1. Common headers for fdt.h and ofw_machdep.h under x86/include
with indirections under i386/include and amd64/include.
2. New modinfo for loader provided FDT blob.
3. Common x86_init_fdt() called from hammer_time() on amd64 and
init386() on i386.
4. Split-off FDT specific low-level console functions from FDT
bus methods for the uart(4) driver. The low-level console
logic has been moved to uart_cpu_fdt.c and is used for arm,
mips & powerpc only. The FDT bus methods are shared across
all architectures.
5. Add dev/fdt/fdt_x86.c to hold the fdt_fixup_table[] and the
fdt_pic_table[] arrays. Both are empty right now.
FDT addresses are I/O ports on x86. Since the core FDT code does
not handle different address spaces, adding support for both I/O
ports and memory addresses requires some thought and discussion.
It may be better to use a compile-time option that controls this.
Obtained from: Juniper Networks, Inc.
Group onboard mic and headphone mic jack together. Creates association that
will switch between microphone inputs depending on the state of the headphone
jack being connected to a live mic.
Fixes onboard mic not working at all on T520.
Tested on T520, T420.
Suspect X220 needs this too, untested on.
MFC after: 1 month
The list-based DMA engine has the following behaviour:
* When the DMA engine is in the init state, you can write the first
descriptor address to the QCU TxDP register and it will work.
* Then when it hits the end of the list (ie, it either hits a NULL
link pointer, OR it hits a descriptor with VEOL set) the QCU
stops, and the TxDP points to the last descriptor that was transmitted.
* Then when you want to transmit a new frame, you can then either:
+ write the head of the new list into TxDP, or
+ you write the head of the new list into the link pointer of the
last completed descriptor (ie, where TxDP points), then kick
TxE to restart transmission on that QCU>
* The hardware then will re-read the descriptor to pick up the link
pointer and then jump to that.
Now, the quirks:
* If you write a TxDP when there's been no previous TxDP (ie, it's 0),
it works.
* If you write a TxDP in any other instance, the TxDP write may actually
fail. Thus, when you start transmission, it will re-read the last
transmitted descriptor to get the link pointer, NOT just start a new
transmission.
So the correct thing to do here is:
* ALWAYS use the holding descriptor (ie, the last transmitted descriptor
that we've kept safe) and use the link pointer in _THAT_ to transmit
the next frame.
* NEVER write to the TxDP after you've done the initial write.
* .. also, don't do this whilst you're also resetting the NIC.
With this in mind, the following patch does basically the above.
* Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA,
kill the TDMA special case and replace it with the above.
* Add a new TXQ flag - PUTRUNNING - which indicates that we've started
DMA.
* Clear that flag when DMA has been shutdown.
* Ensure that we're not restarting DMA with PUTRUNNING enabled.
* Fix the link pointer logic during TXQ drain - we should always ensure
the link pointer does point to something if there's a list of frames.
Having it be NULL as an indication that DMA has finished or during
a reset causes trouble.
Now, given all of this, i want to nuke axq_link from orbit. There's now HAL
methods to get and set the link pointer of a descriptor, so what we
should do instead is to update the right link pointer.
* If there's a holding descriptor and an empty TXQ list, set the
link pointer of said holding descriptor to the new frame.
* If there's a non-empty TXQ list, set the link pointer of the
last descriptor in the list to the new frame.
* Nuke axq_link from orbit.
Note:
* The AR9380 doesn't need this. FIFO TX writes are atomic. As long as
we don't append to a list of frames that we've already passed to the
hardware, all of the above doesn't apply. The holding descriptor stuff
is still needed to ensure the hardware can re-read a completed
descriptor to move onto the next one, but we restart DMA by pushing in
a new FIFO entry into the TX QCU. That doesn't require any real
gymnastics.
Tested:
* AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
Most likely some non-USB compliant devices will choke on it
sooner or later. Clear stall is strictly speaking not needed.
If the first MIDI command sent or transmitted is lost, this
is not a big problem for us.
MFC after: 1 week
Set a valid alternate interface setting
when enumerating USB audio devices else
the device mentioned will not work like
expected.
PR: usb/178722
MFC after: 1 week
o The CP2101 and CP2102 do not support GPIO pin use at all, enforce this.
o Support reading the GPIO status on the second port of the CP2105. More
work is needed before the CP2105 GPIO pins can be used as outputs.
Hardware donated by: Silicon Labs
MFC after: 3 weeks
doesn't match the actual hardware queue this frame is queued to.
I'm trying to ensure that the holding buffers are actually being queued
to the same TX queue as the holding buffer that they end up on.
I'm pretty sure this is all correct so if this complains, it'll be due
to some kind of subtle broken-ness that needs fixing.
This is only done for legacy hardware, not EDMA hardware.
Tested:
* AR5416 STA mode, very lightly
PS-POLL support.
This implements PS-POLL awareness i nthe
* Implement frame "leaking", which allows for a software queue
to be scheduled even though it's asleep
* Track whether a frame has been leaked or not
* Leak out a single non-AMPDU frame when transmitting aggregates
* Queue BAR frames if the node is asleep
* Direct-dispatch the rest of control and management frames.
This allows for things like re-association to occur (which involves
sending probe req/resp as well as assoc request/response) when
the node is asleep and then tries reassociating.
* Limit how many frames can set in the software node queue whilst
the node is asleep. net80211 is already buffering frames for us
so this is mostly just paranoia.
* Add a PS-POLL method which leaks out a frame if there's something
in the software queue, else it calls net80211's ps-poll routine.
Since the ath PS-POLL routine marks the node as having a single frame
to leak, either a software queued frame would leak, OR the next queued
frame would leak. The next queued frame could be something from the
net80211 power save queue, OR it could be a NULL frame from net80211.
TODO:
* Don't transmit further BAR frames (eg via a timeout) if the node is
currently asleep. Otherwise we may end up exhausting management frames
due to the lots of queued BAR frames.
I may just undo this bit later on and direct-dispatch BAR frames
even if the node is asleep.
* It would be nice to burst out a single A-MPDU frame if both ends
support this. I may end adding a FreeBSD IE soon to negotiate
this power save behaviour.
* I should make STAs timeout of power save mode if they've been in power
save for more than a handful of seconds. This way cards that get
"stuck" in power save mode don't stay there for the "inactivity" timeout
in net80211.
* Move the queue depth check into the driver layer (ath_start / ath_transmit)
rather than doing it in the TX path.
* There could be some naughty corner cases with ps-poll leaking.
Specifically, if net80211 generates a NULL data frame whilst another
transmitter sends a normal data frame out net80211 output / transmit,
we need to ensure that the NULL data frame goes out first.
This is one of those things that should occur inside the VAP/ic TX lock.
Grr, more investigations to do..
Tested:
* STA: AR5416, AR9280
* AP: AR5416, AR9280, AR9160
QLogic 8300 Series Adapters
Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
Approved by: George Neville-Neil (gnn@freebsd.org)
* Move the node sleep/wake state under the TX lock rather than the
node lock. Let's leave the node lock protecting rate control only
for now.
* When reassociating, various state needs to be cleared. For example,
the aggregate session needs to be torn down, including any pending
aggregation negotiation and BAR TX waiting.
* .. and we need to do a "cleanup" pass since frames in the hardware
TX queue need to be transmitted.
Modify ath_tx_tid_cleanup() to be called with the TX lock held and push
frames into a completion list. This allows for the cleanup to be
done atomically for all TIDs in a node rather than grabbing and
releasing the TX lock each time.
a non-loss reset.
When the drain functions are called, the holding descriptor and link pointers
are NULLed out.
But when the processq function is called during a non-loss reset, this
doesn't occur. So the next time a DMA occurs, it's chained to a descriptor
that no longer exists and the hardware gets angry.
Tested:
* AR5416, STA mode; use sysctl dev.ath.X.forcebstuck=1 to force a non-loss
reset.
TODO:
* Further AR9380 testing just to check that the behaviour for the EDMA
chips is sane.
PR: kern/178477
assigned conflicting ranges to BARs then leaving the BARs alone could
result in one device stealing mmio accesses intended to go to a second
device. Prior to 233677 the PCI bus driver attempted to handle this case
by clearing the BAR to 0 depending on BARs based at 0 not decoding (which
is not guaranteed to be true). Now when a conflicting BAR is detected the
following steps are taken:
1) If hw.pci.realloc_bars (a new tunable) is enabled (default is enabled),
then ignore the current BAR setting from the firmware and attempt to
allocate a fresh resource range for the BAR.
2) If 1) failed (or was disabled), disable decoding for the relevant
BAR type (e.g. disable mem decoding for a memory BAR) and emit a
warning if booting verbose.
Tested by: Alex Keda <admin@lissyara.su>
MFC after: 1 week
irrespective of the setting of lem_rx_process_limit, while
giving a chance to the taskqueue scheduler to act after
each chunk.
This makes lem_rxeof similar to the one in if_em.c and if_igb.c .
if_lem.c and if_em.c: add a sysctl to manually configure the
'itr' moderation register.
Approved by: Jack Vogel
of "right".)
Flip back on the "always continue TX DMA using the holding descriptor"
code - by always setting ATH_BUF_BUSY and never setting axq_link to NULL.
Since the holding descriptor is accessed via txq->axq_link and _that_
is done behind the TXQ lock rather than the TX path lock, the holding
descriptor stuff itself needs to be behind the TXQ lock.
So, do the mental gymnastics needed to do this.
I've not seen any of the hardware failures that I was seeing when
I last tried to do this.
Tested:
* AR5416, STA mode
* Fix API changes;
* remove unused code;
* Allow some switches to be used that don't expose a set of PHY
registers for the CPU facing port (eg the ADM6996 for the Ubiquiti
Routerstation.)
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by: ray
This adds a vlan capability field to etherswitch_info structure and some
definitions of ports flags.
It adds the support to global config parameters which right now is used
only to switch between the vlan modes, but it is intended to be extended
to support the setup of others parameters (STP, mirror, etc.).
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by: ray
Use if_initbaudrate() to set baudrate.
Add IFCAP_LINKSTATE to if_capabilities.
Submitted by: David C Somayajulu <davidcs@freebsd.org>
Approved by: George Neville-Neil <gnn@freebsd.org>
I'm not sure why this is failing. The holding descriptor should be being
re-read when starting DMA of the next frame. Obviously something here
isn't totally correct.
I'll review the TX queue handling and see if I can figure out why this
is failing. I'll then re-revert this patch out and use the holding
descriptor again.
2. Added Flash Read/Update Support
3. Fixed TSO Handling
Submitted by: David C Somayajulu (davidcs@freebsd.org)
Reviewed by: George Neville-Neil (gnn@freebsd.org)
Approved by: George Neville-Neil (gnn@freebsd.org)
but partly to just tidy up things.
The problem here - there are too many TX buffers in the queue! By the
time one needs to transmit an EAPOL frame (for this PR, it's the response
to the group rekey notification from the AP) there are no ath_buf entries
free and the EAPOL frame doesn't go out.
Now, the problem!
* Enforcing the TX buffer limitation _before_ we dequeue the frame?
Bad idea. Because..
* .. it means I can't check whether the mbuf has M_EAPOL set.
The solution(s):
* De-queue the frame first
* Don't bother doing the TX buffer minimum free check until after
we know whether it's an EAPOL frame or not.
* If it's an EAPOL frame, allocate the buffer from the mgmt pool
rather than the default pool.
Whilst I'm here:
* Add a tweak to limit how many buffers a single node can acquire.
* Don't enforce that for EAPOL frames.
* .. set that to default to 1/4 of the available buffers, or 32,
whichever is more sane.
This doesn't fix issues due to a sleeping node or a very poor performing
node; but this doesn't make it worse.
Tested:
* AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received
(thus the TX queue fills up.)
* .. with CCMP / WPA2 encryption configured
* .. and the group rekey time set to 10 seconds, just to elicit the
behaviour very quickly.
PR: kern/138379
to driver specific files.
- window initialization is done during device attach
- CESA TDMA decoding windows values are set based on DTS,
not copied from CPU registers
- remove unnecessary virtual mapping
- update dts file
Obtained from: Semihalf
- Allow DMA addresses anywhere in the lower 4GB; Envy24HT has a 32-bit DMA
engine, not 28-bit like Envy24.
- Mark interrupt handler as MPSAFE, seems to be correctly synchronized.
PR: kern/152378
Submitted by: Jason Harmening <jason.harmening@gmail.com>
MFC after: 1 month
just "when the queue is busy."
After talking with the MAC team, it turns out that the linked list
implementation sometimes will not accept a TxDP update and will
instead re-read the link pointer. So even if the hardware has
finished transmitting a chain and has hit EOL/VEOL, it may still
re-read the link pointer to begin transmitting again.
So, always set ATH_BUF_BUSY on the last buffer in the chain (to
mark the last descriptor as the holding descriptor) and never
blank the axq_link pointer.
Tested:
* AR5416, STA mode
TODO:
* much more thorough testing with the pre-11n NICs, just to verify
that they behave the same way.
* test TDMA on the 11n and non-11n hardware.
in reduced memory systems.
- Split allocation and freeing of the configuration descriptor into a separate
function, so that the configuration descriptor can be made fixed size
to save memory allocations. This applies for both device and host mode.
versions than the one in base (dim@ mentioned he tried on 4.7.3 and 4.8.1)
do not whine about it, so, at some point this workaround will be reverted.
Reported by: ache
Discussed with: dim
The QCA9565 is a 1x1 2.4GHz 11n chip with integrated on-chip bluetooth.
The AR9300 HAL already has support for this chip; it just wasn't
included in the probe/attach path.
Tested:
* This commit brought to you over a QCA9565 wifi connection from
FreeBSD.
* .. ie, basic STA, pings, no iperf or antenna diversity checking just yet.
Add a simplebus attachment for cfi(4)'s FDT support and move
cfi_bus_fdt.c to sys/conf/files so non-ppc architectures are supported.
Sponsored by: DARPA, AFRL
- netmap_rx_irq()/netmap_tx_irq() can now be called by FreeBSD drivers
hiding the logic for handling NIC interrupts in netmap mode.
This also simplifies the case of NICs attached to VALE switches.
Individual drivers will be updated with separate commits.
- use the same refcount() API for FreeBSD and linux
- plus some comments, typos and formatting fixes
Portions contributed by Michio Honda
those of some non-architectural core events. This is not a problem in the
general case as long as there's an 1:1 mapping between the two, but there
are few exceptions. For example, 3CH_01H on Nehalem/Westmere represents
both unhalted-reference-cycles and CPU_CLK_UNHALTED.REF_P.
CPU_CLK_UNHALTED.REF_P on the aforementioned architectures does not measure
reference (i.e. bus) but TSC, so there's the need to disambiguate.
In order to avoid the namespace collision rename all the architectural
events in a way they cannot be ambigous and refactor the architectural
events handling function to reflect this change.
While here, per Jim Harris request, rename
iap_architectural_event_is_unsupported() to iap_event_is_architectural().
Discussed with: jimharris
Reviewed by: jimharris, gnn
at least if FreeBSD is ran under VirtualBox. In order to avoid the leakage,
properly deallocate structures in case CPU claims that hw performance
monitoring counters are not supported.
Reported by: hiren
-DBKTR_NEW_MSP34XX_DRIVER and -Wformat-security.
This also allows to eliminates a superfluous malloc/snprintf/free on
intermediate buffer.
PR: kern/175546
MFC after: 1 week
The NTB allows you to connect two systems with this device using a PCI-e
link. The driver is made of two modules:
- ntb_hw which is a basic hardware abstraction layer for the device.
- if_ntb which implements the ntb network device and the communication
protocol.
The driver is limited at the moment to CPU memcpy instead of using DMA, and
only Back-to-Back mode is supported. Also the network device isn't full
featured yet. These changes will be coming soon. The DMA change will also
bring in the ioat driver from the project branch it is on now.
This is an initial port of the GPL/BSD Linux driver contributed by Jon Mason
from Intel. Any bugs are my contributions.
Sponsored by: Intel
Reviewed by: jimharris, joel (man page only)
Approved by: jimharris (mentor)
* That lock isn't actually held during reset - just the whole TX/RX path
is paused. So, remove the assertion.
* Log the TX queue status - how many hardware frames are active in the
MAC and whether the queue is active.
/home/sbruno/bsd/head/sys/dev/hptrr/hptrr_osm_bsd.c:178:66: warning: for loop has empty body [-Wempty-body]
for (order=0, size=PAGE_SIZE; size<f->size; order++, size<<=1) ;
^
/home/sbruno/bsd/head/sys/dev/hptrr/hptrr_osm_bsd.c:178:66: note: put the semicolon on a separate line to silence this warning
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
OpenCISS states that if the value is 0, then the driver should try a value
of 31. That's just silly. Set to 17 so that the subtraction for maxio
becomes 16 and aligns nicely.
Reviewed by: scottl
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
Communication on src-commiters, Sat, 27 Apr 2013 22:09:06 -0700,
Subject was: "Re: svn commit: r249997"
As I'm here, fix the style main block comments in files' headers.
If max_sg_length is 0, then we default to 16
If max_sg_length is less than CISS_MAX_SG_ELEMENTS, then
we will set round the value of max_sg_length to the nearest
power of 2 and use it to align maxio.
Else, we will use CISS_MAX_SG_ELEMENTS for our calculations.
Thanks to scottl for working me through the history and providing
the basis for this patch.
Submitted by: scott
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
and tuned value, we would advertise the unsupported value to CAM and it would
merrily destroy the controller with way too many IO operations.
This manifests itself in a Zero Memory RAID configuration for a P410 and
possibly other controllers.
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
that uses non-ISA IRQs but use a plain IRQ resource in _CRS. However,
a non-ISA IRQ can't fit into a plain IRQ resource. If we encounter a
link like this, build the resource buffer from _PRS instead of _CRS.
- Set the correct size of the end tag in a resource buffer.
Tested by: Benjamin Lee <ben@b1c1l1.com>
MFC after: 2 weeks
than VLAN groups.
Some chips (eg this rtl8366rb) has a VLAN group per port - you first
define a set of VLANs in a vlan group, then you assign a VLAN group
to a port.
Other chips (eg the AR8xxx switch chips) have a VLAN ID array per
port - there's no group per se, just a list of vlans that can be
configured.
So for now, the switch API will use the latter and rely on drivers
doing the heavy lifting if one wishes to use the VLAN group method.
Maybe later on both can be supported.
PR: kern/177878
PR: kern/177873
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
Reviewed by: ray
the pause/resume code to not be called completely symmetrically.
I'll chase down the root cause of that soon; this at least works around
the bug and tells me when it happens.
is compiled in or not.
This fixes issues with people running -HEAD but who build modules
without doing a "make buildkernel KERNCONF=XXX", thus picking up
opt_*.h. The resulting module wouldn't have 11n enabled and the
chainmask configuration would just be plain wrong.
This is intended to be used as a stop-gap for switch devices
which expose multiple ethernet PHYs but we don't have a driver
for - here, etherswitchcfg and the general switch configuration
API can be used to interface to said PHYs.
Submitted by: Luiz Otavio O Souza <loos.br@gmail.com>
* Add ah_ratesArray[] to the ar5416 HAL state - this stores the maximum
values permissable per rate.
* Since different chip EEPROM formats store this value in a different place,
store the HT40 power detector increment value in the ar5416 HAL state.
* Modify the target power setup code to store the maximum values in the
ar5416 HAL state rather than using a local variable.
* Add ar5416RateToRateTable() - to convert a hardware rate code to the
ratesArray enum / index.
* Add ar5416GetTxRatePower() - which goes through the gymnastics required
to correctly calculate the target TX power:
+ Add the power detector increment for ht40;
+ Take the power offset into account for AR9280 and later;
+ Offset the TX power correctly when doing open-loop TX power control;
+ Enforce the per-rate maximum value allowable.
Note - setting a TPC value of 0x0 in the TX descriptor on (at least)
the AR9160 resulted in the TX power being very high indeed. This didn't
happen on the AR9220. I'm guessing it's a chip bug that was fixed at
some point. So for now, just assume the AR5416/AR5418 and AR9130 are
also suspect and clamp the minimum value here at 1.
Tested:
* AR5416, AR9160, AR9220 hostap, verified using (2GHz) spectrum analyser
* Looked at target TX power in TX descriptor (using athalq) as well as TX
power on the spectrum analyser.
TODO:
* The TX descriptor code sets the target TX power to 0 for AR9285 chips.
I'm not yet sure why. Disable this for TPC and ensure that the TPC
TX power is set.
* AR9280, AR9285, AR9227, AR9287 testing!
* 5GHz testing!
Quirks:
* The per-packet TPC code is only exercised when the tpc sysctl is set
to 1. (dev.ath.X.tpc=1.) This needs to be done before you bring the
interface up.
* When TPC is enabled, setting the TX power doesn't end up with a call
through to the HAL to update the maximum TX power. So ensure that
you set the TPC sysctl before you bring the interface up and configure
a lower TX power or the hardware will be clamped by the lower TX
power (at least until the next channel change.)
Thanks to Qualcomm Atheros for all the hardware, and Sam Leffler for use
of his spectrum analyser to verify the TX channel power.
ath_tx_rate_fill_rcflags(). Include setting up the TX power cap in the
rate scenario setup code being passed to the HAL.
Other things:
* add a tx power cap field in ath_rc.
* Add a three-stream flag in ath_rc.
* Delete the LDPC flag from ath_rc - it's not a per-rate flag, it's a
global flag for the transmission.
directly referencing ni->ni_txpower.
This provides the hardware with a slightly more accurate idea of
the maximum TX power to be using.
This is part of a series to get per-packet TPC to work (better).
Tested:
* AR5416, hostap mode
well as enabled when necessary. And simplify the checksum routine
itself, adding UDP bit to the test. Thanks to Kevin Lo for pointing
out the problems and code suggestions.
device which makes the request for dma tag, instead of some descendant
of the PCI device, by creating a pass-through trampoline for vga_pci
and ata_pci buses.
Sponsored by: The FreeBSD Foundation
Suggested by: jhb
Discussed with: jhb, mav
MFC after: 1 week
Stop abusing xpt_periph in random plases that really have no periph related
to CCB, for example, bus scanning. NULL value is fine in such cases and it
is correctly logged in debug messages as "noperiph". If at some point we
need some real XPT periphs (alike to pmpX now), quite likely they will be
per-bus, and not a single global instance as xpt_periph now.
This includes a new IOCTL to support a generic method for nvmecontrol(8) to pass
IDENTIFY, GET_LOG_PAGE, GET_FEATURES and other commands to the controller, rather than
separate IOCTLs for each.
Sponsored by: Intel
These were added early on for benchmarking purposes to avoid the mapped I/O
penalties incurred in kern_physio. Now that FreeBSD (including kern_physio)
supports unmapped I/O, the need for these NVMe-specific routines no longer exists.
Sponsored by: Intel
it is being installed). Improve other error messages while here.
- Select special FPGA specific configuration profile when appropriate.
MFC after: 3 days
volumes behind a ciss(4) controller were being reported with malformeed
names and identifiers.
Repair that reporting by using the CAM values for the three SCSI indents
reported via camcontrol devlist
PR: kern/171650
Reviewed by: scottl
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
somewhere around svn r39402 to r39234.
I don't know of anyone who really wants to test these changes, but they
only remove the deprecated code in question. This shreds the driver down a
bit and *removes* options from the kernel configs.
These don't appear to be referenced in the man page, so no need to check it
there.
PR: kern/44587
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
sys/dev/firewire/firewire.c:
- fw_xfer_unload(): Since we are about to free this xfer, call fw_tl_free()
to remove the xfer from its tlabel's list, if it has a tlabel.
- In every occasion when a xfer is removed from a tlabel's list, reset
xfer->tl to -1 while holding fc->tlabel_lock, so that the xfer isn't
mis-identified as belonging to a tlabel.
This doesn't fix all the use-after-free problems for M_FWMEM, but is an
incremental towards that goal.
Reviewed by: kan, sbruno
Sponsored by: Spectra Logic
relearning. Specifically, add subcommands to mfiutil(8) which allow the
user to set the BBU and autolearn modes when the firmware supports it,
and add a subcommand which kicks off a battery relearn.
Reviewed by: sbruno, rstone
Tested by: sbruno
Approved by: rstone (co-mentor)
MFC after: 2 weeks
Sponsored by: Sandvine Incorporated
In r249041, I2C slave addresses were left-shifted at creation time to
have the same behavior between i915 and radeon (not committed yet). This
change broke the aux channel. The user-visible change was that display
port on i915 didn't work anymore.
To fix this, we right-shift the address back to restore the original value.
Reported by: Olivier Cochard-Labbé <olivier@cochard.me>
Tested by: Olivier Cochard-Labbé <olivier@cochard.me>
Reviewed by: kib@
option left but actually consumed by ada(4), so move it to opt_ada.h
and get rid of opt_ata.h.
- Fix stand-alone build of atacore(4) by adding opt_cam.h.
- Use __FBSDID.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Move ata_timeout() to ata-all.c so we don't need to expose both this
function and ata_cam_end_transaction() but only the former.
- Move ata_cmd2str() from ata-queue.c to ata-all.c so we can get rid of
the former.
- Add some missing prototypes.
MFC after: 3 days
