Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

MFC r327231,r327232:

kernel: Fix several typos and minor errors
lib: Fix several typos and minor errors

- duplicate words
- typos
- references to old versions of FreeBSD

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

[ath] commit initial bluetooth coexistence support for the MCI NICs.

This is the initial framework to call into the MCI HAL routines and drive
the basic state engine.

The MCI bluetooth coex model uses a command channel between wlan and
bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things.
This means the wlan and bluetooth chip exchange a lot more information and
signaling, even at the per-packet level. The NICs in question can share
the input LNA and output PA on the die, so they absolutely can't stomp
on each other in a silly fashion. It also allows for the bluetooth side
to signal when profiles come and go, so the driver can take appropriate
control. There's also the possibility of dynamic bluetooth/wlan duty cycle
control which I haven't yet really played with.

It configures things up with a static "wlan wins everything" coexistence,
configures up the available 2GHz channel map for bluetooth, sets a static
duty cycle for bluetooth/wifi traffic priority and drives the basics needed to
keep the MCI HAL code happy.

It doesn't do any actual coexistence except to default to "wlan wins everything",
which at least demonstrates that things do indeed work. Bluetooth inquiry frames
still trump wifi (including beacons), so that demonstrates things really do
indeed seem to work.

Tested:

* AR9462 (WB222), STA mode + bt
* QCA9565 (WB335), STA mode + bt

TODO:

* .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard.
* It doesn't do the initial BT side calibration, which requires a WLAN chip
reset. I'll fix up the reset path a bit more first before I enable that.
* The 1-ant and 2-ant configuration bits aren't being set correctly in
if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit.
* It's not enabled by default for WB222/WB225 even though I believe it now
can be - I'll chase that up in a subsequent commit.

Obtained from: Qualcomm Atheros, Linux ath9k

dev/ath: minor spelling fixes in comments.

No functional change.

Reviewed by: adrian

[ath] add LDPC capability support and LDPC RX support.

This enables LDPC receive support for the AR9300 chips that support it.
It'll announce LDPC support via net80211.

Tested:

* AR9380, STA mode
* AR9331, (to verify the HAL didn't attach it to a chip which
doesn't support LDPC.)

TODO:

* Add in net80211 machinery to make this configurable at runtime.

net80211: replace internal LE_READ_*/LE_WRITE_* macro with system
le*dec / le*enc functions.

Replace net80211 specific macros with system-wide bytestream
encoding/decoding functions:
- LE_READ_2 -> le16dec
- LE_READ_4 -> le32dec
- LE_WRITE_2 -> le16enc
- LE_WRITE_4 -> le32enc

+ drop ieee80211_input.h include, where it was included for these
operations only.

Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6030

Cleanup unnecessary semicolons from the kernel.

Found with devel/coccinelle.

Fix up the ath(4) device names for QCA chipsets.

Submitted by: Tobias Kortkamp <t@tobik.me>

[ath] migrate ioctl and busdma memory operations out into separate source files.

This should be a big no-op pass; and reduces the size of if_ath.c.

I'm hopefully soon going to take a whack at the USB support for ath(4)
and this'll require some reuse of the busdma memory code.

ath(4): begin fleshing out a "reset type" extension to force cold/warn resets.

Right now the only way to force a cold reset is:

* The HAL itself detects it's needed, or
* The sysctl, setting all resets to be cold.

Trouble is, cold resets take quite a bit longer than warm resets.

However, there are situations where a cold reset would be nice.
Specifically, after a stuck beacon, BB/MAC hang, stuck calibration results,
etc.

The vendor HAL has a separate method to set the reset reason (which is
how HAL_RESET_BBPANIC gets set) which informs the HAL during the reset path
why it occured. This is almost but not quite the same; I may eventually
unify both approaches in the future.

This commit just extends HAL_RESET_TYPE to include both status (eg BBPANIC)
and type (eg do COLD.) None of the HAL code uses it yet though; that'll
come later.

It also is a big no-op in each HAL - I need to go teach each of the HALs
about cold/warm reset through this path.

ath(4) - don't try to free buffers / return an error if we've committed
to transmit the buffer.

ath_tx_start() may manipulate/reallocate the mbuf as part of the DMA
code, so we can't expect the mbuf can be returned back to the caller.
Now, the net80211 ifnet work changed the semantics slightly so
if an error is returned here, the mbuf/reference is freed by the
caller (here, it's net80211.)

So, once we reach ath_tx_start(), we never return failure. If we fail
then we still return OK and we free the mbuf/noderef ourselves, and
we increment OERRORS.

net80211: separate mbuf cleanup from ieee80211_fragment()

* Create ieee80211_free_mbuf() which frees a list of mbufs.
* Use it in the fragment transmit path and ath / uath transmit paths.
* Call it in xmit_pkt() if the transmission fails; otherwise fragments
may be leaked.

This should be a big no-op.

Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3769

Remove the unnecessary cast.

net80211 & wireless drivers: remove duplicate defines (noop)

* IEEE80211_DIR_DSTODS(wh) -> IEEE80211_IS_DSTODS(wh).
* N(a) -> nitems(a).
* Remove LE_READ_2(p)/LE_READ_4(p) definitions (and include ieee80211_input.h instead).
* <drvname>_TXOP_TO_US(txop) -> IEEE80211_TXOP_TO_US(txop).
* Put IEEE80211_RV(v) into ieee80211_proto.h and remove local RV(v) definitions.

Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3705

Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Remove most of the references of ifp->if_softc and replace with
references to ic->ic_softc.

This is in preparation for gleb's ifnet work.

Tested:

* ath(4), STA mode
* ath(4), hostap mode
* make universe

Revert the wifi ifnet changes until things are more baked and tested.

* 286410
* 286413
* 286416

The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.

Change KPI of how device drivers that provide wireless connectivity interact
with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:

https://wiki.freebsd.org/projects/ifnet/net80211

Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.

Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix

Add a hack-around to this fatal taskqueue running whilst the NIC
is detaching.

This mostly fixes a panic - the reset path shouldn't run whilst
the NIC is being torn down.

It's not locked, so it's "mostly" ok, but most of the rest of
the driver doesn't read sc->invalid with sensible locking. Grr.

The real solution is to cleanly tear down taskqueues in the detach/suspend
phase, but ..

Use device_printf() instead of if_printf(). No functional changes.

Change three methods in struct ieee80211com, namely ic_updateslot,
ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com,
not to the ifnet.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Set ic_softc in all 802.11 drivers. Not required right now, but will be
used quite soon.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Make net80211 drivers supply their device name to the net80211 layer, so
that the latter doesn't need to go through struct ifnet to get their name.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.

Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks

Fix more ticks wrapping bugs exposed by the ticks wrapping bug check.

This symptom is "calibrations don't ever run", which may cause some
pretty spectacularly bad behaviour in noisy environments or with longer
uptimes.

Thanks to dtrace to make it easy to check if specific non-inlined functions
are getting called by things like the ANI and calibration HAL methods.
Grr.

Tested:

* AR9380, STA mode

Fix a long-standing bug with the early MAC address initialisation path,
which showed up after I started changing addresses this early.

It turns out that there's some other malarky going on behind the scenes
in the HAL and merely setting the net80211/ifp mac address this early
isn't enough. If the MAC is set from kenv at attach time, the HAL
also needs to be programmed early.

Without this, the VAP wouldn't work enough for finishing association -
probe requests would be fine as they're broadcast, but association
request would fail.

Update if_ath(4) to check for "hint.ath.X.macaddr" for an override MAC address.

This is used by the AR71xx platform code to choose a local MAC based on
the "board MAC address", versus whatever potentially invalid/garbage
values are stored in the Atheros calibration data.

Check the right value correctly.

Thanks to clang for pointing out this silliness.

Convert the callouts back to using mutexes.

I did this wrong - I should've included a state flag for each callout
to see if it was supposed to run or not. I didn't do that.
Instead, just use mutexes anyway.

Suggested by: jhb

Migrate the callouts from using mutex locks to being mpsafe with
the locks being held by the callers.

Kill callout_drain() and use callout_stop().

Add initial support for the AR9485 CUS198 / CUS230 variants.

These variants have a few differences from the default AR9485 NIC,
namely:

* a non-default antenna switch config;
* slightly different RX gain table setup;
* an external XLNA hooked up to a GPIO pin;
* (and not yet done) RSSI threshold differences when
doing slow diversity.

To make this possible:

* Add the PCI device list from Linux ath9k, complete with vendor and
sub-vendor IDs for various things to be enabled;
* .. and until FreeBSD learns about a PCI device list like this,
write a search function inspired by the USB device enumeration code;
* add HAL_OPS_CONFIG to the HAL attach methods; the HAL can use this
to initialise its local driver parameters upon attach;
* copy these parameters over in the AR9300 HAL;
* don't default to override the antenna switch - only do it for
the chips that require it;
* I brought over ar9300_attenuation_apply() from ath9k which is cleaner
and easier to read for this particular NIC.

This is a work in progress. I'm worried that there's some post-AR9380
NIC out there which doesn't work without the antenna override set as
I currently haven't implemented bluetooth coexistence for the AR9380
and later HAL. But I'd rather have this code in the tree and fix it
up before 11.0-RELEASE happens versus having a set of newer NICs
in laptops be effectively RX deaf.

Tested:

* AR9380 (STA)
* AR9485 CUS198 (STA)

Obtained from: Qualcomm Atheros, Linux ath9k

Fix up the EDMA RX setup path to correctly initialise and reset the RX FIFO.

The original code was .. well, slightly more than incorrect.

It showed up as stalled RX queues if the NIC needed to be frequently
reinitialised (eg during scans.)

This is inspired by work done by Matt Dillon over at the DragonflyBSD
project.

So:

* track when EDMA RX has been stopped and when the MAC has been reset;
* re-initialise the ring only after a reset;
* track whether RX has been stopped/started - just for debugging now;
* don't bother with the RX EOL stuff for EDMA - we don't need the
interrupt at all. We also don't need to disable/enable the interrupt
or start DMA - once new frames are pushed into the ring via the
normal RX path, it'll just restart RX DMA on its own.

Tested:

* AR9380, STA mode
* AR9380, AP mode
* AR9485, STA mode
* AR9462, STA mode

Mechanically convert to if_inc_counter().

Shut down RX before TX - in theory, this should make the chip less likely
to get upset.

The Qualcomm Atheros reference design code goes through significant
hacks to shut down RX before TX. It doesn't even try do do it in the
driver - it actually makes the DMA stop routines in the HAL shut down
RX before shutting down TX.

So, to make this work for chips that aren't the AR9380 and later, do
it in the driver. Shuffle the TX stop/drain HAL calls to be called
*after* the RX stop HAL call.

Tested:

* AR5413 (STA)
* AR5212 (STA)
* AR5416 (STA)
* AR9380 (STA)
* AR9331 (AP)
* AR9341 (AP)

TODO:

* test ar92xx series NIC and the AR5210/AR5211, in case there's something
even odder about those.

an isn't used, so eliminate it.

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

These changes prevent sysctl(8) from returning proper output,
such as:

1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

Wake up the hardware before calling ath_mode_init() in the ioctl() path.

Tested:

* AR5416, STA + powersave

Break out the multicast programming into its own hardware specific
call, which assumes the hardware is awake.

Turn ath_update_mcast() into a routine that's only called from the
net80211 layer - and it forces the hardware awake first.

This fixes a LOR from the EDMA RX path which calls ath_mode_init()
with the RX lock held - the driver lock can't also be grabbed.
This path assumes that the ath_mode_init() callers all wake up
the NIC first.

Tested:

* AR9485, STA mode, powersave

Add tracking for self-generated frames when the VAP is in sleep state.

The hardware can generate its own frames (eg RTS/CTS exchanges, other
kinds of 802.11 management stuff, especially when it comes to 802.11n)
and these also have PWRMGT flags. So if the VAP is asleep but the
NIC is in force-awake for some reason, ensure that the self-generated
frames have PWRMGT set to 1.

Now, this (like basically everything to do with powersave) is still
racy - the only way to guarantee that it's all actually consistent
is to pause transmit and let it finish before transitioning the VAP
to sleep, but this at least gets the basic method of tracking and
updating the state debugged.

Tested:

* AR5416, STA mode
* AR9380, STA mode

Bring over some initial power save management support, reset path
fixes and beacon programming / debugging into the ath(4) driver.

The basic power save tracking:

* Add some new code to track the current desired powersave state; and
* Add some reference count tracking so we know when the NIC is awake; then
* Add code in all the points where we're about to touch the hardware and
push it to force-wake.

Then, how things are moved into power save:

* Only move into network-sleep during a RUN->SLEEP transition;
* Force wake the hardware up everywhere that we're about to touch
the hardware.

The net80211 stack takes care of doing RUN<->SLEEP<->(other) state
transitions so we don't have to do it in the driver.

Next, when to wake things up:

* In short - everywhere we touch the hardware.
* The hardware will take care of staying awake if things are queued
in the transmit queue(s); it'll then transit down to sleep if
there's nothing left. This way we don't have to track the
software / hardware transmit queue(s) and keep the hardware
awake for those.

Then, some transmit path fixes that aren't related but useful:

* Force EAPOL frames to go out at the lowest rate. This improves
reliability during the encryption handshake after 802.11
negotiation.

Next, some reset path fixes!

* Fix the overlap between reset and transmit pause so we don't
transmit frames during a reset.
* Some noisy environments will end up taking a lot longer to reset
than normal, so extend the reset period and drop the raise the
reset interval to be more realistic and give the hardware some
time to finish calibration.
* Skip calibration during the reset path. Tsk!

Then, beacon fixes in station mode!

* Add a _lot_ more debugging in the station beacon reset path.
This is all quite fluid right now.
* Modify the STA beacon programming code to try and take
the TU gap between desired TSF and the target TU into
account. (Lifted from QCA.)

Tested:

* AR5210
* AR5211
* AR5212
* AR5413
* AR5416
* AR9280
* AR9285

TODO:

* More AP, IBSS, mesh, TDMA testing
* Thorough AR9380 and later testing!
* AR9160 and AR9287 testing

Obtained from: QCA

Wrap the rate control re-init code in a lock, to serialise it with
concurrent updates from any completing transmits in other threads.

This was exposed when doing power save work - net80211 is constantly
doing reassociations and it's causing the rate control state to get
blanked out. This could cause the rate control code to assert.

This should be MFCed to stable/10 as it's a stability fix.

Tested:

* AR5416, STA

MFC after: 7 days

Don't call ath_init() inside the lock.

Yes, this means that sc_invalid is slightly racy, but there are other
issues here which need fixing.

This fixes a source of eventual LORs - ath_init() grabs ATH_LOCK to do
work and releases it before it calls ieee80211_start_all().
ieee80211_start_all() will grab the net80211 comlock to iterate over
the VAPs.

TODO:

* .. I should just migrate the ieee80211_start_all() work to a
deferred task so it can be done later; it doesn't have to be
immediately done.

Tested:

* AR5416, STA mode

The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Move a lot of debugging printf's to DPRINTF.

Approved by: adrian
MFC after: 2 weeks

Use the new ieee80211_tx_complete() function.

Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver.

The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.

This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.

Tested:

* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM

Bring over the initial static bluetooth coexistence configuration
for the WB195 combo NIC - an AR9285 w/ an AR3011 USB bluetooth NIC.

The AR3011 is wired up using a 3-wire coexistence scheme to the AR9285.

The code in if_ath_btcoex.c sets up the initial hardware mapping
and coexistence configuration. There's nothing special about it -
it's static; it doesn't try to configure bluetooth / MAC traffic priorities
or try to figure out what's actually going on. It's enough to stop basic
bluetooth traffic from causing traffic stalls and diassociation from
the wireless network.

To use this code, you must have the above NIC. No, it won't work
for the AR9287+AR3012, nor the AR9485, AR9462 or AR955x combo cards.

Then you set a kernel hint before boot or before kldload, where 'X'
is the unit number of your AR9285 NIC:

# kenv hint.ath.X.btcoex_profile=wb195

This will then appear in your boot messages:

[100482] athX: Enabling WB195 BTCOEX

This code is going to evolve pretty quickly (well, depending upon my
spare time) so don't assume the btcoex API is going to stay stable.

In order to use the bluetooth side, you must also load in firmware using
ath3kfw and the binary firmware file (ath3k-1.fw in my case.)

Tested:

* AR9280, no interference
* WB195 - AR9285 + AR3011 combo; STA mode; basic bluetooth inquiries
were enough to cause traffic stalls and disassociations. This has
stopped with the btcoex profile code.

TODO:

* Importantly - the AR9285 needs ASPM disabled if bluetooth coexistence
is enabled. No, I don't know why. It's likely some kind of bug to do
with the AR3011 sending bluetooth coexistence signals whilst the device
is asleep. Since we don't actually sleep the MAC just yet, it shouldn't
be a problem. That said, to be totally correct:

+ ASPM should be disabled - upon attach and wakeup
+ The PCIe powersave HAL code should never be called

Look at what the ath9k driver does for inspiration.

* Add WB197 (AR9287+AR3012) support
* Add support for the AR9485, which is another combo like the AR9285
* The later NICs have a different signaling mechanism between the MAC
and the bluetooth device; I haven't even begun to experiment with
making that HAL code work. But it should be a lot more automatic.

* The hardware can do much more interesting traffic weighting with
bluetooth and wifi traffic. None of this is currently used.
Ideally someone would code up something to watch the bluetooth traffic
GPIO (via an interrupt) and then watch it go high/low; then figure out
what the bluetooth traffic is and adjust things appropriately.

* If I get the time I may add in some code to at least track this stuff
and expose statistics. But it's up to someone else to experiment with
the bluetooth coexistence support and add the interesting stuff (like
"real" detection of bulk, audio, etc bluetooth traffic patterns and
change wifi parameters appropriately - eg, maximum aggregate length,
transmit power, using quiet time to control TX duty cycle, etc.)

Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration in
the RX antenna field.

The AR9285/AR9485 use an LNA mixer to determine how to combine the signals
from the two antennas. This is encoded in the RSSI fields (ctl/ext) for
chain 2. So, let's use that here.

This maps RX antennas 0->3 to the RX mixer configuration used to
receive a frame. There's more that can be done but this is good enough
to diagnose if the hardware is doing "odd" things like trying to
receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's
only one antenna connected.

Tested:

* AR9285, STA mode

Fix the order of TX shutdown and reset.

* Grab the reset lock first, so any subsequent interrupt, TX, RX work
will fail

* Then shut down interrupts

* Then wait for TX/RX to finish running

At this point no further work will be running, so it's safe to do the
reset path code.

PR: kern/179232

Turn the reassociate debug print into a DPRINTF.

Migrate ath(4) to now use if_transmit instead of the legacy if_start
and if queue mechanism; also fix up (non-11n) TX fragment handling.

This may result in a bit of a performance drop for now but I plan on
debugging and resolving this at a later stage.

Whilst here, fix the transmit path so fragment transmission works.

The TX fragmentation handling is a bit more special. In order to
correctly transmit TX fragments, there's a bunch of corner cases that
need to be handled:

* They must be transmitted back to back, in the same order..
* .. ie, you need to hold the TX lock whilst transmitting this
set of fragments rather than interleaving it with other MSDUs
destined to other nodes;
* The length of the next fragment is required when transmitting, in
order to correctly set the NAV field in the current frame to the
length of the next frame; which requires ..
* .. that we know the transmit duration of the next frame, which ..
* .. requires us to set the rate of all fragments to the same length,
or make the decision up-front, etc.

To facilitate this, I've added a new ath_buf field to describe the
length of the next fragment. This avoids having to keep the mbuf
chain together. This used to work before my 11n TX path work because
the ath_tx_start() routine would be handed a single mbuf with m_nextpkt
pointing to the next frame, and that would be maintained all the way
up to when the duration calculation was done. This doesn't hold
true any longer - the actual queuing may occur at any point in the
future (think ath_node TID software queuing) so this information
needs to be maintained.

Right now this does work for non-11n frames but it doesn't at all
enforce the same rate control decision for all frames in the fragment.
I plan on fixing this in a followup commit.

RTS/CTS has the same issue, I'll look at fixing this in a subsequent
commit.

Finaly, 11n fragment support requires the driver to have fully
decided what the rate scenario setup is - including 20/40MHz,
short/long GI, STBC, LDPC, number of streams, etc. Right now that
decision is (currently) made _after_ the NAV field value is updated.
I'll fix all of this in subsequent commits.

Tested:

* AR5416, STA, transmitting 11abg fragments
* AR5416, STA, 11n fragments work but the NAV field is incorrect for
the reasons above.

TODO:

* It would be nice to be able to queue mbufs per-node and per-TID so
we can only queue ath_buf entries when it's time to assemble frames
to send to the hardware.

But honestly, we should just do that level of software queue management
in net80211 rather than ath(4), so I'm going to leave this alone for now.

* More thorough AP, mesh and adhoc testing.

* Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has
been negotiated, as we can't do software retransmission of fragments.

* .. set CLRDMASK when transmitting fragments, just to ensure.

Implement a separate hardware queue threshold for aggregate and non-aggr
traffic.

When transmitting non-aggregate traffic, we need to keep the hardware
busy whilst transmitting or small bursts in txdone/tx latency will
kill us.

This restores non-aggregate iperf performance, especially when doing
TDMA.

Tested:

* AR5416<->AR5416, TDMA
* AR5416 STA <-> AR9280 AP

Enable the use of TDMA on an 802.11n channel (with aggregation disabled,
of course.)

There's a few things that needed to happen:

* In case someone decides to set the beacon transmission rate to be
at an MCS rate, use the MCS-aware version of the duration calculation
to figure out how long the received beacon frame was.

* If TxOP enforcing is available on the hardware and we're doing TDMA,
enable it after a reset and set the TDMA guard interval to zero.
This seems to behave fine.

TODO:

* Although I haven't yet seen packet loss, the PHY errors that would be
triggered (specifically Transmit-Override-Receive) aren't enabled
by the 11n HAL. I'll have to do some work to enable these PHY errors
for debugging.

What broke:

* My recent changes to the TX queue handling has resulted in the driver
not keeping the hardware queue properly filled when doing non-aggregate
traffic. I have a patch to commit soon which fixes this situation
(albeit by reminding me about how my ath driver locking isn't working
out, sigh.)

So if you want to test this without updating to the next set of patches
that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32.

Tested:

* AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI.
I saw 30mbit/sec in both directions using a bidirectional UDP test.

Since we're now using the ah pointer, always declare it.

This fixes non-DEBUG builds.

Be (very) careful about how to add more TX DMA work.

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.

Re-add some code to exclude transmitting if we're in reset.

This fixes some "transmitting during reset" bugs that crept in after
I messed around with this part of the transmit path.

Dump out the holding buffer descriptor contents and addresses stopping DMA.

Implement my first cut at "correct" node power-save and
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

Add ALQ beacon debugging.

Improve the debugging output - use the MAC address rather than various
pointer values everywhere.

Since the node state is 100% back under the TX lock, just kill the use
of atomics.

I'll re-think this nonsense later.

Begin tidying up the reassociation and node sleep/wakeup paths.

* 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.

Make sure the holding descriptor and link pointer are both freed during
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

Fix the holding descriptor logic to actually be "right" (for values
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

Revert a previous commit - this is causing hardware errors.

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.

Re-work how transmit buffer limits are enforced - partly to fix the PR,
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

The holding buffer logic needs to be used for _all_ transmission, not
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.

Debugging changes!

* 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.

Conditionally compile this only if ATH_DEBUG is defined.

Dump the entire TXQ descriptor contents during a reset, rather than only
completed descriptors.

Initialise the chainmask fields regardless of whether 11n support
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.

Add a debug statement to log the currently chosen chainmask configuration.

.. don't know how this snuck into this commit. Sorry.

Fix compile build before anyone notices.

Print out the chainmask configuration.

Use uint32_t for fields that are fetched via ath_hal_getcapability().

Use a per-RX-queue deferred list, rather than a single deferred list for
both queues.

Since ath_rx_pkt() does multi-mbuf frame recombining based on the RX queue,
this needs to occur.

Tested:

* AR9380 (XB112), hostap mode

Always enable TXOK interrupts when setting up TX queues for EDMA NICs.

Some TX dmamap cleanups.

* Don't use BUS_DMA_ALLOCNOW for descriptor DMA maps; we never use
bounce buffers for the descriptors themselves.

* Add some XXX's to mark where the ath_buf has its mbuf ripped from
underneath it without actually cleaning up the dmamap. I haven't
audited those particular code paths to see if the DMA map is guaranteed
to be setup there; I'll do that later.

* Print out a warning if the descdma tidyup code is given some descriptors
w/ maps to free. Ideally the owner will free the mbufs and unmap
the descriptors before freeing the descriptor/ath_buf pairs, but
right now that's not guaranteed to be done.

Reviewed by: scottl (BUS_DMA_ALLOCNOW tag)

Ensure that we only call the busdma unmap/flush routines once, when
the buffer is being freed.

* When buffers are cloned, the original mapping isn't copied but it
wasn't freeing the mapping until later. To be safe, free the
mapping when the buffer is cloned.

* ath_freebuf() now no longer calls the busdma sync/unmap routines.

* ath_tx_freebuf() now calls sync/unmap.

* Call sync first, before calling unmap.

Tested:

* AR5416, STA mode

Remove an un-needed comment.

Use ATH_MAX_SCATTER rather than ATH_TXDESC.

ATH_MAX_SCATTER is used to size the ath_buf DMA segment array.
We thus should use it when checking sizes of things.

Add per-TXQ EDMA FIFO staging queue support.

Each set of frames pushed into a FIFO is represented by a list of
ath_bufs - the first ath_buf in the FIFO list is marked with
ATH_BUF_FIFOPTR; the last ath_buf in the FIFO list is marked with
ATH_BUF_FIFOEND.

Multiple lists of frames are just glued together in the TAILQ as per
normal - except that at the end of a FIFO list, the descriptor link
pointer will be NULL and it'll be tagged with ATH_BUF_FIFOEND.

For non-EDMA chipsets this is a no-op - the ath_txq frame list (axq_q)
stays the same and is treated the same.

For EDMA chipsets the frames are pushed into axq_q and then when
the FIFO is to be (re) filled, frames will be moved onto the FIFO
queue and then pushed into the FIFO.

So:

* Add a new queue in each hardware TXQ (ath_txq) for staging FIFO frame
lists. It's a TAILQ (like the normal hardware frame queue) rather than
the ath9k list-of-lists to represent FIFO entries.

* Add new ath_buf flags - ATH_TX_FIFOPTR and ATH_TX_FIFOEND.

* When allocating ath_buf entries, clear out the flag value before
returning it or it'll end up having stale flags.

* When cloning ath_buf entries, only clone ATH_BUF_MGMT. Don't clone
the FIFO related flags.

* Extend ath_tx_draintxq() to first drain the FIFO staging queue, _then_
drain the normal hardware queue.

Tested:

* AR9280, hostap
* AR9280, STA
* AR9380/AR9580 - hostap

TODO:

* Test on other chipsets, just to be thorough.

Overhaul the TXQ locking (again!) as part of some beacon/cabq timing
related issues.

Moving the TX locking under one lock made things easier to progress on
but it had one important side-effect - it increased the latency when
handling CABQ setup when sending beacons.

This commit introduces a bunch of new changes and a few unrelated changs
that are just easier to lump in here.

The aim is to have the CABQ locking separate from other locking.
The CABQ transmit path in the beacon process thus doesn't have to grab
the general TX lock, reducing lock contention/latency and making it
more likely that we'll make the beacon TX timing.

The second half of this commit is the CABQ related setup changes needed
for sane looking EDMA CABQ support. Right now the EDMA TX code naively
assumes that only one frame (MPDU or A-MPDU) is being pushed into each
FIFO slot. For the CABQ this isn't true - a whole list of frames is
being pushed in - and thus CABQ handling breaks very quickly.

The aim here is to setup the CABQ list and then push _that list_ to
the hardware for transmission. I can then extend the EDMA TX code
to stamp that list as being "one" FIFO entry (likely by tagging the
last buffer in that list as "FIFO END") so the EDMA TX completion code
correctly tracks things.

Major:

* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than
a single lock.

* Leave the software queue side of things under the ATH_TX_LOCK lock,
(continuing) to serialise things as they are.

* Add a new function which is called whenever there's a beacon miss,
to print out some debugging. This is primarily designed to help
me figure out if the beacon miss events are due to a noisy environment,
issues with the PHY/MAC, or other.

* Move the CABQ setup/enable to occur _after_ all the VAPs have been
looked at. This means that for multiple VAPS in bursted mode, the
CABQ gets primed once all VAPs are checked, rather than being primed
on the first VAP and then having frames appended after this.

Minor:

* Add a (disabled) twiddle to let me enable/disable cabq traffic.
It's primarily there to let me easily debug what's going on with beacon
and CABQ setup/traffic; there's some DMA engine hangs which I'm finally
trying to trace down.

* Clear bf_next when flushing frames; it should quieten some warnings
that show up when a node goes away.

Tested:

* AR9280, STA/hostap, up to 4 vaps (staggered)
* AR5416, STA/hostap, up to 4 vaps (staggered)

TODO:

* (Lots) more AR9380 and later testing, as I may have missed something here.
* Leverage this to fix CABQ hanling for AR9380 and later chips.
* Force bursted beaconing on the chips that default to staggered beacons and
ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being
correctly set when chaining descriptors.)

Break out the RX completion path into "FIFO check / refill" and
"complete RX frames."

The 128 entry RX FIFO is really easy to fill up and miss refilling
when it's done in the ath taskq - as that gets blocked up doing
RX completion, TX completion and other random things.

So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr()
task (and it grabs / releases locks, so now ath_intr() can't just be
a FAST handler yet!) but the locks aren't held for very long. The
completion part is done in the ath taskqueue context.

Details:

* Create a new completed frame list - sc->sc_rx_rxlist;
* Split the EDMA RX process queue into two halves - one that
processes the RX FIFO and refills it with new frames; another
that completes the completed frame list;
* When tearing down the driver, flush whatever is in the deferred
queue as well as what's in the FIFO;
* Create two new RX methods - one that processes all RX queues,
one that processes the given RX queue. When MSI is implemented,
we get told which RX queue the interrupt came in on so we can
specifically schedule that. (And I can do that with the non-MSI
path too; I'll figure that out later.)
* Convert the legacy code over to use these new RX methods;
* Replace all the instances of the RX taskqueue enqueue with a call
to a relevant RX method to enqueue one or all RX queues.

Tested:

* AR9380, STA
* AR9580, STA
* AR5413, STA

Add locking around the new holdingbf code.

Since this is being done during buffer free, it's a crap shoot whether
the TX path lock is held or not. I tried putting the ath_freebuf() code
inside the TX lock and I got all kinds of locking issues - it turns out
that the buffer free path sometimes is called with the lock held and
sometimes isn't. So I'll go and fix that soon.

Hence for now the holdingbf buffers are protected by the TXBUF lock.

Implement "holding buffers" per TX queue rather than globally.

When working on TDMA, Sam Leffler found that the MAC DMA hardware
would re-read the last TX descriptor when getting ready to transmit
the next one. Thus the whole ATH_BUF_BUSY came into existance -
the descriptor must be left alone (very specifically the link pointer
must be maintained) until the hardware has moved onto the next frame.

He saw this in TDMA because the MAC would be frequently stopping during
active transmit (ie, when it wasn't its turn to transmit.)

Fast-forward to today. It turns out that this is a problem not with
a single MAC DMA instance, but with each QCU (from 0->9). They each
maintain separate descriptor pointers and will re-read the last
descriptor when starting to transmit the next.

So when your AP is busy transmitting from multiple TX queues, you'll
(more) frequently see one QCU stopped, waiting for a higher-priority QCU
to finsh transmitting, before it'll go ahead and continue. If you mess
up the descriptor (ie by freeing it) then you're short of luck.

Thanks to rpaulo for sticking with me whilst I diagnosed this issue
that he was quite reliably triggering in his environment.

This is a reimplementation; it doesn't have anything in common with
the ath9k or the Qualcomm Atheros reference driver.

Now - it in theory doesn't apply on the EDMA chips, as long as you
push one complete frame into the FIFO at a time. But the MAC can DMA
from a list of frames pushed into the hardware queue (ie, you concat
'n' frames together with link pointers, and then push the head pointer
into the TXQ FIFO.) Since that's likely how I'm going to implement
CABQ handling in hostap mode, it's likely that I will end up teaching
the EDMA TX completion code about busy buffers, just to be "sure"
this doesn't creep up.

Tested - iperf ap->sta and sta->ap (with both sides running this code):

* AR5416 STA
* AR9160/AR9220 hostap

To validate that it doesn't break the EDMA (FIFO) chips:

* AR9380, AR9485, AR9462 STA

Using iperf with the -S <tos byte decimal value> to set the TCP client
side DSCP bits, mapping to different TIDs and thus different TX queues.

TODO:

* Make this work on the EDMA chips, if we end up pushing lists of frames
to the hardware (eg how we eventually will handle cabq in hostap/ibss
mode.)

Print out the queue flags during a TX DMA shutdown.

Add in the STBC TX/RX capability support into the HAL and driver.

The HAL already included the STBC fields; it just needed to be exposed
to the driver and net80211 stack.

This should allow single-stream STBC TX and RX to be negotiated; however
the driver and rate control code currently don't do anything with it.

Part #2 of the TX chainmask changes:

* Remove ar5416UpdateChainmasks();
* Remove the TX chainmask override code from the ar5416 TX descriptor
setup routines;
* Write a driver method to calculate the current chainmask based on the
operating mode and update the driver state;
* Call the HAL chainmask method before calling ath_hal_reset();
* Use the currently configured chainmask in the TX descriptors rather than
the hardware TX chainmasks.

Tested:

* AR5416, STA/AP mode - legacy and 11n modes

Disable debugging entries about BAW issues. I haven't seen any issues
to do with BAW tracking in the last 9 months or so.

Add an option to allow the minimum number of delimiters to be tweaked.

This is primarily for debugging purposes.

Tested:

* AR5416, STA mode

Add a new option to limit the maximum size of aggregates.
The default is to limit them to what the hardware is capable of.

Add sysctl twiddles for both the non-RTS and RTS protected aggregate
generation.

Whilst here, add some comments about stuff that I've discovered during
my exploration of the TX aggregate / delimiter setup path from the
reference driver.

Enable TX FIFO underrun interrupts. This allows the TX FIFO threshold
adjustment code to now run.

Tested:

* AR5416, STA

TODO:

* Much more thorough testing on the other chips, AR5210 -> AR9287

oops, tab!

Post interrupts in the ath alq trace.

CFG_ERR, DATA_UNDERRUN and DELIM_UNDERRUN are all flags, rather than
part of ts_status. Thus:

* make sure we decode them from ts_flags, rather than ts_status;
* make sure we decode them regardless of whether there's an error or not.

This correctly exposes descriptor configuration errors, TX delimiter
underruns and TX data underruns.

Pull out the if_transmit() work and revert back to ath_start().

My changed had some rather significant behavioural changes to throughput.
The two issues I noticed:

* With if_start and the ifnet mbuf queue, any temporary latency
would get eaten up by some mbufs being queued. With ath_transmit()
queuing things to ath_buf's, I'd only get 512 TX buffers before I
couldn't queue any further frames.

* There's also some non-zero latency involved with TX being pushed
into a taskqueue via direct dispatch. Any time the scheduler didn't
immediately schedule the ath TX task would cause extra latency.
Various 1ge/10ge drivers implement both direct dispatch (if the TX
lock can be acquired) and deferred task transmission (if the TX lock
can't be acquired), with frames being pushed into a drbd queue.
I'll have to do this at some point, but until I figure out how to
deal with 802.11 fragments, I'll have to wait a while longer.

So what I saw:

* lots of extra latency, specially under load - if the taskqueue
wasn't immediately scheduled, things went pear shaped;

* any extra latency would result in TX ath_buf's taking their sweet time
being replenished, so any further calls to ath_transmit() would drop
mbufs.

* .. yes, there's no explicit backpressure here - things are just dropped.
Eek.

With this, the general performance has gone up, but those subtle if_start()
related race conditions are back. For some reason, this is doubly-obvious
with the AR5416 NIC and I don't quite understand why yet.

There's an unrelated issue with AR5416 performance in STA mode (it's
fine in AP mode when bridging frames, weirdly..) that requires a little
further investigation. Specifically - it works fine on a Lenovo T40
(single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60
(dual core) running an early November 2012 kernel behaves very poorly.
The same hardware with an AR9160 or AR9280 behaves perfectly.

Go back to direct-dispatch of the software queue and frame TX paths
when they're being called from the TX completion handler.

Going (back) through the taskqueue is just adding extra locking and
latency to packet operations. This improves performance a little bit
on most NICs.

It still hasn't restored the original performance of the AR5416 NIC
but the AR9160, AR9280 and later NICs behave very well with this.

Tested:

* AR5416 STA (still tops out at ~ 70mbit TCP, rather than 150mbit TCP..)
* AR9160 hostap (good for both TX and RX)
* AR9280 hostap (good for both TX and RX)

Create a new TX lock specifically for queuing frames.

This now separates out the act of queuing frames from the act of running
TX and TX completion.

Methodize the process of adding the software TX queue to the taskqueue.

Move it (for now) to the TX taskqueue.

Migrate the TX sending code out from under the ath0 taskq and into
the separate ath0 TX taskq.

Whilst here, make sure that the TX software scheduler is also
running out of the TX task, rather than the ath0 taskqueue.

Make sure that the tx taskqueue is blocked/unblocked as necessary.

This allows for a little more parallelism on multi-core machines,
as well as (eventually) supporting a higher task priority for TX
tasks, allowing said TX task to preempt an already running RX or
TX completion task.

Tested:

* AR5416, AR9280 hostap and STA modes

Fix hangs (exposed by spectral scan activity) in STA mode when the
chip hangs.

* Always do a reset in ath_bmiss_proc(), regardless of whether the
hardware is "hung" or not. Specifically, for spectral scan, there's
likely a whole bunch of potential hangs that we don't (yet) recognise
in the HAL. So to avoid staying RX deaf persisting until the station
disassociates, just do a no-loss reset.

* Set sc_beacons=1 in STA mode. During a reset, the beacon programming
isn't done. (It's likely I need to set sc_syncbeacons during a hang
reset, but I digress.) Thus after a reset, there's no beacon timer
programming to send a BMISS interrupt if beacons aren't heard ..
thus if the AP disappears, you won't get notified and you'll have to
reset your interface.

This hasn't yet fixed all of the hangs that I've seen when debugging
spectral scan, but it's certainly reduced the hang frequency and it
should improve general STA stability in very noisy environments.

Tested:

* AR9280, STA mode, spectral scan off/on

PR: kern/175227

Implement frame (data) transmission using if_transmit(), rather than
if_start().

This removes the overlapping data path TX from occuring, which
solves quite a number of the potential TX queue races in ath(4).
It doesn't fix the net80211 layer TX queue races and it doesn't
fix the raw TX path yet, but it's an important step towards this.

This hasn't dropped the TX performance in my testing; primarily
because now the TX path can quickly queue frames and continue
along processing.

This involves a few rather deep changes:

* Use the ath_buf as a queue placeholder for now, as we need to be
able to support queuing a list of mbufs (ie, when transmitting
fragments) and m_nextpkt can't be used here (because it's what is
joining the fragments together)

* if_transmit() now simply allocates the ath_buf and queues it to
a driver TX staging queue.

* TX is now moved into a taskqueue function.

* The TX taskqueue function now dequeues and transmits frames.

* Fragments are handled correctly here - as the current API passes
the fragment list as one mbuf list (joined with m_nextpkt) through
to the driver if_transmit().

* For the couple of places where ath_start() may be called (mostly
from net80211 when starting the VAP up again), just reimplement
it using the new enqueue and taskqueue methods.

What I don't like (about this work and the TX code in general):

* I'm using the same lock for the staging TX queue management and the
actual TX. This isn't required; I'm just being slack.

* I haven't yet moved TX to a separate taskqueue (but the taskqueue is
created); it's easy enough to do this later if necessary. I just need
to make sure it's a higher priority queue, so TX has the same
behaviour as it used to (where it would preempt existing RX..)

* I need to re-review the TX path a little more and make sure that
ieee80211_node_*() functions aren't called within the TX lock.
When queueing, I should just push failed frames into a queue and
when I'm wrapping up the TX code, unlock the TX lock and
call ieee80211_node_free() on each.

* It would be nice if I could hold the TX lock for the entire
TX and TX completion, rather than this release/re-acquire behaviour.
But that requires that I shuffle around the TX completion code
to handle actual ath_buf free and net80211 callback/free outside
of the TX lock. That's one of my next projects.

* the ic_raw_xmit() path doesn't use this yet - so it still has
sequencing problems with parallel, overlapping calls to the
data path. I'll fix this later.

Tested:

* Hostap - AR9280, AR9220
* STA - AR5212, AR9280, AR5416

Add a new (skeleton) spectral mode manager module.

Fix typo in comment.

Submitted by: Christoph Mallon <christoph.mallon@gmx.de>

Delete the per-TXQ locks and replace them with a single TX lock.

I couldn't think of a way to maintain the hardware TXQ locks _and_ layer
on top of that per-TXQ software queuing and any other kind of fine-grained
locks (eg per-TID, or per-node locks.)

So for now, to facilitate some further code refactoring and development
as part of the final push to get software queue ps-poll and u-apsd handling
into this driver, just do away with them entirely.

I may eventually bring them back at some point, when it looks slightly more
architectually cleaner to do so. But as it stands at the present, it's
not really buying us much:

* in order to properly serialise things and not get bitten by scheduling
and locking interactions with things higher up in the stack, we need to
wrap the whole TX path in a long held lock. Otherwise we can end up
being pre-empted during frame handling, resulting in some out of order
frame handling between sequence number allocation and encryption handling
(ie, the seqno and the CCMP IV get out of sequence);

* .. so whilst that's the case, holding the lock for that long means that
we're acquiring and releasing the TXQ lock _inside_ that context;

* And we also acquire it per-frame during frame completion, but we currently
can't hold the lock for the duration of the TX completion as we need
to call net80211 layer things with the locks _unheld_ to avoid LOR.

* .. the other places were grab that lock are reset/flush, which don't happen
often.

My eventual aim is to change the TX path so all rejected frame transmissions
and all frame completions result in any ieee80211_free_node() calls to occur
outside of the TX lock; then I can cut back on the amount of locking that
goes on here.

There may be some LORs that occur when ieee80211_free_node() is called when
the TX queue path fails; I'll begin to address these in follow-up commits.

Call if_free() with the correct vnet context if and only if ifp_vnet
isn't NULL.

If the attach fails prematurely and there's no if_vnet context, calling
CURVNET_SET(ifp->if_vnet) is going to dereference a NULL pointer.

ALQ logging enhancements:

* upon setup, tell the alq code what the chip information is.
* add TX/RX path logging for legacy chips.
* populate the tx/rx descriptor length fields with a best-estimate.
It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled)
but it'll do for now.

Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a
partial solution to fixing crashes during attach when the attach fails.
There are other attach failures that I have to deal with; those'll come
later.

Correctly fix the 'scan during STA mode' crash.

Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ
is defined.

This will unbreak ATH_DEBUG builds.

Disable my software queue TIM and PS handling for now.

ps-poll is totally broken in its current form.

This should unbreak things enough to let people use PS-POLL devices,
but leave it in place for me to finish PS-POLL handling.

Add a new HAL call to extract out the HAL enterprise bits from the
AR9300 HAL.

I give up - introduce a TX lock to serialise TX operations.

I've tried serialising TX using queues and such but unfortunately
due to how this interacts with the locking going on elsewhere in the
networking stack, the TX task gets delayed, resulting in quite a
noticable throughput loss:

* baseline TCP for 2x2 11n HT40 is ~ 170mbit/sec;
* TCP for TX task in the ath taskq, with the RX also going on - 80mbit/sec;
* TCP for TX task in a separate, second taskq - 100mbit/sec.

So for now I'm going with the Linux wireless stack approach - lock tx
early. The linux code does in the wireless stack, before the 802.11
state stuff happens and before it's punted to the driver.
But TX locking needs to also occur at the driver layer as the TX
completion code _also_ begins to drain the ifnet TX queue.

Whilst I'm here, add some KTR traces for the TX path.

Note:

* This really should be done at the net80211 layer (as well, at least.)
But that'll have to wait for a little more thought to happen.

Begin fleshing out some software queue awareness for TIM handling with
the power save queue.

* introduce some new ATH_NODE lock protected fields, tracking the
net80211 psq and TIM state;
* when doing buffer transitions - ie, when sending and completing
buffers - check the state of the SWQ and update the TIM appropriately.
* when clearing the TIM bit, if the SWQ is not empty then delay clearing
it.

This is racy, but it's no less racy than the current net80211 power
save queue management code. Specifically, with multiple TX threads,
it's quite plausible that parallel state updates will race and the
TIM will be left in an inconsistent state. I'll address that in
a follow-up commit.

Add a temporary (for values of "temporary") work around for hotplug
support with ath(4) and VIMAGE.

Right now the VIMAGE code doesn't supply a default vnet context during:

* hotplug attach;
* any device detach.

It special cases kldload/boot time probing (by setting the context to
vnet0) but that doesn't occur when probing devices during a bus rescan -
eg, adding a cardbus card.

These will eventually go away when the VIMAGE support extends to providing
default contexts to hotplug attach/detach.

Push the actual TX processing into the ath taskqueue, rather than having
it run out of multiple concurrent contexts.

Right now the ath(4) TX processing is a bit hairy. Specifically:

* It was running out of ath_start(), which could occur from multiple
concurrent sending processes (as if_start() can be started from multiple
sending threads nowdays.. sigh)

* during RX if fast frames are enabled (so not really at the moment, not
until I fix this particular feature again..)

* during ath_reset() - so anything which calls that

* during ath_tx_proc*() in the ath taskqueue - ie, TX is attempted again
after TX completion, as there's now hopefully some ath_bufs available.

* Then, the ic_raw_xmit() method can queue raw frames for transmission
at any time, from any net80211 TX context. Ew.

This has caused packet ordering issues in the past - specifically,
there's absolutely no guarantee that preemption won't occuring _during_
ath_start() by the TX completion processing, which will call ath_start()
again. It's a mess - 802.11 really, really wants things to be in
sequence or things go all kinds of loopy.

So:

* create a new task struct for TX'ing;
* make the if_start method simply queue the task on the ath taskqueue;
* make ath_start() just be called by the new TX task;
* make ath_tx_kick() just schedule the ath TX task, rather than directly
calling ath_start().

Now yes, this means that I've taken a step backwards in terms of
concurrency - TX -and- RX now occur in the same single-task taskqueue.
But there's nothing stopping me from separating out the TX / TX completion
code into a separate taskqueue which runs in parallel with the RX path,
if that ends up being appropriate for some platforms.

This fixes the CCMP/seqno concurrency issues that creep up when you
transmit large amounts of uni-directional UDP traffic (>200MBit) on a
FreeBSD STA -> AP, as now there's only one TX context no matter what's
going on (TX completion->retry/software queue,
userland->net80211->ath_start(), TX completion -> ath_start());
but it won't fix any concurrency issues between raw transmitted frames
and non-raw transmitted frames (eg EAPOL frames on TID 16 and any other
TID 16 multicast traffic that gets put on the CABQ.) That is going to
require a bunch more re-architecture before it's feasible to fix.

In any case, this is a big step towards making the majority of the TX
path locking irrelevant, as now almost all TX activity occurs in the
taskqueue.

Phew.

Initialise an uninitialised variable.

Pause and unpause the software queues for a given node based on the
net80211 node power save state.

* Add an ATH_NODE_UNLOCK_ASSERT() check
* Add a new node field - an_is_powersave
* Pause/unpause the queue based on the node state
* Attempt to handle net80211 concurrency issues so the queue
doesn't get paused/unpaused more than once at a time from
the net80211 power save code.

Whilst here (and breaking my usual rule), set CLRDMASK when a queue
is unpaused, regardless of whether the queue has some pending traffic.
This means the first frame from that TID (now or later) will hvae
CLRDMASK set.

Also whilst here, bump the swretrymax counters whenever the
filtered frames code expires a frame. Again, breaking my rule, but
this is just a statistics thing rather than a functional change.

This doesn't fix ps-poll (but it doesn't break it too much worse
than it is at the present) or correcting the TID updates.
That's next on the list.

Tested:
* AR9220 AP (Atheros AP96 reference design)
* Macbook Pro and LG Optimus 1 Android phone, both setting
and clearing power save state (but not using PS-POLL.)

Migrate the ath(4) KTR logging to use an ATH_KTR() macro.

This should eventually be unified with ATH_DEBUG() so I can get both
from one macro; that may take some time.

Add some new probes for TX and TX completion.

Remove TDMA #define entries from if_ath.c; they now exist in if_ath_tdma.h.

There's no nede to allocate a DMA map just before calling bus_dmamem_alloc().

In fact, bus_dmamem_alloc() happily NULLs the dmat pointer passed in,
before replacing it with its own.

This fixes a MIPS crash when kldload'ing if_ath/if_ath_pci -
bus_dmamap_destroy() was passed in a NULL dmat pointer and was doing
all kinds of very bad things.

Reviewed by: scottl

Implement a sequential descriptor ID value and stuff it in the ath_buf.

This will be used by the EDMA TX code to assign descriptor IDs in order
to provide some debugging.

Break out the TX completion code into a separate function, so it can be
re-used by the upcoming EDMA TX completion code.

Make ath_stoptxdma() public, again so the EDMA TX code can use it.

Don't check for the TXQ bitmap in the ISR when doing EDMA work as it
doesn't apply for EDMA.

Revert the ath_tx_draintxq() method, and instead teach it the minimum
necessary to "do" EDMA.

It was just using the TX completion status for logging information about
the descriptor completion. Since with EDMA we don't know this without
checking the TX completion FIFO, we can't provide this information.
So don't.

Break out ath_draintxq() into a method and un-methodize ath_tx_processq().

Now that I understand what's going on with this, I've realised that
it's going to be quite difficult to implement a processq method in
the EDMA case. Because there's a separate TX status FIFO, I can't
just run processq() on each EDMA TXQ to see what's finished.
i have to actually run the TX status queue and handle individual
TXQs.

So:

* unmethodize ath_tx_processq();
* leave ath_tx_draintxq() as a method, as it only uses the completion status
for debugging rather than actively completing the frames (ie, all frames
here are failed);
* Methodize ath_draintxq().

The EDMA ath_draintxq() will have to take care of running the TX
completion FIFO before (potentially) freeing frames in the queue.

The only two places where ath_tx_draintxq() (on a single TXQ) are used:

* ath_draintxq(); and
* the CABQ handling in the beacon setup code - it drains the CABQ before
populating the CABQ with frames for a new beacon (when doing multi-VAP
operation.)

So it's quite possible that once I methodize the CABQ and beacon handling,
I can just drop ath_tx_draintxq() in its entirety.

Finally, it's also quite possible that I can remove ath_tx_draintxq()
in the future and just "teach" it to not check the status when doing
EDMA.

Extend the beacon code slightly to support AP mode beaconing for the
EDMA HAL hardware.

* The EDMA HAL code assumes the nexttbtt and intval values are in TU/8
units, rather than TU. For now, just "hack" around that here, at least
until I code up something to translate it in the HAL.
* Setup some different TXQ flags for EDMA hardware.
* The EDMA HAL doesn't support setting the first rate series via
ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario()
is always required. So for now, just do an 11n rate series setup
for EDMA beacon frames.

This allows my AR9380 to successfully transmit beacon frames.

However, CABQ TX and all normal data frame TX and TX completion is
still not functional and will require some more significant code churn
to make work.

Allow 802.11n hardware to support multi-rate retry when RTS/CTS is
enabled.

The legacy (pre-802.11n) hardware doesn't support this - although
the AR5212 era hardware supports MRR, it doesn't have all the bits
needed to support MRR + RTS/CTS. The AR5416 and later support
a packet duration and RTS/CTS flags per rate scenario, so we should
support it.

Tested:

* AR9280, STA

PR: kern/170302

Migrate some more TX side setup routines to be methods.

Fix breakage introduced in r238824 - correctly calculate the descriptor
wrapping.

The previous code was only wrapping descriptor "block" boundaries rather
than individual descriptors. It sounds equivalent but it isn't.

r238824 changed the descriptor allocation to enforce that an individual
descriptor doesn't wrap a 4KiB boundary rather than the whole block
of descriptors. Eg, for TX descriptors, they're allocated in blocks
of 10 descriptors for each ath_buf (for scatter/gather DMA.)

Add a missing call to ath_txdma_teardown().

Modify ath_descdma_cleanup() to handle ath_descdma instances with no
buffers.

ath_descdma is now being used for things other than the classical
combination of ath_buf + ath_desc allocations. In this particular case,
don't try to free and blank out the ath_buf list if it's not passed in.

Migrate the descriptor allocation function to not care about the number
of buffers, only the number of descriptors.

This involves:

* Change the allocation function to not use nbuf at all;
* When calling it, pass in "nbuf * ndesc" to correctly update how many
descriptors are being allocated.

Whilst here, fix the descriptor allocation code to correctly allocate
a larger buffer size if the Merlin 4KB WAR is required. It overallocates
descriptors when allocating a block that doesn't ever have a 4KB boundary
being crossed, but that can be fixed at a later stage.

Refactor out the descriptor allocation code from the buffer allocation
code.

The TX EDMA completion path is going to need descriptors allocated but
not any buffers. This code will form the basis for that.

Modify ath_descdma_setup() to take a descriptor size parameter.

The AR9300 and later descriptors are 128 bytes, however I'd like to make
sure that isn't used for earlier chips.

* Populate the TX descriptor length field in the softc with
sizeof(ath_desc)

* Use this field when allocating the TX descriptors

* Pre-AR93xx TX/RX descriptors will use the ath_desc size; newer ones will
query the HAL for these sizes.

Begin separating out the TX DMA setup in preparation for TX EDMA support.

* Introduce TX DMA setup/teardown methods, mirroring what's done in
the RX path.

Although the TX DMA descriptor is setup via ath_desc_alloc() /
ath_desc_free(), there TX status descriptor ring will be allocated
in this path.

* Remove some of the TX EDMA capability probing from the RX path and
push it into the new TX EDMA path.

Begin modifying the descriptor allocation functions to support a variable
sized TX descriptor.

This is required for the AR93xx EDMA support which requires 128 byte
TX descriptors (which is significantly larger than the earlier
hardware.)

Enable the basic node-based rate control statistics via an ioctl().

Ensure that error is set.

Noticed by: rui

Don't free the descriptor allocation/map if it doesn't exist.

I missed this in my previous commit.

Fix EDMA RX to actually work without panicing the machine.

I was setting up the RX EDMA buffer to be 4096 bytes rather than the
RX data buffer portion. The hardware was likely getting very confused
and DMAing descriptor portions into places it shouldn't, leading to
memory corruption and occasional panics.

Whilst here, don't bother allocating descriptors for the RX EDMA case.
We don't use those descriptors. Instead, just allocate ath_buf entries.

Flip on EDMA RX of both HP and LP queue frames.

Yes, this is in the legacy interrupt path. The NIC does support
MSI but I haven't yet sat down and written that code.

Migrate the ATH_KTR_* fields out to if_ath_debug.h .

Further preparations for the RX EDMA support.

Break out the DMA descriptor setup/teardown code into a method.
The EDMA RX code doesn't allocate descriptors, just ath_buf entries.

Begin abstracting out the RX path in preparation for RX EDMA support.

The RX EDMA support requires a modified approach to the RX descriptor
handling.

Specifically:

* There's now two RX queues - high and low priority;
* The RX queues are implemented as FIFOs; they're now an array of pointers
to buffers;
* .. and the RX buffer and descriptor are in the same "buffer", rather than
being separate.

So to that end, this commit abstracts out most of the RX related functions
from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't
updated, primarily because I haven't yet fleshed out what it should look
like.

Whilst I'm here, create a set of matching but mostly unimplemented EDMA
stubs.

Tested:

* AR9280, station mode

TODO:

* Thorough AP and other mode testing for non-EDMA chips;
* Figure out how to allocate RX buffers suitable for RX EDMA, including
correctly setting the mbuf length to compensate for the RX descriptor
and completion status area.

Shuffle these initialisations to where they should be.

Introduce an optional ath(4) radiotap vendor extension.

This includes a few new fields in each RXed frame:

* per chain RX RSSI (ctl and ext);
* current RX chainmask;
* EVM information;
* PHY error code;
* basic RX status bits (CRC error, PHY error, etc).

This is primarily to allow me to do some userland PHY error processing
for radar and spectral scan data. However since EVM and per-chain RSSI
is provided, others may find it useful for a variety of tasks.

The default is to not compile in the radiotap vendor extensions, primarily
because tcpdump doesn't seem to handle the particular vendor extension
layout I'm using, and I'd rather not break existing code out there that
may be (badly) parsing the radiotap data.

Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel
configuration file to enable these options.

After some discussion with bschmidt@, it's likely better to just go
through ieee80211_suspend_all() and ieee80211_resume_all().
All the other wireless drivers are doing that particular dance.

PR: kern/169084

oops, remove this, it wasn't supposed to be committed.

Fix build.

Shuffle some more fields in ath_buf so it's not too big.

This shaves off 20 bytes - from 288 bytes to 268 bytes.

However, it's still too big.

Convert ath(4) to just use ieee80211_suspend_all() and ieee80211_resume_all().

The existing code tries to use the beacon miss timer to signal that the AP
has gone away. Unfortunately this doesn't seem to be behaving itself.
I'll try to investigate why this is for the sake of completeness.

The result is the STA will stay "associated" to the AP it was associated
with when it suspended. It never receives a bmiss notification so it
never tries reassociating.

PR: kern/169084

Disable BGSCAN for 802.11n for now. Until scanning during traffic is
fixed for 802.11n TX, this needs to be disabled or users wlil see randomly
hanging aggregation sessions.

Whilst I'm here, remove the warning about 802.11n being full of dragons.
It's nowhere near that scary now.

Implement a global (all non-mgmt traffic) TX ath_buf limitation when
ath_start() is called.

This (defaults to 10 frames) gives for a little headway in the TX ath_buf
allocation, so buffer cloning is still possible.

This requires a lot omre experimenting and tuning.

It also doesn't stop a node/TID from consuming all of the available
ath_buf's, especially when the node is going through high packet loss
or only talking at a low TX rate. It also doesn't stop a paused TID
from taking all of the ath_bufs. I'll look at fixing that up in subsequent
commits.

PR: kern/168170

Implement a separate, smaller pool of ath_buf entries for use by management
traffic.

* Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately.
* Create an enum to represent buffer types in the API.
* Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum.
* Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT.
This may not be very useful.
* Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer
is a mgmt buffer and should go back onto the mgmt free list.
* Extend 'txagg' to include debugging output for both normal and mgmt txbufs.
* When checking/clearing ATH_BUF_BUSY, do it on both TX pools.

Tested:

* STA mode, with heavy UDP injection via iperf. This filled the TX queue
however BARs were still going out successfully.

TODO:

* Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right
type is being allocated and freed on the appropriate list. That'd save
a write operation (to bf->bf_flags) on each buffer alloc/free.

* Test on AP mode, ensure that BAR TX and probe responses go out nicely
when the main TX queue is filled (eg with paused traffic to a TID,
awaiting a BAR to complete.)

PR: kern/168170

Replace the direct sc_txbuf manipulation with a pair of functions.

This is preparation work for having a separate ath_buf queue for
management traffic.

PR: kern/168170

Add a new ioctl for ath(4) which returns the aggregate statistics.

Mostly revert previous commit(s). After doing a bunch of local testing,
it turns out that it negatively affects performance. I'm stil investigating
exactly why deferring the IO causes such negative TCP performance but
doesn't affect UDP preformance.

Leave the ath_tx_kick() change in there however; it's going to be useful
to have that there for if_transmit() work.

PR: kern/168649

Create a function - ath_tx_kick() - which is called where ath_start() is
called to "kick" along TX.

For now, schedule a taskqueue call.

Later on I may go back to the direct call of ath_rx_tasklet() - but for
now, this will do.

I've tested UDP and TCP TX. UDP TX still achieves 240MBit, but TCP
TX gets stuck at around 100MBit or so, instead of the 150MBit it should
be at. I'll re-test with no ACPI/power/sleep states enabled at startup
and see what effect it has.

This is in preparation for supporting an if_transmit() path, which will
turn ath_tx_kick() into a NUL operation (as there won't be an ifnet
queue to service.)

Tested:
* AR9280 STA

TODO:
* test on AR5416, AR9160, AR928x STA/AP modes

PR: kern/168649

Migrate the TX path to a taskqueue for now, until a better way of
implementing parallel TX and TX/RX completion can be done without
simply abusing long-held locks.

Right now, multiple concurrent ath_start() entries can result in
frames being dequeued out of order. Well, they're dequeued in order
fine, but if there's any preemption or race between CPUs between:

* removing the frame from the ifnet, and
* calling and runningath_tx_start(), until the frame is placed on a
software or hardware TXQ

Then although dequeueing the frame is in-order, queueing it to the hardware
may be out of order.

This is solved in a lot of other drivers by just holding a TX lock over
a rather long period of time. This lets them continue to direct dispatch
without races between dequeue and hardware queue.

Note to observers: if_transmit() doesn't necessarily solve this.
It removes the ifnet from the main path, but the same issue exists if
there's some intermediary queue (eg a bufring, which as an aside also
may pull in ifnet when you're using ALTQ.)

So, until I can sit down and code up a much better way of doing parallel
TX, I'm going to leave the TX path using a deferred taskqueue task.
What I will likely head towards is doing a direct dispatch to hardware
or software via if_transmit(), but it'll require some driver changes to
allow queues to be made without using the really large ath_buf / ath_desc
entries.

TODO:

* Look at how feasible it'll be to just do direct dispatch to
ath_tx_start() from if_transmit(), avoiding doing _any_ intermediary
serialisation into a global queue. This may break ALTQ for example,
so I have to be delicate.

* It's quite likely that I should break up ath_tx_start() so it
deposits frames onto the software queues first, and then only fill
in the 802.11 fields when it's being queued to the hardware.
That will make the if_transmit() -> software queue path very
quick and lightweight.

* This has some very bad behaviour when using ACPI and Cx states.
I'll do some subsequent analysis using KTR and schedgraph and file
a follow-up PR or two.

PR: kern/168649

oops - ath_hal_disablepcie is actually destined for another purpose,
not to disable the PCIe PHY in prepration for reset.

Extend the enablepci method to have a "poweroff" flag, which if equal
to true means the hardware is about to go to sleep.

Prepare for improved (read: pcie) suspend/resume support.

* Flesh out the pcie disable method for 11n chips, as they were defaulting
to the AR5212 (empty) PCIe disable method.

* Add accessor macros for the HAL PCIe enable/disable calls.

* Call disable on ath_suspend()

* Call enable on ath_resume()

NOTE:

* This has nothing to do with the NIC sleep/run state - the NIC still
will stay in network-run state rather than supporting network-sleep
state. This is preparation work for supporting correct suspend/resume
WARs for the 11n PCIe NICs.

TODO:

* It may be feasible at this point to keep the chip powered down during
initial probe/attach and only power it up upon the first configure/reset
pass. This however would require correct (for values of "correct")
tracking of the NIC power configuration state from the driver and that
just isn't attempted at the moment.

Tested:

* AR9280 on my Lenovo T60, but with no suspend/resume pass (yet).

Migrate most of the beacon handling functions out to if_ath_beacon.c.

This is also in preparation for supporting AR9300 and later NICs.

Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c.

There's some TX path TDMA code in if_ath_tx.c which should be migrated
out, but first I should likely try and verify/fix/repair the TDMA support
in 9.x and -HEAD.

Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch].

* migrate the rx processing out into if_ath_rx.c
* migrate the TSF functions into if_ath_tsf.h, as inlines

This is in prepration for supporting the EDMA RX routines, required to
support the AR93xx series NICs.

TODO:

* ath_start() shouldn't be private, but it's called as part of
the RX path. I should likely migrate ath_rx_tasklet() back into
if_ath.c and then return this to be 'static'. The RX code really
shouldn't need to see TX routines (and vice versa.)

* ath_beacon_* should be in if_ath_beacon.[ch].

* ath_tdma_* should be in if_ath_tdma.[ch] ...

Re-enable this particular DELAY() for now, at least until the
TX and RX PCU stop/drain routines have been thoroughly debugged.

It's also very likely that I should add hooks back up to the
interface glue (if_ath_pci / if_ath_ahb) to do any relevant
bus flushes that are required. A WMAC DDR flush may be required
for the AR9130 SoC.

Add a comment about this DELAY(), I'm not sure whether it's supposed
to be for a DDR/FIFO flush or something else.

Run the fatal proc as a proc, rather than where it currently is.

Otherwise the reset path will sleep, which it can't do in this context.

Fix the default, non-superg compile.

Pointy-hat-to: adrian

Fix compilation with IEEE80211_ENABLE_SUPERG defined.

PR: kern/164951

Blank the aggregate stats whenever the zero ioctl is called.

Squirrel away SYNC interrupt debugging if it's enabled in the HAL.

Bus errors will show up as various SYNC interrupts which will be passed
back up to ath_intr().

Revert this for now - it may work for -8 and -9 and -HEAD, but not
"-HEAD driver + net80211 on -9 kernel."

I'll figure this out at some later stage.

* Since the API changed along the -CURRENT path (december 2011),
add a FreeBSD_version check. It should work fine for compiling
on -HEAD, 9.x and 8.x.

* Conditionally compile the 11n options only when 11n is enabled.

The above changes allow the ath(4) driver to compile and run on
8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled.

I've done a test against the net80211 and tools in 8.1-RELEASE.
The NIC used in testing is the AR2427 in an EEEPC.

Just to be clear - this change is to allow the -HEAD ath/hal/rate
code to run on 9.x _and_ 8.x with no source changes. However,
when running on earlier kernels, it should only be used for legacy
mode. (Don't define ATH_ENABLE_11N.)

Store away the RTS aggregate limit from the HAL.

This will be used by some upcoming code to ensure that aggregates
are enforced to be a certain size. The AR5416 has a limitation on
RTS protected aggregates (8KiB).

Remove duplicate txflags field from ath_buf.

rename bf_state.bfs_flags to bf_state.bfs_txflags, as that is what
it effectively is.

Disable the HWQ contents upon a TX queue reset, rather than a TX queue flush.

This is designed to assist in figuring out what the hardware state is
when something like a queue hang has occured.

oops, add a missing lock.

Defer the rescheduling of TID -> TXQ frames in some instances.

Right now ath_txq_sched() is mainly called from the TX ath_tx_processq()
routine, which is (mostly) done as part of the taskqueue. It shouldn't
be called outside the taskqueue.

But now that I'm about to flip back on BAR TX, I'm going to start
stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths.
What I don't want to have happen is a reschedule of the TID traffic
_during_ the completion of TX frames.

Ideally I'd like to have a way to flag back up to the processing code
that the current hardware queue should be rechecked for software TID
queue frames. But for now, this should suffice for the BAR TX case.

I may eventually delete this code once I've brought some further
sanity to the general TX queue/completion path.

Add the new channel width change field to the ath(4) driver.

This is not entirely correct as it simply resets the channel, flushing
whatever is in the TX/RX queue. This can and will break aggregation
BAW tracking. But the alternative (HT40 frames being sent with the hardware
in HT20 mode) is even worse.

There's still a small window between the htinfo being received (and the ni_chw
field being updated) which could cause problems. I'll look at fleshing this
out in follow-up commits.

PR: kern/166286

Fix a couple of debugging outputs.

* printf -> device_printf
* print the buffer pointer and sequence number for any buffer that wasn't
correctly tidied up before it was freed. This is to aid in some
current SMP TX debugging stalls.

PR: kern/166190

Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included.

Stick the if_drv_flags access (check and modify) behind the ifq lock.

Although access to the flags to check/set OACTIVE is racy due to how
the default if_start() function works, this should remove any races
with read/modify/write between threads.

Don't flood the cabq/mcastq with frames.

In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:

* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.

This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.

It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.

I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.

PR: kern/165895

Should the mcast queue be locked here? In case more multicast traffic
comes along?

This commit was brought to you via an Atheros AR5210, associated to an 3x3
HT40 11na access point. Yes, this driver still works with it.

Insert extra paranoia into the ath(4) driver.

This function must be called with both the source and destination TXQs
locked or things will get hairy.

I added this as part of some debugging in a PR but it turned out to not
be the cause. I still think it's -correct- so, here it is.

Wrap another ATH_LOCK around the scanning flag.

PR: kern/163318

Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddling
behind the PCU lock.

sc_scanning is being checked without ATH_LOCK behind held and could
in theory run from multiple threads.

Attempt to further fix some of the concurrency/reset issues that occur.

* ath_reset() is being called in softclock context, which may have the
thing sleep on a lock. To avoid this, since we really _shouldn't_
be sleeping on any locks, break out the no-loss reset path into a tasklet
and call that from:

+ ath_calibrate()
+ ath_watchdog()

This has the added advantage that it'll end up also doing the frame
RX cleanup from within the taskqueue context, rather than the softclock
context.

* Shuffle around the taskqueue_block() call to be before we grab the lock
and disable interrupts.

The trouble here is that taskqueue_block() doesn't block currently
queued (but not yet running) tasks so calling it doesn't guarantee
no further tasks (that weren't running on _A_ CPU at the time of this
call) will complete. Calling taskqueue_drain() on these tasks won't
work because if any _other_ thread calls taskqueue_enqueue() for whatever
reason, everything gets very angry and stops working.

This slightly changes the race condition enough to let ath_rx_tasklet()
run before we try disabling it, and thus quietens the warnings a bit.

The (more) true solution will be doing something like the following:

* having a taskqueue_blocked mask in ath_softc;
* having an interrupt_blocked mask in ath_softc;
* only calling taskqueue_drain() on each individual task _after_ the
lock has been acquired - that way no further tasklet scheduling
is going to occur.
* Then once the tasks have been blocked _and_ the interrupt has been
disabled, call taskqueue_drain() on each, ensuring that anything
that _was_ scheduled or running is removed.

The trouble is if something calls taskqueue_enqueue() on a task
after taskqueue_blocked() has been called but BEFORE taskqueue_drain()
has been called, ta_pending will be set to 1 and taskqueue_drain()
will sit there stuck in msleep() until you hard-kill the machine.

PR: kern/165382
PR: kern/165220

Use the passed-in channel rather than ic->ic_curchan.

I'm not sure _why_ the ic is NULL here, but I've seen it occasionally do
this after I've been tinkering with things for a while. It ends up
crashing in a call to ath_chan_set() via the net80211 scan code and scan
task.

Try to ensure that ieee80211_newstate() and the vap_newstate methods
hold the lock.

This is part of my series of work to try and capture when net80211
locking isn't.

ObNote: it'd be nice to be able to mark a lock as "assert if the lock
is dropped", so I could capture functions which decide that dropping
and reacquiring the lock is a good idea (without re-checking the
sanity of the state protected by the lock.)

Enforce some consistent ordering and handling of interrupt disable/enable
with RX/TX halting.

* Always disable/enable interrupts during a channel change, just to simply
things.

* Ensure that the ath taskqueue has completed and is paused before
continuing.

This dramatically reduces the instances of overlapping RX and reset
conditions.

PR: kern/165220

Begin breaking out the txrx stop code into a locked and unlocked variant.

PR: kern/165220

Attempt to address some potential vap->iv_bss race conditions.

There are unfortunately a number of situations where vap->iv_bss is changed
or freed by some code in net80211. Because multiple threads can concurrently
be doing work (and the vap->iv_bss access isn't at all done behind any kind
of lock), it's quite possible that:

* a change will occur in one thread - eg, by a call through
ieee80211_sta_join1();
* a state change occurs in another thread - eg an RX is scheduled
in the ath tasklet and it calls ieee80211_input_mimo_all(), which
does dereference vap->iv_bss;
* these two executing concurrently, causing things to explode.

Another instance is ath_beacon_alloc() which takes an ieee80211_node *.
It's called with the vap->iv_bss node from ath_newstate(). If the node has
changed in the meantime (say it's been freed elsewhere) the reference
that it grabbed _before_ refcounting it may be stale.

I would _prefer_ that these sorts of things were serialised somewhere but
that may be a bit much to ask. Instead, the best we can (currently) hope
is that the underlying bss node is still (somewhat) valid.

There is a related PR (kern/164382) described by the first case above.
That should be fixed by properly serialising the RX path and reset path
so an RX can't occur at the same time as the vap free/shutdown path.

This is inspired by some related fixes in r212127.

PR: kern/165060

.. oops, use the right chainmask.

Add in a new driver feature to allow the TX and RX chainmask to be
overridden at attach time.

Some 802.11n NICs may only have one physical antenna connected.
The radios will be very upset if you try enabling radios which aren't
connected to antennas.

This allows hints to override the TX and RX chainmask.

These hints are:

hint.ath.X.rx_chainmask
hint.ath.X.tx_chainmask

They can be set at either boot time or in kenv before the module is loaded.

This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc.

Sponsored by: Hobnob, Inc.

Correctly fetch the TX/RX stream count from the HAL.

Pointy hat to: me

Two changes from my DFS work:

* Grab the net80211com lock when calling ieee80211_dfs_notify_radar().
* Use the tsf extend function to turn the 64 bit base TSF into a per-
frame 64 bit TSF. This will improve radiotap logging (which will
now have a (more) correct per-frame TSF, rather then the single TSF64
value read at the beginning of ath_rx_proc().

Add some node debugging which has helped me track down which particular
concurrent vap->iv_bss free issues have been occuring.

Re-enable the PHY radar error frames if sc_dodfs is set.

This was messing up a local port of the atheros reference radar detection
code; I'll fix the port instead.

Flesh out configurable hardware based LED blinking.

The hardware (MAC) LED blinking involves a few things:

* Selecting which GPIO pins map to the MAC "power" and "network" lines;
* Configuring the MAC LED state (associated, scanning, idle);
* Configuring the MAC LED blinking type and speed.

The AR5416 HAL configures the normal blinking setup - ie, blink rate based
on TX/RX throughput. The default AR5212 HAL doesn't program in any
specific blinking type, but the default of 0 is the same.

This code introduces a few things:

* The hardware led override is configured via sysctl 'hardled';
* The MAC network and power LED GPIO lines can be set, or left at -1
if needed. This is intended to allow only one of the hardware MUX
entries to be configured (eg for PCIe cards which only have one LED
exposed.)

TODO:

* For AR2417, the software LED blinking involves software blinking the
Network LED. For the AR5416 and later, this can just be configured
as a GPIO output line. I'll chase that up with a subsequent commit.

* Add another software LED blink for "Link", separate from "activity",
which blinks based on the association state. This would make my
D-Link DWA-552 have consistent and useful LED behaviour (as they're
marked "Link" and "Activity."

* Don't expose the hardware LED override unless it's an AR5416 or later,
as the previous generation hardware doesn't have this multiplexing
setup.

Setup the initial LED state on attach and resume.

Some of the NICs I have here power up with the LEDs blinking, which is
incorrect. The blinking should only occur when the NIC is attempting
to associate.

* On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC
LED but leaves the "Network" MAC LED the way it is.

* On resume, also init it to HAL_LED_INIT unless in station mode, where
it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will
call newstate() at some point, which will refiddle the LEDs.

I've tested this on a handful of 11n and pre-11n NICs. The blinking
behaviour is slightly more sensible now.

Refactor out the software LED config code into a common function, called
ath_led_config().

The eventual aim is to have both software and hardware based LED
configuration done here.

First pass of LED related code changes.

Migrate the LED code out of if_ath.c and into if_ath_led.c.
These routines are _all_ software based LED blinking.

Do a quick style(9) pass of some of the code introduced with 802.11n
support.

Rework this ugly mess that tries to handle reset serialisation.

Some users were reporting concurrent resets _were_ occuring - ie,
either two ath_reset()s ran at the same time (likely one on each CPU)
or ath_reset() versus ath_chan_change().

Instead, this now tries to grab the serialisation semaphore and will
pause() for a while if it fails. It will always eventually succeed though
and will log an error if it hits the recursion situation.

All of this stuff needs to die a horrible death at some point and be
replaced with a properly serialising method of programming this stuff
(eg using the net80211 taskqueue for all of this stuff.) The trouble
is figuring out how to handle the concurrent ioctl() based things without
introducing more LORs (which is another reason why I haven't just wrapped
all of this stuff in large, long-lived locks, a-la what Linux can get
away with.)

MFC after: Absolutely, positively never.

Make some more of the 11n specific code conditional.

This doesn't fix compilation w/out AH_SUPPORT_AR5416 as all of the software
aggregation support in if_ath_tx.c and 11n code in if_ath_tx_ht.c touches
the 11n specific fields. I'll work on that later.

Add a temporary debugging statement in order to try and identify what's
going on with the occasional garbage rs_antenna field reported by AR9285
users.

I've discovered that the 11n NICs only fill out the entire RX status
descriptor on the final descriptor in an aggregate. Some of the fields
(notably RSSI) are complete nonsense for A-MPDU subframes. This may
be another example of this.

The driver doesn't currently toss out statistics for non-final aggregate
frames. It's likely that this should be done.

If any users hit this particular debugging message they should report it
immediately to freebsd-wireless@freebsd.org - please ensure you have
ATH_DEBUG enabled so it prints out the full receive descriptor.

PR: kern/163312

Fix some net80211 enum nits:
- ic_vap_create() uses an ieee80211_opmode argument
- ieee80211_rate2media() takes an ieee80211_phymode argument
- ieee80211_plcp2rate() takes an ieee80211_phytype argument
- cast to enum ieee80211_protmode and ieee80211_roamingmode to silence
compiler warnings

Submitted by: arundel@

Print out the radio RF version at startup, so I can better see which
RF frontend versions people have when they submit problem reports.

Sponsored by: Hobnob, Inc.

Re-lock the ath lock after ath_reset() has been called.
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.

Use the correct lock when calling msleep().

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.

Fix some whitespace pollution.

Begin breaking apart the receive setup/stop path in preparation for more
"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.

Flesh out some slightly dirty reset/channel change serialisation code
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.

Introduce a work-around for issues with the AR5416 based MAC on SMP devices.

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

Fix the KTR option to compile by default - it was referencing
some unmerged interrupt status debugging code from my branch.

* Add ah_intrstate[8] which will have the record of the last
call to ath_hal_getintr().
* Wrap the KTR code behind ATH_KTR_INTR_DEBUG.
* Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING.

This is only done for the AR5416 and later NICs but it will be
trivial to add to the earlier NICs if required.

Neither are enabled by default, although to minimise HAL binary
API differences, the ah_intrstate[] array is always compiled into
the ath_hal struct.

Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.

This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.

Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.

In summary:

TX path:

* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.

Rate control:

* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.

Misc:

* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.

Known issues:

* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.

* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.

* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".

* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.

* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.

* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.

* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.

Because of this, ATH_ENABLE_11N is still not enabled by default.

Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros

Make sure TXEOL is set on default queues. Otherwise we don't get an
interrupt on the completion of a TX queue and this can cause TX
hangs / timeout.

Sponsored by: Hobnob, Inc.

Refactor out the TX buffer management and completion code in
preparation for TX aggregation.

* Add in logic which calls ath_buf bf->bf_comp if it's set.
This allows for AMPDU (and RIFS, and FF, if someone desires) code
to handle completion - which includes freeing subframes, retransmitting
subframes, etc.

* Break out the buffer free, buffer busy/unbusy default completion handler
code into separate functions. This allows bf_comp methods to free and
unbusy each subframe ath_buf as required.

* Break out the statistics update code into a separate function, just
to clean up the TX completion path a little.

Sponsored by: Hobnob, Inc.

Change the descriptor logic to use bf_lastds to point to the last
descriptor, rather than using the maths involving bf_desc[bf_nseg - 1].

When doing TX aggregation, the status will be updated in the -final-
descriptor of the -final- subframe in an aggregate. Thus bf_lastds
may point to the last descriptor in a completely different ath_buf.

Sponsored by: Hobnob, Inc.

Change ath_buf allocation to:

* Immediately return NULL if a buffer isn't available;
* Track the "buffers not available" count;
* Clear some fields used for tx aggregation;
* Add ath_buf_clone() which clones the majority of buffer state.
This is needed when retransmission of a "busy" buffer is required.

Sponsored by: Hobnob, Inc.

Break out the TX DMA stop code into a separate function.

Sponsored by: Hobnob, Inc.

Add a 'vap' to ath_keyset().

Add some code (which is currently disabled) which modifies the group
multicast key cache behaviour. I haven't yet figured out what the
exact/correct behaviour is so I'm leaving it disabled. It's worth
investigating and "correcting", especially for future work with
mesh/ibss and encryption.

Sponsored by: Hobnob, Inc.

Some more various fixes, etc from my 11n branch.

* When doing software TX queue handling and flush, it's possible
that the deletion of a VAP (eg a STA shutdown) will queue a
"STA Disassociate" frame whilst the interface is being deleted.
The VAP is then deleted, and the frame ends up being queued
to a node that is freed before it can be TX'ed. Things go awry
at this point.

There's no way at the present to avoid freeing the underlying node
when the vap is being deleted. It's too late in the game.

I suspect the real fix is to make sure the frame is software
queued with no completion information somehow, so it doesn't
link back to a node whose underlying VAP has been freed.
For now, we'll just have to do this.

* Add some comments showing what's going on.

* Move an instance of the ATH_LOCK() around to protect the interrupt
set. I'll worry about changing that to a PCU lock later on once
the 11n code is in the tree.

Sponsored by: Hobnob, Inc.

Add KTR tracepoints to the ath driver, in order to debug TX, RX
and interrupt handling.

Sponsored by: Hobnob, Inc.

In preparation for supporting 11n TX/RX properly, allow for TX queue draining
and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL,
ATH_RESET_NOLOSS.

Currently a reset is still a reset - ie, all tx/rx frames in the hardware
queues are purged. This means that those frames will be lost to the 11n TX
and RX aggregation state tracking, breaking AMPDU sessions.

The (eventual) new semantics:

* ATH_RESET_DEFAULT:
full reset, this is the default for reset situations
which I haven't yet figured out what they should be.
* ATH_RESET_FULL:
A full reset - for things such as channel changes.
* ATH_RESET_NOLOSS:
Don't flush TX/RX queues - handle pending RX frames and leave TX
frames where they are; restart TX DMA from where it was.

Break out the node cleanup and node free path, in preparation for
doing software TX queue management.

The software queued TX frames will be freed by the new cleanup
function.

Sponsored by: Hobnob, Inc.

Preparation for correct 802.11n tx/rx handling.

* Change ath_rx_proc() to ath_rx_tasklet(); make that the taskqueue function.
This way (eventually) ath_rx_proc() can be called from elsewhere in the
packet reset/processing queue so frames aren't just "flushed" during
interface resets/reconfigure. This breaks 802.11n RX aggregation tracking.
* Extend ath_tx_proc() to take a 'resched' flag, which marks whether to
reschedule further RX PCU reads or not.
* Change ath_tx_processq() to take a "dosched" flag, which will eventually
be used to indicate whether to reschedule the software TX scheduler.

Sponsored by: Hobnob, Inc.

Merge in some fixes from the if_ath_tx branch.

* Close down some of the kickpcu races, where the interrupt handler
can and will run concurrently with the taskqueue.
* Close down the TXQ active/completed race between the interrupt
handler and the concurrently running tx completion taskqueue
function.
* Add some tx and rx interrupt count tracking, for debugging.
* Fix the kickpcu logic in ath_rx_proc() to not simply drain and
restart the TX queue - instead, assume the hardware isn't
(too) confused and just restart RX DMA. This may break on
previous chipsets, so if it does I'll add a HAL flag and
conditionally handle this (ie, for broken chipsets, I'll
just restore the "stop PCU / flush things / restart PCU"
logic.)
* Misc stuff

Sponsored by: Hobnob, Inc.

Migrate the STAILQ lists to TAILQs.

A bunch of the 11n TX aggregation logic wants to traverse lists of buffers
in various ways. In order to provide O(1) behaviour in this instance,
use TAILQs.

This does blow out the memory footprint and CPU cycles slightly for some
of these operations. I may convert some of these back to STAILQs once
the rest of the software transmit queue handling has been stabilised.

Sponsored by: Hobnob, Inc.

Begin merging in some of my 802.11n TX aggregation driver changes.

* Add a PCU lock, which isn't currently used but will eventually be
used to serialise some of the driver access.

* Add in all the software TX aggregation state, that's kept per-node
and per-TID.

* Add in the software and aggregation state to ath_buf.

* Add in hooks to ath_softc for aggregation state and the (upcoming)
aggregation TX state calls.

* Add / fix the HAL access macros.

Obtained from: Linux, ath9k
Sponsored by: Hobnob, Inc.

Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.

This means that their use is restricted to a single C file.

When punting frames to the RX tap, free the mbufs since we've tampered with
their length.

Without this, an error frame mbuf would:

* have its size adjusted;
* thrown at the radiotap code;
* then since it's never consumed, the rxbuf/mbuf is then re-added to the
RX descriptor list with the small size;
* .. and the hardware ends up (sometimes) only DMA'ing part of a frame into
the small buffer, chaining RX frames together (setting the more flag).

I discovered this particular issue when doing some promiscuous radiotap
testing; I found that I'd occasionally get rs_more set in RX descriptors
w/ the first frame length being very small (sub-100 bytes.) The driver
handles 2-descriptor RX frames (but not more), so this still worked; it
was just odd.

This is suboptimal and may benefit from being replaced with caching
the m_pkthdr_len and m_len fields, then restoring them after completion.

Include opt_ah.h when compiling the driver.

There are HAL methods which are actually direct register
access, rather than simply HAL calls. Because of this, these
register accesses would use the non-debug path in ah_osdep.h
as opt_ah.h isn't included.

With this, the correct register access methods are used,
so debugging traces show things such as TXDP checking and
TSF32 access.

Don't enable the PHY radar errors in calcrxfilter.
That way the radar errors aren't enabled prematurely.

A DFS tester has reported that radar events are reported
during channel scanning, before DFS is actually enabled.

Don't bother triggering the cabq queue if it's empty.

Obtained from: Atheros

Fix lock order to be correcter.

Nothing else locks these two queues (cabq, avp mcastq), but it should
be consistent and correct.

Update the TSF and next-TBTT methods to work for the AR5416 and later NICs.
This is another commit in a series of TDMA support fixes for the 11n NICs.

* Move ath_hal_getnexttbtt() into the HAL; write methods for it.
This returns a timer value in TSF, rather than TU.

* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they
likely now belong.

* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF.
The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor;
the AR5416 and later write 32 bit TSF snapshots into the RX descriptor.
* Use the new capability to choose between 15 and 31 bit TSF adjustment
functions in ath_extend_tsf().

* Write ar5416GetTsf64() and ar5416SetTsf64() methods.
ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.

According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA
stations can now associate/talk, but there are still issues with traffic
stability which need to be investigated.

The ath_hal_extendtsf() function is also used in RX packet timestamping;
this may improve adhoc mode on the 11n chipsets. It also will affect the
timestamps seen in radiotap frames.

Submitted by: Kang Yin Su <cantona@cantona.net>
Approved by: re (kib)

Fix a missing initialisation of bt_flags when setting up the TDMA beacon.

The AR5212 HAL didn't check this field; timers are enabled a different
way.

The AR5416 HAL however did, and since this field was uninitialised, it had
whatever was on the stack at the time. This lead to "unpredictable"
behaviour.

This allows TDMA to work on the AR5416 and later chipsets.

Thanks to: paradyse@gmail.com
Approved by: re (kib, blanket)

Remove this call, now that I've solved the radar module problem without
needing this particular modification.

It can be called during ath_dfs_radar_enable() and still achieve the
same functionality, so I am.

Approved by: re (kib, blanket)

Introduce some more DFS related hooks, inspired both by local work
and the Atheros reference code.

The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.

The specifics:

* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
updated.

Since this isn't currently used by any radar code, these should all
be no-ops for existing users.

Obtained from: Atheros
Submitted by: KBC Networks, sibridge
Approved by: re (kib, blanket)

Fix a corner case in RXEOL handling which was likely introduced by yours
truly.

Before 802.11n, the RX descriptor list would employ the "self-linked tail
descriptor" trick which linked the last descriptor back to itself.
This way, the RX engine would never hit the "end" of the list and stop
processing RX (and assert RXEOL) as it never hit a descriptor whose next
pointer was 0. It would just keep overwriting the last descriptor until
the software freed up some more RX descriptors and chained them onto the
end.

For 802.11n, this needs to stop as a self-linked RX descriptor tickles the
block-ack logic into ACK'ing whatever frames are received into that
self-linked descriptor - so in very busy periods, you could end up with
A-MPDU traffic that is ACKed but never received by the 802.11 stack.
This would cause some confusion as the ADDBA windows would suddenly
be out of sync.

So when that occured here, the last descriptor would be hit and the PCU
logic would stop. It would only start again when the RX descriptor list
was updated and the PCU RX engine was re-tickled. That wasn't being done,
so RXEOL would be continuously asserted and no RX would continue.

This patch introduces a new flag - sc->sc_kickpcu - which when set,
signals the RX task to kick the PCU after its processed whatever packets
it can. This way completed packets aren't discarded.

In case some other task gets called which resets the hardware, don't
update sc->sc_imask - instead, just update the hardware interrupt mask
directly and let either ath_rx_proc() or ath_reset() restore the imask
to its former setting.

Note: this bug was only triggered when doing a whole lot of frame snooping
with serial console IO in the RX task. This would defer interrupt processing
enough to cause an RX descriptor overflow. It doesn't happen in normal
conditions.

Approved by: re (kib, blanket)

Disable the RXORN/RXEOL interrupts if RXEOL occurs, preventing an
interrupt storm.

This is easily triggered by flipping on and off tcpdump -y IEEE802_11_RADIO
w/ witness enabled. This causes a whole lot of console IO and when you're
attached to a serial console (eg on my AR7161 embedded board), the RX
interrupt doesn't get called quickly enough and the RX queue fills up.

This wasn't a problem in the past because of the self-linked RX descriptor
trick - the RX would never hit the "end" of the RX descriptor list.
However this isn't possible for 802.11n (see previous commit history for
why.)

Both Linux ath9k and the Atheros reference driver code do this; I'm just
looking now for where they then restart the PCU receive. Right now the RX
will just stop until the interface is reset.

Obtained from: Linux, Atheros
Approved by: re (kib)

Remove two debugging printf()s which snuck in during the testing of the
last commit.

Approved by: re (kib)
Pointy-hat-to: adrian@

Implement the 4KB split transaction workaround for Merlin (AR9280).

The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.

This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.

I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)

Obtained from: Linux, Atheros
Approved by: re (kib)

This links in the ath dfs ioctl into the driver and defines the
ioctl interface for DFS modules to use.

Since there's no open source dfs code yet, this doesn't introduce any
operational changes.

Approved by: re (kib)

Fix a corner case in STA beacon processing when a CSA is received but
the AP doesn't transmit beacons.

If the AP requests a CSA (ie, a channel switch) and then enters CAC
(channel availability check) for 60 seconds, it doesn't send beacons
and it just listens for radar events (and other things which we don't
do yet.)

Now, ath_newstate() was not resetting the beacon timer config on
a transition to the RUN state when in STA mode - it was setting
sc_syncbeacon, which simply updates the beacon config from the
contents of the next received beacon.

This means the STA never generates beacon miss events.

If the AP goes into CAC for 60 seconds and recovers, the STA will
happily receive the first beacon and reconfigure timers.
But if it gets a radar event after that, it'll change channel
again, not notify the station that it's changed channel..
and since the station is happily waiting for the first beacon
to configure the beacon timer details from, it won't ever
generate a beacon miss interrupt and it'll sit there forever
(or until the AP appears on that channel once again.)

This change forces the last known beacon timer config to be
written to hardware on a transition from CSA->RUN in STA mode.
This forces bmiss events to occur and the STA will eventually
(after a handful of beacon miss events) begin scanning for
another access point.

Fix beacon transmission after a channel set.

The DFS code was tickling the channel set directly whilst going
through the state RUN -> CSA -> RUN. This only changed the channel;
it didn't go via ath_reset(). However in this driver, a channel
change always causes a chip reset, which resets the beacon timer
configuration and interrupt setup. This meant that data would go
out but as the beacon timers never fired, beacons would never
be queued.

The confusing part is that sometimes the state transition was
RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes);
going via SCAN would clear sc_beacons and thus the transition
to RUN would reprogram beacon transmission.

In case someone tries debugging why suspending a device currently
beaconing (versus just RX'ing beacons which is what occurs in STA
mode), add a silly comment which should hopefully land them at
this commit message. The call to ath_hal_reset() will be clearing
the beacon config and it may not be always reset.

Add ATH_ENABLE_DFS which enables the DFS flag so the DFS code
can be tested.

This doesn't at all actually do radar detection! It's just
so developers who wish to test the net80211 DFS code can easily
do so. Without this flag, the DFS channels are never marked
DFS and thus the DFS stuff doesn't run.

Break out most of the HAL related tweaks into a per-HAL instance,
rather than global variables.

This specifically allows for debugging to be enabled per-NIC, rather
than globally.

Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.

The ALQ support is currently still global pending some brainstorming.

Submitted by: ssgriffonuser@gmail.com
Reviewed by: adrian, bschmidt

Add a missing call to sync the DMAed buffer before the radar event data is extracted.

A few changes to make radar detection implementable in a hal_dfs/
module.

* If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(),
set the relevant rx filter bit to begin receiving radar PHY
errors. The HAL code already knows how to set the relevant
error mask register to enable radar events.

* Add a missing call to ath_dfs_radar_enable() after ath_hal_reset()

* change ath_dfs_process_phyerr() to take a const char *buf for now,
rather than a descriptor. This way it can get access to the packet
buffer contents.

Flesh out the radar detection related operations for the ath driver.

This is in no way a complete DFS/radar detection implementation!
It merely creates an abstracted interface which allows for future
development of the DFS radar detection code.

Note: Net80211 already handles the bulk of the DFS machinery,
all we need to do here is figure out that a radar event has occured
and inform it as such. It then drives the DFS state engine for us.

The "null" DFS radar detection module is included by default;
it doesn't require a device line.

This commit:

* Adds a simple abstracted layer for radar detection state -
sys/dev/ath/ath_dfs/;
* Implements a null DFS module which doesn't do anything;
(ie, implements the exact behaviour at the moment);
* Adds hooks to the ath driver to process received radar events
and gives the DFS module a chance to determine whether
a radar has been detected.

Obtained from: Atheros

Set default A-MPDU density/size.

Teach if_ath about devices which have short-GI in 20MHz channel modes.

This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.

* Add some more TX descriptor error counters; this'll be helpful when
implementing TX aggregation
* Whilst I'm there, comment some RX error counters

Now that the devices with functioning ps-poll hardware support have
been enumerated (merlin and later), flick this on.

Cosmetic changes to fit 80 character screen width.

Fix a corner-case of interrupt handling which resulted in potentially
spurious (and fatal) interrupt errors.

One user reported seeing this:

Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000

SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.

After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.

The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.

This patch does the following:

* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.

This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.

For now, only enable GTT. CST is firing very frequently during local tests;
I'll figure out what's going on before re-enabling this as it does add
to the interrupt load.

Add TX carrier sense timeout statistics.

Rework the Global TX timeout handling to look more like ath9k.

It correctly now sets the AR_IMR BCNMISC register, along with
the GTT register in AR_IMR_S2.

Add global TX timeout handling.

The global TX timeout counter increments whenever a frame is ready
to be transmitted and the medium is busy.

Add in the AR9285 (Kite) diversity to if_ath, enabling TX/RX antenna
diversity.

This is bit dirty and likely should be revised at a later date,
with an eye to unifying/tidying up the whole diversity setup
and allowing developers to do "tricky stuff" as they desire.
For now, this works.

Add a HAL capability bit for supporting self-linked RX descriptors and disable it for the 11n chipsets.

From the ath9k source:

==

11N: we can no longer afford to self link the last descriptor.
MAC acknowledges BA status as long as it copies frames to host
buffer (or rx fifo). This can incorrectly acknowledge packets
to a sender if last desc is self-linked.

==

Since this is useful for pre-AR5416 chips that communicate PHY errors
via error frames rather than by on-chip counters, leave the support
in there, but disable it for AR5416 and later.

Break out the ath PCI logic into a separate device/module.

Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.

Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.

According to ath9k recv.c, one shouldn't be doing self-linked descriptors
in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC
will loop over that self-linked descriptor and treat it as "good enough"
for (incorrectly!) ACKing the frames in the block-ack.

Until I figure out how to work around this issue in the future, this counter
will tell me if packet RX processing ever gets to the point where it's
touching the self-linked descriptor. If there's ever enough packets to get
to that point, BA's will be invalid and likely very unhappy.

Fix typo.

Rename AH_ENABLE_11N to ATH_ENABLE_11 - the HAL supports 11n by
default but the ath driver doesn't. This is a much more consistent
name.

Add in the hardware PS-POLL frame reception setting, but leave it disabled
by default.

Adventourous souls with an AR9220/AR9280 or later and who have a device
that sends PS-POLL frames may wish to try tinkering with this option and
get back to me.

Enable setting the MCS rate bit for ast_tx_rate.

This allows ath_stats to print the MCS rate when TX'ing.

Flip this over to be a configurable option for people who wish to play with it.

It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my head around, and AMPDU-TX is just not
implemented so things will come to a crashing halt if you're not careful.

This isn't actually needed any longer, A-MPDU frames work fine if only tagged for 11n nodes.

Break the keycache management functions out into if_ath_keycache.c .

Migrate the sysctl related routines (statistics, debugging, etc) out of
if_ath.c and into if_ath_sysctl.c .

Fix formatting of new stat sysctls; add descriptions

Add a new counter which tracks frames TX'ed with HT protection.

Disable short-GI in 20mhz mode - the hardware doesn't support this.

Some statistics additions - prepare for error codes > 32 (since the AR5416
error mask is > 5 bits) and add some extra CRC/HT40/ShortGI counters to
help debug 802.11n issues.

Add in the (very!) optional glue to flip the 11n bits for if_ath.

There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU TX handling!)
but if people wish to give this a go and assist in debugging the
issues, they can define ATH_DO_11N to enable it.

I'm just re-iterating - this is here to allow people to assist in
further 11n development; it is not any indication that the 11n support
is complete and functional.

Important notes:

* This doesn't support 1-stream cards yet - (eg AR9285) - the various bits
that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate
1-stream RX; so don't enable 11n unless you've first taught the rate
control module and the net80211 stack to negotiate 1-stream stuff;

* The only rate control module minimally 11n aware is ath_rate_sample;

* ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly
calculated;

* The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for
some reason; this will definitely impact 11n performance;

* AMPDU-TX isn't yet implemented;

* AMPDU-RX may be a bit buggy still and will definitely suffer from the
radio unreliability mentioned above (ie, don't expect 150/300mbit
RX just yet.)

Fix the keycache behaviour for multicast keycache search.

The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)

The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.

This fixes some encryption problems in station mode.

PR: kern/154598

net80211 really doesn't want A_MPDU to appear on non-11n station node mbufs.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.

I'll have to do some further research into exactly what is being messed up
with the sequence number matching and I'll then revisit this.

Add in a per phy error sysctl.

Just tag all RX packets as needing reorder processing for now.

This fixes two problems -

* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherwise) in the given TID (traffic class id)
will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
somehow need to be tracked. Thus just tag them all for now; I'll figure out
the why later.

Whilst I'm here, bump the stats counters whilst I'm at it.

This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.

Only tag packets with the A-MPDU bit if they were part of an A-MPDU RX.

Whilst I'm here, add a counter to count said packets.

Oops, fix newbie mistake that breaks the normal build.