These realtek switch PHYs speak a variant of i2c with some slightly
modified handling.
From the submitter, slightly modified now that some further digging
has been done:
The I2C framework makes a assumption that the read/not-write bit of the first
byte (the address) indicates whether reads or writes are to follow.
The RTL8366 family uses the bus: after sending the address+read/not-write byte,
two register address bytes are sent, then the 16-bit register value is sent
or received. While the register write access can be performed as a 4-byte
write, the read access requires the read bit to be set, but the first two bytes
for the register address then need to be transmitted.
This patch maintains the i2c protocol behaviour but allows it to be relaxed
(for these kinds of switch PHYs, and whatever else Realtek may do with this
almost-but-not-quite i2c bus) - by setting the "strict" hint to 0.
The "strict" hint defaults to 1.
Submitted by: Stefan Bethke <stb@lassitu.de>
It appears this device fails if sent a SYNCHRONIZE_CACHE command, so add
quirk to avoid sending it.
I will follow up with Micron on this issue, and will adjust the quirk if
necessary based on their feedback.
Reviewed by: hselasky@
According to the open firmware standard, finddevice call has to return
a phandle with value of -1 in case of error.
This commit is to:
- Fix the FDT implementation of this interface (ofw_fdt_finddevice) to
return (phandle_t)-1 in case of error, instead of 0 as it does now.
- Fix up the callers of OF_finddevice() to compare the return value with
-1 instead of 0 to check for errors.
- Since phandle_t is unsigned, the return value of OF_finddevice should
be checked with '== -1' rather than '<= 0' or '> 0', fix up these cases
as well.
Reported by: nwhitehorn
Reviewed by: raj
Approved by: raj, nwhitehorn
to known AHCI-capable chips (AMD/NVIDIA), configured for legacy emulation.
Enabled by default to get additional performance and functionality of AHCI
when it can't be enabled by BIOS. Can be disabled to honor BIOS settings if
needed for some reason.
MFC after: 1 month
control for all vr(4) controllers that support it. It's known that
old vr(4) controllers(Rhine II) does not support TX pause but Rhine
III supports both TX and RX pause.
Make TX pause really work on Rhine III by letting controller know
available RX buffers.
While here, adjust XON/XOFF parameters to get better performance
with flow control.
using member variables in softc.
While I'm here change media after setting IFF_DRV_RUNNING. This
will remove unnecessary link state handling in vr_tick() if
controller established a link immediately.
transfer statemachine. This work is about using a single
state variable instead of multiple state bits as input
for the USB statemachine to determine what to do in the
various parts of the code. No APIs towards USB device
drivers or USB host controller drivers will be changed.
MFC after: 1 month
put into suspend/shutdown. Old PCI controllers performed that
operation in firmware but for RTL8111C or newer controllers, it's
responsibility of driver. It's not clear whether the firmware of
RTL8111B still downgrades its speed to 10/100Mbps so leave it as it
was.
issues probably needing workarounds in bge(4) when brgphy(4) handles this
PHY. Letting ukphy(4) handle it instead results in a working configuration,
although likely with performance penalties.
The calibrate callout is done with the sc lock held.
This only showed up when using an older NIC (AR5212) whose
radio/phy requires the rfgain adjustment.
Pointy-hat-to: adrian
Sponsored by: Hobnob, Inc.
* Failall is now named just that.
* Add TX ok and TX fail, for aggregate frame sub-frames.
This will break athstats; a followup commit wil resolve this.
Sponsored by: Hobnob, Inc.
Because there is no reliable way to know whether RX MAC is in
stopped state, rejecting all frames would be the only way to
minimize possible races.
Otherwise it's possible to receive frames while stop command
execution is in progress and controller can DMA the frame to freed
RX buffer during that period.
This was observed on recent PCIe controllers(i.e. RTL8111F).
While this change may not be required on old controllers it
wouldn't make negative effects on old controllers. One side effect
of this change is disabling receive so driver reprograms RL_RXCFG
to receive WOL frames when it is put into suspend or shutdown.
This should address occasional 'memory modified free' errors seen
on recent RealTek controllers.
driver would ignore the first link state update if controller
already established a link such that it would have to take
additional link state handling in re_tick().
access.
While I'm here, enable WOL through magic packet but disable waking
up system via unicast, multicast and broadcast frames. Otherwise,
multicast or unicast frame(e.g. ICMP echo request) can wake up
system which is not probably wanted behavior on most environments.
This was not known as problem because RL_CFG5 register access had
not effect until this change.
The capability to wake up system with unicast/multicast frames
are still set in driver, default off, so users who need that
feature can still activate it with ifconfig(8).
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
bit should not affect link establishment process of auto-negotiation
if manual configuration is not used, which is true in auto-negotiation.
However it seems setting this bit interfere with IP1001 PHY's
down-shifting feature such that establishing a 10/100Mbps link failed
when 1000baseT link is not available during auto-negotiation process.
Tested by: Andrey Smagin <samspeed <> mail dot ru >
Pause timer value is initialized to 0xFFFF. Controller allows just
4 different TX pause thresholds. The lowest possible threshold
value looks too aggressive so use next available threshold value.
- Remove MIIBUS statchg callback and program VGE_DIAGCTL before
initiating link establishment. Previously driver used to
program VGE_DIAGCTL after getting a link in statchg callback.
It seems the VGE_DIAGCTL register works like a kind of MII
register such that it requires setting a 'to be' mode in advance
rather than relying on resolved speed/duplex of established link.
This means the statchg callback is not needed in driver. In
addition, if there was no link at the time of media change, this
was not called at all.
- Introduce vge_ifmedia_upd_locked() to change current media to
configured one. Actual media change is performed only after PHY
reset and VGE_DIAGCTL setup.
- In WOL configuration, make sure to clear forced mode such that
controller can rely on auto-negotiation.
- Unlike most other drivers that use miibus(4), vge(4) used
controller's auto-polling feature for link state tracking via
interrupt. This came from controller's inefficient mechanism to
access MII registers. On link state change interrupt, vge(4)
used to get current link state with series of MII register
accesses. Because vge(4) already enabled auto polling, read PHY
status register to resolved speed/duplex/flow control parameters.
vge(4) still does not drive MII_TICK to reduce number of MII
register accesses which in turn means the driver does not know the
status of auto-negotiation. This was a one of long standing
issue of vge(4). Probably driver may be able to implement a timer
that keeps track of auto-negotiation state and restart
auto-negotiation when driver couldn't establish a link within a
specified period. However the controller does not provide a
reliable way to detect auto-negotiation failure so I'm not sure
whether it's worth to implement it in driver.
Alternatively driver can completely disable MII auto-polling and
let miibus(4) poll link state by driving MII_TICK. This may reduce
unnecessary overhead of stopping/restarting MII auto-polling of
controller. Unfortunately it was known that some variants of
controller does not work correctly if MII auto-polling is disabled.
This fixes panics that users have been seeing when operating in station mode,
where the interface undergoes a lot more resets then in hostap mode (ie whilst
doing channel scanning.)
Reported by: arundel, wblock@wonkity.com
Sponsored by: Hobnob, Inc.
passed over to the runtime firmware on 6050 devices. Instead let
the runtime firmware do the calibration itself. This fixes support
for the 6050 series devices.
Obtained from: OpenBSD
Submitted by: kevlo
Tested by: lx, Tz-Huan Huang(earlier version)
defined and will allow consumers, willing to provide options, file and
line to locking requests, to not worry about options redefining the
interfaces.
This is typically useful when there is the need to build another
locking interface on top of the mutex one.
The introduced functions that consumers can use are:
- mtx_lock_flags_
- mtx_unlock_flags_
- mtx_lock_spin_flags_
- mtx_unlock_spin_flags_
- mtx_assert_
- thread_lock_flags_
Spare notes:
- Likely we can get rid of all the 'INVARIANTS' specification in the
ppbus code by using the same macro as done in this patch (but this is
left to the ppbus maintainer)
- all the other locking interfaces may require a similar cleanup, where
the most notable case is sx which will allow a further cleanup of
vm_map locking facilities
- The patch should be fully compatible with older branches, thus a MFC
is previewed (infact it uses all the underlying mechanisms already
present).
Comments review by: eadler, Ben Kaduk
Discussed with: kib, jhb
MFC after: 1 month
mode configuration registers. This is apparently required for correct
behaviour, but also requires the chip to actually officially support it.
Sponsored by: Hobnob, Inc.
"correct" handling of frames in the RX pending queue during interface
transitions.
* ath_stoprecv() doesn't blank out the descriptor list - that's what
ath_startrecv() does. So, change a comment to reflect that.
* ath_stoprecv() does include a large (3ms) delay to let pending DMA
complete. However, I'm under the impression that the stopdma hal
method does check for a bit in the PCU to indicate DMA has stopped.
So, to help with fast abort and restart, modify ath_stoprecv() to take
a flag which indicates whether this is needed.
* Modify the uses of ath_stoprecv() to pass in a flag to support the
existing behaviour (ie, do the delay.)
* Remove some duplicate PCU teardown code (which wasn't shutting down DMA,
so it wasn't entirely correct..) and replace it with a call to
ath_stoprecv(sc, 0) - which disables the DELAY call.
The upshoot of this is now channel change doesn't simply drop completed
frames on the floor, but instead it cleanly handles those frames.
It still discards pending TX frames in the software and hardware queues
as there's no (current) logic which forcibly recalculates the rate control
information (or whether they're appropriate to be on the TX queue after
a channel change), that'll come later.
This still doesn't stop all the sources of queue stalls but it does
tidy up some of the code duplication.
To be complete, queue stalls now occur during normal behaviour -
they only occur after some kind of broken behaviour causes an interface
or node flush, upsetting the TX/RX BAW. Subsequent commits will
incrementally fix these and other related issues.
Sponsored by: Hobnob, Inc.
to the kernel's pause() function. The pause() function can now be used
when cold != 0. Also assert that the timeout in system ticks must be
positive.
Suggested by: Bruce Evans
MFC after: 1 week
to kern/subr_bus.c. Simplify this function so that it no longer
depends on malloc() to execute. Identify a few other places where
it makes sense to use device_delete_all_children().
MFC after: 1 week
It's not currently used; it didn't build on 32-bit and the previous build fix
is incorrect. If we really implement self-tests we can do this again
properly.
Submitted by: Ben Hutchings <bwh -at- solarflare.com>
MFC after: 3 weeks
This field is supposed to be set to the interface bit rate, but for some
reason I thought it was denominated in kilobits. Multiply the values up
accordingly, taking care to saturate rather than overflow on 32-bit
architectures.
Submitted by: Ben Hutchings <bwh -at- solarflare.com>
MFC after: 3 weeks
addresses from being probed and attaching something including ukphy(4)
to it. This is mainly necessarily for PHY switches that create duplicate
or fake PHYs on the bus that can corrupt the PHY state when accessed or
simply cause problems when ukphy(4) isolates the additional instances.
- Change miibus(4) to be a hinted bus, allowing to add child devices via
hints and to set their attach arguments (including for automatically
probed PHYs). This is mainly needed for PHY switches that violate IEEE
802.3 and don't even implement the basic register set so we can't probe
them automatically. However, the ability to alter the attach arguments
for automatically probed PHYs is also useful as for example it allows
to test (or tell a user to test) new variant of a PHY with a specific
driver by letting an existing driver attach to it via manipulating the
IDs without the need to touch the source code or to limit a Gigabit
Ethernet PHY to only announce up to Fast Ethernet in order to save
energy by limiting the capability mask. Generally, a driver has to
be hinted via hint.phydrv.X.at="miibusY" and hint.phydrv.X.phyno="Z"
(which already is sufficient to add phydrvX at miibusY at PHY address
Z). Then optionally the following attach arguments additionally can
be configured:
hint.phydrv.X.id1
hint.phydrv.X.id2
hint.phydrv.X.capmask
- Some minor cleanup.
Reviewed by: adrian, ray
dcphy(4) (CID 9283).
- In dc_detach(), check whether ifp is NULL as dc_attach() may call the
former without ifp being allocated (CID 4288).
Found with: Coverity Prevent(tm)
!DC_IS_ADMTEK in dc_miibus_statchg(). This change broke link
establishment of Intel 21143 with dcphy(4) where it stuck in
"ability detect" state without completing auto-negotiation.
Also nuke dc_if_media as it's not actually used.
Submitted by: marius
Tested on Qemu/KVM, VirtualBox, and BHyVe.
Currently built as modules-only on i386/amd64. Man pages not yet hooked
up, pending review.
Submitted by: Bryan Venteicher bryanv at daemoninthecloset dot org
Reviewed by: bz
MFC after: 4 weeks or so
for the ath(4) driver.
Currently, there's nothing stopping reset, channel change and general
TX/RX from overlapping with each other. This wasn't a big deal with
pre-11n traffic as it just results in some dropped frames.
It's possible this may have also caused some inconsistencies and
badly-setup hardware.
Since locks can't be held across all of this (the Linux solution)
due to LORs with the network stack locks, some state counter
variables are used to track what parts of the code the driver is
currently in.
When the hardware is being reset, it disables the taskqueue and
waits for pending interrupts, tx, rx and tx completion before
it begins the reset or channel change.
TX and RX both abort if called during an active reset or channel
change.
Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS
is set. Instead, completed TX and RX frames are passed back up to
net80211 before the reset occurs.
This is not without problems:
* Raw frame xmit are just dropped, rather than placed on a queue.
The net80211 stack should be the one which queues these frames
rather than the driver.
* It's all very messy. It'd be better if these hardware operations
were serialised on some kind of work queue, rather than hoping
they can be run in parallel.
* The taskqueue block/unblock may occur in parallel with the
newstate() function - which shuts down the taskqueue and restarts
it once the new state is known. It's likely these operations should
be refcounted so the taskqueue is restored once no other areas
in the code wish to suspend operations.
* .. interrupt disable/enable should likely be refcounted as well.
With this work, the driver does not drop frames during stuck beacon
or fatal errors and thus 11n traffic continues to run correctly.
Default and full resets however do still drop frames and it's possible
this may occur, causing traffic loss and session stalls.
Sponsored by: Hobnob, Inc.
completely skipping them, create ahcich devices for them to allocate unit
numbers, but mark them as disabled to prevent driver probe and attach.
Last time some BIOSes tend to report unused channels as "not implemented".
This change makes ahcichX devices numbering consistent, independently of
connected disks. It makes per-channel driver hints usable and CAM devices
wiring possible on such systems.
I/O from userspace, capable of line rate at 10G, see
http://info.iet.unipi.it/~luigi/netmap/
At this time I am bringing in only the generic code (sys/dev/netmap/
plus two headers under sys/net/), and some sample applications in
tools/tools/netmap. There is also a manpage in share/man/man4 [1]
In order to make use of the framework you need to build a kernel
with "device netmap", and patch individual drivers with the code
that you can find in
sys/dev/netmap/head.diff
The file will go away as the relevant pieces are committed to
the various device drivers, which should happen in a few days
after talking to the driver maintainers.
Netmap support is available at the moment for Intel 10G and 1G
cards (ixgbe, em/lem/igb), and for the Realtek 1G card ("re").
I have partial patches for "bge" and am starting to work on "cxgbe".
Hopefully changes are trivial enough so interested third parties
can submit their patches. Interested people can contact me
for advice on how to add netmap support to specific devices.
CREDITS:
Netmap has been developed by Luigi Rizzo and other collaborators
at the Universita` di Pisa, and supported by EU project CHANGE
(http://www.change-project.eu/)
The code is distributed under a BSD Copyright.
[1] In my opinion is a bad idea to have all manpage in one directory.
We should place kernel documentation in the same dir that contains
the code, which would make it much simpler to keep doc and code
in sync, reduce the clutter in share/man/ and incidentally is
the policy used for all of userspace code.
Makefiles and doc tools can be trivially adjusted to find the
manpages in the relevant subdirs.
controllers.
More and more RealTek controllers started to implement EEE feature.
Vendor driver seems to load a kind of firmware for EEE with
additional PHY fixups. It is known that the EEE feature may need
ASPM support. Unfortunately there is no documentation for EEE of
the controller so enabling ASPM may cause more problems.
Unnecessarily complex LE format used on Marvell controller was
main reason not to enable 64bit DMA addressing in driver. If high
32bit address of DMA address of TX/RX buffer is changed, driver has
to generate a new LE. In TX path, driver will keep track of lastly
used high 32bit address of DMA address and generate a new LE
whenever it sees high address change in the DMA address. In RX path,
driver will always use two LEs to specify 64bit DMA address of RX
buffer. If the high 32bit address of DMA address of RX buffer is
the same as previous DMA address of RX buffer, driver does not have
to use two LEs but driver will use two LEs for simplicity in RX
ring management.
One of draw back for switching to 64bit DMA addressing is that the
large amount of LEs are used to specify 64bit DMA address such that
number of available LEs for TX/RX buffers are considerably reduced.
To mitigate the issue, increase number of available LEs from 256 to
384 for TX and from 256 to 512 for RX. For 32bit architectures,
msk(4) does not use 64bit DMA addressing to save resources.
Tested by: das
based on Solarflare SFC9000 family controllers. The driver supports jumbo
frames, transmit/receive checksum offload, TCP Segmentation Offload (TSO),
Large Receive Offload (LRO), VLAN checksum offload, VLAN TSO, and Receive Side
Scaling (RSS) using MSI-X interrupts.
This work was sponsored by Solarflare Communications, Inc.
My sincere thanks to Ben Hutchings for doing a lot of the hard work!
Sponsored by: Solarflare Communications, Inc.
MFC after: 3 weeks
can be enabled via the hw.mfi.msi tunable. Many mfi(4) controllers also
support MSI-X, but in testing it seems that many adapters do not work with
MSI-X but do work with MSI.
MFC after: 2 weeks
is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered
a couple of misplaced opcode definitions and some missing continual mbox command
cases, so might as well update them here.
maximum IP datagram size (65535 bytes) +
Ethernet header size (14 bytes) +
2 * VLAN tag size (4 bytes) [1].
[1] We need to multiply by 2 to account for the double VLAN tag
provision added in IEEE 802.1ad.
Submitted by: David Somayajulu (david.somayajulu qlogic.com)
MFC after: 4 days
curthread-accessing part of mtx_{,un}lock(9) when using a r210623-style
curthread implementation on sparc64, crashing the kernel in its early
cycles as PCPU isn't set up, yet (and can't be set up as OFW is one of the
things we need for that, which leads to a chicken-and-egg problem). What
happens is that due to the fact that the idea of r210623 actually is to
allow the compiler to cache invocations of curthread, it factors out
obtaining curthread needed for both mtx_lock(9) and mtx_unlock(9) to
before the branch based on kobj_mutex_inited when compiling the kernel
without the debugging options. So change kobj_class_compile_static(9)
to just never acquire kobj_mtx, effectively restricting it to its
documented use, and add a kobj_init_static(9) for initializing objects
using a class compiled with the former and that also avoids using mutex(9)
(and malloc(9)). Also assert in both of these functions that they are
used in their intended way only.
While at it, inline kobj_register_method() and kobj_unregister_method()
as there wasn't much point for factoring them out in the first place
and so that a reader of the code has to figure out the locking for
fewer functions missing a KOBJ_ASSERT.
Tested on powerpc{,64} by andreast.
Reviewed by: nwhitehorn (earlier version), jhb
MFC after: 3 days
- Don't use a single big DMA block for all rings. Create separate
DMA area for each ring instead. Currently the following DMA
areas are created:
Event ring, standard RX ring, jumbo RX ring, RX return ring,
hardware MAC statistics and producer/consumer status area.
For Tigon II, mini RX ring and TX ring are additionally created.
- Added missing bus_dmamap_sync(9) in various TX/RX paths.
- TX ring is no longer created for Tigon 1 such that it saves more
resources on Tigon 1.
- Data sheet is not clear about alignment requirement of each ring
so use 32 bytes alignment for normal DMA area but use 64 bytes
alignment for jumbo RX ring where the extended RX descriptor
size is 64 bytes.
- For each TX/RX buffers use separate DMA tag(e.g. the size of a
DMA segment, total size of DMA segments etc).
- Tigon allows separate DMA area for event producer, RX return
producer and TX consumer which is really cool feature. This
means TX and RX path could be independently run in parallel.
However ti(4) uses a single driver lock so it's meaningless
to have separate DMA area for these producer/consumer such that
this change creates a single status DMA area.
- It seems Tigon has no limits on DMA address space and I also
don't see any problem with that but old comments in driver
indicates there could be issues on descriptors being located in
64bit region. Introduce a tunable, dev.ti.%d.dac, to disable
using 64bit DMA in driver. The default is 0 which means it would
use full 64bit DMA. If there are DMA issues, users can disable
it by setting the tunable to 0.
- Do not increase watchdog timer in ti_txeof(). Previously driver
increased the watchdog timer whenever there are queued TX frames.
- When stat ticks is set to 0, skip processing ti_stats_update(),
avoiding bus_dmamap_sync(9) and updating if_collisions counter.
- MTU does not include FCS bytes, replace it with
ETHER_VLAN_ENCAP_LEN.
With these changes, ti(4) should work on PAE environments.
Many thanks to Jay Borkenhagen for remote hardware access.
have administrators control them. ti(4) provides a character
device to control various other features of driver via ioctls but
users had to write their own code to manipulate these parameters.
It seems some default values for these parameters are not optimal
on today's system but leave it as it was and let administrators
change them. The following parameters could be changed:
dev.ti.%d.rx_coal_ticks
dev.ti.%d.rx_max_coal_bds
dev.ti.%d.tx_coal_ticks
dev.ti.%d.tx_max_coal_bds
dev.ti.%d.tx_buf_ratio
dev.ti.%d.stat_ticks
The interface has to be brought down and up again before a change
takes effect.
ti(4) controller supports hardware MAC counters with additional
DMA statistics. So it's doable to export these counters via
sysctl interface. Unfortunately, these counters are cumulative
such that driver have to either send an explicit clear command to
controller after extracting them or have to maintain internal
counters to get actual changes. Neither look good to me so
counters were not exported via sysctl.
Pre-allocate the memory in device attach time. While I'm here
remove unnecessary reassignment of error variable as it was already
initialized. Also added a missing driver lock in TIIOCSETTRACE
handler.
cp2103 usb-to-serial chip.
- This patch also makes the line status polling asynchronous, to reduce
the time needed to change the GPIO pins.
Submitted by: JD Louw
MFC after: 1 week
- Make it easier to port the USB code to other platforms by only using
one set of memory functions for clearing and copying memory. None of
the memory copies are overlapping. This means using bcopy() is not
required.
- Fix a compile warning when USB_HAVE_BUSDMA=0
- Add missing semicolon in avr32dci.
- Update some comments.
MFC after: 1 week
if_alloctype was used to store the origional interface type. Take
advantage of this change by removing all existing uses of if_free_type()
in favor of if_free().
MFC after: 1 Month
- fix other errors introduced when committing r226436
- add 'function' to a sentence where it makes sense
Submitted by: delphij
Submitted by: dougb
Submitted by: jhb
Approved by: dougb
Approved by: jhb
the length of frame should be treated as multiple of 4. Actual
frame length is set in the TX header. The TX header position
should be aligned on 4 byte boundary and actual frame start
position should be aligned on 4 byte boundary as well. This means
we need 4(TX header length) + 3(frame length fixup) additional free
space in TX buffer in addition to actual frame length.
Make sure TX handler check these additional bytes.
ae_tx_avail_size() returns actual free space in TX buffer to ease
the calculation of available TX buffer space in caller. While I'm
here, replace magic number to appropriate sizeof operator to
enhance readability.
This change should fix controller lockup issue happened under
certain conditions but it still does not fix watchdog timeout. It
seems the watchdog timeout is side-effect of TxS and TxD
mismatches. The root cause of TxD/TxD mismatch is not known yet but
it looks like silicon bug. I guess driver may have to reinitialize
controller whenever it sees TxS and TxD mismatches but leave it as
it was at this moment.
PR: kern/145918
I need to investigate this a little closer, but it seems that in noisy
environments the NF load takes longer than 5 * DELAY(10) and this is
messing up future NF calibrations. (The background: NF calibrations
begin at the value programmed in after the load has completed, so
if this is never loaded in, the NF calibrations only ever start at
the currently calibrated NF value, rather than starting at something
high (say -50.)
More investigation about the effect on 11n RX and calibration results
are needed.
Sponsored by: Hobnob, Inc.
The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has
issues with PCI transactions on SMP machines. This work-around enforces
that register access is serialised through a (global for now) spinlock.
This should stop the hangs people have seen with the AR5416 PCI devices
on SMP hosts.
Obtained by: Linux, Atheros
ensuring that everything is really, truly consistent.
This fixes certain cases where one will see various:
mfi0: COMMAND 0xffffffXXXXXXXXXX TIMEOUT AFTER XX SECONDS
MFC after: 3 days
Submitted by: scottl
Ok'ed by: jhb
