Commit Graph

1402 Commits

Author SHA1 Message Date
Adrian Chadd
fc56c9c5e2 There's no need to use a TXQ pointer here; we specifically need the
hardware queue ID when queuing to EDMA descriptors.

This is a small part of trying to reduce the size of ath_buf entries.
2012-12-11 04:19:51 +00:00
Adrian Chadd
2992cd2231 Add XC900 SKU mapping. 2012-12-07 06:38:30 +00:00
Gleb Smirnoff
c6499eccad Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.
2012-12-04 09:32:43 +00:00
Adrian Chadd
e89812c379 Methodise the BT diversity configuration function; so the AR9285
can correctly override it.

This was missed in the previous commit.
2012-12-04 00:02:46 +00:00
Adrian Chadd
96b59d60c8 Override the BT coex parameter function for the AR9285. 2012-12-04 00:01:42 +00:00
Adrian Chadd
87a85d8a49 Reformat/reindent. 2012-12-04 00:01:24 +00:00
Adrian Chadd
24a8406b99 Add and tie in the AR5416 bluetooth coexistence methods into the HAL. 2012-12-03 23:45:06 +00:00
Adrian Chadd
974185bb13 Don't grab the PCU lock inside the TX lock. 2012-12-02 06:50:27 +00:00
Adrian Chadd
375307d411 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.
2012-12-02 06:24:08 +00:00
Adrian Chadd
e5d63a99bc Add a new HAL capability - check and enforce whether the NIC supports
enforcing the TXOP and TBTT limits:

* Frames which will overlap with TBTT will not TX;
* Frames which will exceed TXOP will be filtered.

This is not enabled by default; it's intended to be enabled by the
TDMA code on 802.11n capable chipsets.
2012-12-01 03:48:11 +00:00
Adrian Chadd
8bf4020830 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.
2012-11-28 07:12:08 +00:00
Adrian Chadd
491e124856 Until I figure out what to do here, remind myself that this needs some
rate control 'adjustment' when NOACK is set.
2012-11-28 06:55:34 +00:00
Adrian Chadd
7c783791c8 Pull out the debugging code from the critical path and make sure it
happens _after_ all of the time delta calculations.
2012-11-28 01:55:22 +00:00
Adrian Chadd
821311ea59 * Fix another culprit of my "committed from the wrong directory" nonsense;
now this works for non-debug and debug builds.

* Add a comment reminding me (or someone) to audit all of the relevant
  math to ensure there's no weird wrapping issues still lurking about.

But yes, this does seem to be mostly working.

Pointy-hat-to:	adrian, yet again
2012-11-27 11:30:39 +00:00
Adrian Chadd
4fd97455a3 Correct some debugging output. 2012-11-27 08:40:48 +00:00
Adrian Chadd
584295fca4 Fix build 2012-11-27 05:52:08 +00:00
Adrian Chadd
4bda23f95b Improve the TDMA debugging:
* add some further debugging prints, which are quite nice to have
* add in ALQ hooks (optional!) to allow for the TDMA information to be
  logged in-line with the TX and RX descriptor information.
2012-11-27 02:27:30 +00:00
Adrian Chadd
11f07b7b52 Add in specific TDMA logging types. 2012-11-27 02:24:05 +00:00
Adrian Chadd
e6f1a34af4 Fix the TDMA nexttbtt programming for 802.11n chips.
The existing logic wrapped programming nexttbtt at 65535 TU.
This is not good enough for the 11n chips, whose nexttbtt register
(GENERIC_TIMER_0) has an initial value from 0..2^31-1 TSF.
So converting the TU to TSF had the counter wrap at (65535 << 10) TSF.

Once this wrap occured, the nexttbtt value was very very low, much
lower than the current TSF value.  At this point, the nexttbtt timer
would constantly fire, leading to the TX queue being constantly gated
open.. and when this occured, the sender was not correctly transmitting
in its slot but just able to continuously transmit.  The master would
then delay transmitting its beacon until after the air became free
(which I guess would be after the burst interval, before the next burst
interval would quickly follow) and that big delta in master beacon TX
would start causing big swings in the slot timing adjustment.

With this change, the nexttbtt value is allowed to go all the way up
to the maximum value permissable by the 32 bit representation.
I haven't yet tested it to that point; I really should.  The AR5212
HAL now filters out values above 65535 TU for the beacon configuration
(and the relevant legal values for SWBA, DBA and NEXTATIM) and the
AR5416 HAL just dutifully programs in what it should.

With this, TDMA is now useful on the 802.11n chips.

Tested:

* AR5416, AR9280 TDMA slave
* AR5413 TDMA slave
2012-11-27 02:23:45 +00:00
Adrian Chadd
a52b6c396b Add a note about the magic values here; don't change them. 2012-11-27 02:19:35 +00:00
Adrian Chadd
2cb6e9834f When programming the beacon timer configuration, be very explicit about
what the maximum legal values are.

The current beacon timer configuration from TDMA wraps things at
HAL_BEACON_PERIOD-1 TU.  For the 11a chips this is fine, but for
the 11n chips it's not enough resolution.  Since the 11a chips have a
limit on what's "valid", just enforce this so when I do write larger
values in, they get suitably wrapped before programming.

Tested:

* AR5413, TDMA slave

Todo:

* Run it for a (lot) longer on a clear channel, ensure that no strange
  slippages occur.
* Re-validate this on STA configurations, just to be sure.
2012-11-27 02:18:41 +00:00
Adrian Chadd
6dd853a77a Add a comment which covers what's going on with the 64 bit TSF write.
After chatting with the MAC team, the TSF writes (at least on the 11n
MACs, I don't know about pre-11n MACs) are done as 64 bit writes that
can take some time.  So, doing a 32 bit TSF write is definitely not
supported.  Leave a comment here which explains that.

Whilst here, add a comment which outlines that after a reset or TSF
write, the TSF write may take a while (up to 50uS) to update.
A write or reset shouldn't be done whilst the previous one is in
flight.  Also (and this isn't currently done) a read shouldn't
occur until the SLEEP32_TSF_WRITE_STAT is clear.  Right now we're
not doing that, mostly because we haven't been doing lots of TSF
resets/writes until recently.
2012-11-24 02:41:18 +00:00
Adrian Chadd
84dd5933b5 Use a 64 bit TSF write to update the TSF adjust, rather than a 32 bit
TSF write.

The TSF_L32 update is fine for the AR5413 (and later, I guess) 11abg NICs
however on the 11n NICs this didn't work.  The TSF writes were causing
a much larger time to be skipped, leading to the timing to never
converge.

I've tested this 64 bit TSF read, adjust and write on both the
11n NICs and the AR5413 NIC I've been using for testing.  It works
fine on each.

This patch allows the AR5416/AR9280 to be used as a TDMA member.
I don't yet know why the AR9280 is ~7uS accurate rather than ~3uS;
I'll look into it soon.

Tested:

* AR5413, TDMA slave (~ 3us accuracy)
* AR5416, TDMA slave (~ 3us accuracy)
* AR9280, TDMA slave (~ 7us accuracy)
2012-11-23 05:52:22 +00:00
Adrian Chadd
ddee921170 Fix up the nexttbtt -> TSF delta calculation to not wrap ridiculously
on the 802.11n NICs.

The 802.11n NICs return a TBTT value that continues far past the 16 bit
HAL_BEACON_PERIOD time (in TU.)  The code would constrain nextslot to
HAL_BEACON_PERIOD, but it wasn't constraining nexttbtt - the pre-11n
NICs would only return TU values from 0 -> HAL_BEACON_PERIOD.  Thus,
when nexttbtt exceeded 64 milliseconds, it would not wrap (but nextslot
did) which lead to a huge tsfdelta.

So until the slot calculation is converted to work in TSF rather than
a mix of TSF and TU, "make" the nexttbtt values match the TU assumptions
for pre-11n NICs.

This fixes the crazy deltatsf calculations but it doesn't fix the
non-convergent tsfdelta issue.  That'll be fixed in a subsequent commit.
2012-11-23 05:38:38 +00:00
Adrian Chadd
02a9696b0a Add the HAL wrapper for settsf64. 2012-11-23 05:33:01 +00:00
Adrian Chadd
c83ba0b9bf Implement a HAL method to set a 64 bit TSF value.
TODO: implement it (and test) for the AR5210/AR5211.
2012-11-23 05:32:24 +00:00
Adrian Chadd
cc637103f6 Don't allocate or program a key for the AR5210.
The AR5210 doesn't support HAL_CIPHER_CLR ('clear encryption' keycache
slots), so don't bother - just map them to slot 0 and never program them.
2012-11-19 23:54:05 +00:00
Adrian Chadd
143cfad710 Disable WEP hardware encryption on the AR5210, in order to allow other
encryption types.

The AR5210 only has four WEP key slots, in contrast to what the
later MACs have (ie, the keycache.)  So there's no way to store a "clear"
key.

Even if the driver is taught to not allocate CLR key entries for
the AR5210, the hardware will actually attempt to decode the encrypted
frames with the (likely all 0!) WEP keys.

So for now, disable the hardware encryption entirely and just so it
all in software.  That allows both WEP -and- WPA to actually work.

If someone wishes to try and make hardware WEP _but_ software WPA work,
they'll have to create a HAL capability to enable/disable hardware
encryption based on the current STA/Hostap mode. However, making
multi-vap work with one WEP and one WPA VAP will require hardware
encryption to be disabled anyway.
2012-11-19 23:42:46 +00:00
Adrian Chadd
73f81b5b19 Remove this include, it isn't needed. 2012-11-18 20:41:46 +00:00
Adrian Chadd
875d039e0a Correctly populate the RTS field.
Tested:
	* AR5210, STA mode, RTS enabled
2012-11-17 02:39:37 +00:00
Adrian Chadd
3a4d0022de * Remove ah_desc.h, it's not needed
* Add some shifts that I'm using in userspace (athalq.)

However, this exposes a fun little bug..
2012-11-17 02:39:09 +00:00
Adrian Chadd
93cad1bdbd .. include ah_desc.h here now. 2012-11-17 02:02:36 +00:00
Adrian Chadd
f8af1be8f8 Remove the ah_desc.h reference; it's not needed.
I'm using these descriptor header files in userland and I'm trying to
avoid populating a compatibility ah_desc.h file.
2012-11-17 02:00:33 +00:00
Adrian Chadd
69f33b13d1 I'm not sure why ah_desc.h was required here, but it doesn't _need_
to be. So, just toss it.

There's no options or ah_desc fields in here.

Whilst I'm here, fix up the #ifdef and #define to mach.
2012-11-16 20:04:45 +00:00
Adrian Chadd
e3f0668803 * Remove a duplicate TX ALQ post routine!
* For CABQ traffic, I -can- chain them together using the next pointer
  and just push that particular chain head to the CABQ.  However, this
  doesn't magically make EDMA TX CABQ work - I have to do some further
  hoop jumping.
2012-11-16 19:58:15 +00:00
Adrian Chadd
bb327d284b 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.
2012-11-16 19:57:16 +00:00
Adrian Chadd
956d4fb965 ath(4) ALQ logging improvements.
* Add a new method which allows the driver to push the MAC/phy/hal info
  into the logging stream.
* Add a new ALQ logging entry which logs the mac/phy/hal information.
* Modify the ALQ startup path to log the MAC/phy/hal information
  so the decoder knows which HAL/chip is generating this information.
* Convert the header and mac/phy/hal information to use be32, rather than
  host order.  I'd like to make this stuff endian-agnostic so I can
  decode MIPS generated logs on a PC.

This requires some further driver modifications to correctly log the
right initial chip information.

Also - although noone bar me is currently using this, I've shifted the
debug bitmask around a bit.  Consider yourself warned!
2012-11-16 19:39:29 +00:00
Adrian Chadd
bbdf3df1c4 Make sure the final descriptor in an aggregate has rate control information.
This was broken by me when merging the 802.11n aggregate descriptor chain
setup with the default descriptor chain setup, in preparation for supporting
AR9380 NICs.

The corner case here is quite specific - if you queue an aggregate frame
with >1 frames in it, and the last subframe has only one descriptor making
it up, then that descriptor won't have the rate control information
copied into it. Look at what happens inside ar5416FillTxDesc() if
both firstSeg and lastSeg are set to 1.

Then when ar5416ProcTxDesc() goes to fill out ts_rate based on the
transmit index, it looks at the rate control fields in that descriptor
and dutifully sets it to be 0.

It doesn't happen for non-aggregate frames - if they have one descriptor,
the first descriptor already has rate control info.

I removed the call to ath_hal_setuplasttxdesc() when I migrated the
code to use the "new" style aggregate chain routines from the HAL.
But I missed this particular corner case.

This is a bit inefficient with MIPS boards as it involves a few redundant
writes into non-cachable memory.  I'll chase that up when it matters.

Tested:

 * AR9280 STA mode, TCP iperf traffic
 * Rui Paulo <rpaulo@> first reported this and has verified it on
   his AR9160 based AP.

PR:		kern/173636
2012-11-15 03:00:49 +00:00
Adrian Chadd
5f9fe65d64 Place 'dev.ath.X.debug' back under ATH_DEBUG, rather than ATH_DEBUG_ALQ. 2012-11-13 19:45:13 +00:00
Adrian Chadd
7d9dd2ac96 Add some debugging to try and catch an invalid TX rate (0x0) that is
being reported.
2012-11-13 06:28:57 +00:00
Adrian Chadd
603280386b Correctly fix the 'scan during STA mode' crash. 2012-11-11 21:58:18 +00:00
Adrian Chadd
58c82ec453 Remove this; i incorrectly committed the wrong (debug) changes in my
previous commit.
2012-11-11 21:57:18 +00:00
Adrian Chadd
04cdca73d9 Don't call av_set_tim() if it's NULL.
This happens during a scan in STA mode; any queued data frames will
be power save queued but as there's no TIM in STA mode, it panics.

This was introduced by me when I disabled my driver-aware power save
handling support.
2012-11-11 00:34:10 +00:00
Adrian Chadd
3345c65be0 Correct some rather weird and broken behaviour observed when doing
actual traffic with an AR9380/AR9382/AR9485.

The sample rate control stats would show impossibly large numbers for
"successful packets transmitted."  The number was a tad under 2^^64-1.
So after a bit of digging, I found that the sample rate control code
was making 'tries' turn into a negative number.. and this was because
ts_longretry was too small.

The hardware returns "ts_longretry" at the current rate selection,
not overall for that TX descriptor.  So if you setup four TX rate
scenarios and the second one works, ts_longretry is only set for
the number of attempts at that second rate scenario.  The FreeBSD HAL
code does the correction in ath_hal_proctxdesc() - however, this isn't
possible with EDMA.

EDMA TX completion is done separate from the original TX descriptor.
So the real solution is to split out "find ts_rate and ts_longretry"
from "complete TX descriptor".  Until that's done, put a hack in
the EDMA TX path that uses the rate scenario information in the ath_buf.

Tested: AR9380, AR9382, AR9485 STA mode
2012-11-10 22:37:06 +00:00
Kevin Lo
f78d5b7e8a s/ATH_DEBUG/ATH_DEBUG_ALQ 2012-11-10 15:21:39 +00:00
Kevin Lo
9fc1923565 Fix the build. 2012-11-10 08:34:40 +00:00
Adrian Chadd
a64438faed Fix a very incorrect description. 2012-11-09 01:28:11 +00:00
Adrian Chadd
bbee93a84e Fix the build - fix up the ath_alq code to not compile by default. 2012-11-08 23:11:59 +00:00
Adrian Chadd
b69b0dcc24 Add some hooks into the driver to attach, detach and record EDMA descriptor
events.

This is primarily for the TX EDMA and TX EDMA completion. I haven't yet
tied it into the EDMA RX path or the legacy TX/RX path.

Things that I don't quite like:

* Make the pointer type 'void' in ath_softc and have if_ath_alq*()
  return a malloc'ed buffer.  That would remove the need to include
  if_ath_alq.h in if_athvar.h.
* The sysctl setup needs to be cleaned up.
2012-11-08 18:11:31 +00:00
Adrian Chadd
2a2441c9fa Add my initial cut at driver-layer ALQ support.
I'm using this to debug EDMA TX and RX descriptors and it's really helpful
to have a non-printf() way to decode frames.

I won't link this into the build until I've tidied it up a little more.

This will eventually be behind ATH_DEBUG_ALQ.
2012-11-08 18:07:29 +00:00
Adrian Chadd
174484b17a Oops, fix bogus spacing. 2012-11-08 17:46:27 +00:00
Adrian Chadd
ae3815fd18 Implement the ATH_RESET_NOLOSS path for TX stop and start; this is needed
for 802.11n TX device restarting.

Remove the debug printf()s; they're no longer needed here.
2012-11-08 17:43:58 +00:00
Adrian Chadd
d4c0d5d0d9 Convert this to a debug printf; it's working fine now. 2012-11-08 17:32:55 +00:00
Adrian Chadd
89d2e576a4 Don't compile in my (not yet committed) ath_alq code unless ATH_DEBUG_ALQ
is defined.

This will unbreak ATH_DEBUG builds.
2012-11-07 16:34:09 +00:00
Adrian Chadd
bdbb6e5b8c 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.
2012-11-07 06:29:45 +00:00
Adrian Chadd
7877ac644e Add new HAL configuration features for the updated AR9300 HAL. 2012-11-07 06:23:23 +00:00
Adrian Chadd
6e84772f4d Convert the aggregate descriptor path over to use the same API as
the non-aggregate path.

I "cheated" by using some TX setup code in our HAL that isn't present
in the atheros HAL (or Linux ath9k.)

The old path for forming aggregates was:

* setup the rate control in the first descriptor;
* call chaintxdesc() on all the frames;
* call setupfirsttxdesc() on the first descrpitor in the first
  frame;
* call setuplasttxdesc() on the last descriptor in the last frame.

The new path for forming aggregates looks like the non-aggregate path:

* call setuptxdesc() on the first descriptor in the first frame;
* setup the rate control in the first descriptor;
* call filltxdesc() on each descriptor in the frame;
* if it's an aggregate - call set11n_aggr_{first, middle, last} as
  appropriate (see the code for a description of what is "appropriate".)

Now, this is done primarily for the AR9300 HAL - it doesn't implement
the first set of aggregate functions.  It just has the older methods
and the "first/middle/last" aggregate methods.  So, let's convert the
code to use these.

Note: the AR5416 HAL in FreeBSD had that code (from me, a while ago)
and a previous commit brought it up to behave the same as the AR9300
HAL routines.

There's some further tidyups to be done - specifically, avoid doing
multiple calls to the 11n descriptor functions. I shouldn't call
clr11n_aggr(), then set11n_aggr_middle(), then also set11n_aggr_first().
On (at least MIPS) the TX descriptors are in non-cachable memory and
this will cause multiple slow writes.

I'll debug/tidy that up in a future commit.

Tested:

* AR9280, STA
* AR9280/AR9160, AP
* AR9380, STA (using a local, closed source HAL, sorry!)
2012-11-06 06:19:11 +00:00
Dimitry Andric
29658c96ce Remove duplicate const specifiers in many drivers (I hope I got all of
them, please let me know if not).  Most of these are of the form:

static const struct bzzt_type {
	[...list of members...]
} const bzzt_devs[] = {
	[...list of initializers...]
};

The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).

I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).

Reviewed by:	yongari, marius
MFC after:	1 week
2012-11-05 19:16:27 +00:00
Adrian Chadd
c19a2a1a9f Clear IFF_DRV_OACTIVE if any slots were completed.
This unblocks TX EDMA under high load.
2012-11-05 09:27:47 +00:00
Adrian Chadd
bc919a54b2 TX EDMA debugging fixes:
* Do the calculation for each ath_buf, rather than just the first
* Correct the calculation in the first place.
2012-11-05 07:08:45 +00:00
Adrian Chadd
4c5038c7b5 Oops - conditionalise that. 2012-11-04 00:46:01 +00:00
Adrian Chadd
d40c846abf EDMA TX tweaks:
* don't poke ath_hal_txstart() if nothing was pushed into the FIFO during
  the refill process;

* shuffle around the TX debugging output a little so it's logged at
  TX hardware enqueue;

* Add logging of the TX status processing.
2012-11-03 22:54:42 +00:00
Adrian Chadd
64dbfc6d92 For AR9380 NICs - the non-enterprise versions don't support RTS protection
of small (< 256 byte) aggregate frames.

This needs to be done or 11n aggregation TX just simply doesn't work
on these NICs.

Whilst here, extend some debug printing; I was using this whilst
debugging the TX power setup in the TX descriptor(s) on the AR9380.
2012-11-03 22:13:42 +00:00
Adrian Chadd
5540369b93 Add a new HAL call to extract out the HAL enterprise bits from the
AR9300 HAL.
2012-11-03 22:12:35 +00:00
Adrian Chadd
b90559c429 HAL API updates, from the previous couple of HAL commits. 2012-11-03 04:56:08 +00:00
Adrian Chadd
f74b406ddd HAL API changes!
* introduce a new HAL API method to pull out the TX status descriptor
  contents.

* Add num_delims to the 11n first aggr method.  This isn't used by the
  driver at the moment so it won't affect anything.
2012-11-03 04:55:43 +00:00
Adrian Chadd
70ee90299b Add a debug method to dump the EDMA TX status descriptor contents out.
This requires some HAL API changes to be useful, as there's no way
right now to pull out the TX status descriptor contents.
2012-11-03 04:53:44 +00:00
Adrian Chadd
aff98f17c6 Since the PLL changes aren't in here yet for the AR9130 half/quarter
rate support, disable it.
2012-10-31 21:14:25 +00:00
Adrian Chadd
b0245b90ba Oops - this was incorrectly removed in a previous commit. 2012-10-31 21:06:55 +00:00
Adrian Chadd
9bb63aa8ff Oops - missing from the last commit - add ANI immunity levels for AR9160.
Obtained from:	Qualcomm Atheros
2012-10-31 21:04:23 +00:00
Adrian Chadd
adadb6074d HAL updates!
* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
  that are available. A later revision of the AR5111 supports the 4.9GHz
  PSB channels but right now there's no check in place for the radio
  revision.

  If someone wants PSB support on AR5212+AR5111 radios then please let
  me know and I'll add the relevant version check.

Obtained from:	Qualcomm Atheros
2012-10-31 21:03:55 +00:00
Adrian Chadd
3631c3f200 Add in the last random assortment of missing bits for the AR9380 HAL.
Obtained from:	Qualcomm Atheros
2012-10-31 21:00:01 +00:00
Adrian Chadd
321e63ddee Add the emulation PCI device id - these days, 0xabcd shows up all over
the internet as "AR9380 and later which didn't get its PCI ID written
in at power-on", so it's hardly an unknown constant.

Obtained from:	Qualcomm Atheros
2012-10-31 20:58:24 +00:00
Adrian Chadd
bf57b7b2ce I've had some feedback that CCK rates are more reliable than MCS 0
in some very degenerate conditions.

However, until ath_rate_form_aggr() is taught to not form aggregates
if ANY selected rate is non-MCS, this can't yet be enabled.

So, just add a comment.
2012-10-31 06:35:50 +00:00
Adrian Chadd
1b5c5f5ad0 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.
2012-10-31 06:27:58 +00:00
Adrian Chadd
548a605d0d 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.
2012-10-28 21:13:12 +00:00
Adrian Chadd
a93c5097c9 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.
2012-10-28 18:46:06 +00:00
Adrian Chadd
9572684af7 Since it's not immediately obvious whether the current TX path handles
fragment rate lookups correctly, add a comment describing exactly that.

The assumption in the fragment duration code is the duration of the next
fragment will match the rate used by the current fragment.  But I think
a rate lookup is being done for _each_ fragment.  For older pre-sample
rate control this would almost always be the case, but for sample
it may be incorrect more often then correct.
2012-10-26 16:31:12 +00:00
Adrian Chadd
cf0c92d600 Track the total number of software queued frames in an atomic variable
stashed away in ath_node.

As much as I tried to stuff that behind the ATH_NODE lock, unfortunately
the locking is just too plain hairy (for me! And I wrote it!) to do
cleanly. Hence using atomics here instead of a lock. The ATH_NODE lock
just isn't currently used anywhere besides the rate control updates.

If in the future everything gets migrated back to using a single ATH_NODE
lock or a single global ATH_TX lock (ie, a single TX lock for all TX and
TX completion) then fine, I'll remove the atomics.
2012-10-15 00:07:18 +00:00
Adrian Chadd
13aa9ee5c2 Stop abusing the ATH_TID_*() queue macros for filtered frames and give
them their own macro set.
2012-10-14 23:52:30 +00:00
Adrian Chadd
8e7393944d 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.
2012-10-14 20:44:08 +00:00
Adrian Chadd
516f67965a Break the RX processing up into smaller chunks of 128 frames each.
Right now processing a full 512 frame queue takes quite a while (measured
on the order of milliseconds.) Because of this, the TX processing ends up
sometimes preempting the taskqueue:

* userland sends a frame
* it goes in through net80211 and out to ath_start()
* ath_start() will end up either direct dispatching or software queuing a
  frame.

If TX had to wait for RX to finish, it would add quite a few ms of
additional latency to the packet transmission.  This in the past has
caused issues with TCP throughput.

Now, as part of my attempt to bring sanity to the TX/RX paths, the first
step is to make the RX processing happen in smaller 'parts'. That way
when TX is pushed into the ath taskqueue, there won't be so much latency
in the way of things.

The bigger scale change (which will come much later) is to actually
process the frames in the ath_intr taskqueue but process _frames_ in
the ath driver taskqueue.  That would reduce the latency between
processing and requeuing new descriptors. But that'll come later.

The actual work:

* Add ATH_RX_MAX at 128 (static for now);
* break out of the processing loop if npkts reaches ATH_RX_MAX;
* if we processed ATH_RX_MAX or more frames during the processing loop,
  immediately reschedule another RX taskqueue run.  This will handle
  the further frames in the taskqueue.

This should have very minimal impact on the general throughput case,
unless the scheduler is being very very strange or the ath taskqueue
ends up spending a lot of time on non-RX operations (such as TX
completion.)
2012-10-14 20:31:38 +00:00
Adrian Chadd
b1dddc280f Fix the non-TDMA build. 2012-10-13 06:27:34 +00:00
Adrian Chadd
3e6cc97fd6 Migrate the TID TXQ accesses to a new set of macros, rather than reusing
the ATH_TXQ_* macros.

* Introduce the new macros;
* rename the TID queue and TID filtered frame queue so the compiler
  tells me I'm using the wrong macro.

These should correspond 1:1 to the existing code.
2012-10-07 23:45:19 +00:00
Adrian Chadd
943e37a120 Initialise an uninitialised variable. 2012-10-05 16:44:00 +00:00
Adrian Chadd
e9472a9f88 Implement the quarter rate fractional channel programming for the
AR5416 and AR9280, but leave it disabled by default.

TL;DR: don't enable this code at all unless you go through the process
of getting the NIC re-certified.  This is purely to be used as a
reference and NOT a certified solution by any stretch of the imagination.

The background:

The AR5112 RF synth right up to the AR5133 RF synth (used on the AR5416,
derivative is used for the AR9130/AR9160) only implement down to 2.5MHz
channel spacing in 5GHz.  Ie, the RF synth is programmed in steps of 2.5MHz
(or 5, 10, 20MHz.) So they can't represent the quarter rate channels
in the 4.9GHz PSB (which end in xxx2MHz and xxx7MHz).  They support
fractional spacing in 2GHz (1MHz spacing) (or things wouldn't work,
right?)

So instead of doing this, the RF synth programming for the AR5112 and
later code will round to the nearest available frequency.

If all NICs were RF5112 or later, they'll inter-operate fine - they all
program the same. (And for reference, only the latest revision of the
RF5111 NICs do it, but the driver doesn't yet implement the programming.)

However:

* The AR5416 programming didn't at all implement the fractional synth
  work around as above;
* The AR9280 programming actually programmed the accurate centre frequency
  and thus wouldn't inter-operate with the legacy NICs.

So this patch:

* Implements the 4.9GHz PSB fractional synth workaround, exactly as the
  RF5112 and later code does;
* Adds a very dirty workaround from me to calculate the same channel
  centre "fudge" to the AR9280 code when operating on fractional frequencies
  in 5GHz.

HOWEVER however:

It is disabled by default.  Since the HAL didn't implement this feature,
it's highly unlikely that the AR5416 and AR928x has been tested in these
centre frequencies.  There's a lot of regulatory compliance testing required
before a NIC can have this enabled - checking for centre frequency,
for drift, for synth spurs, for distortion and spectral mask compliance.
There's likely a lot of other things that need testing so please don't
treat this as an exhaustive, authoritative list.  There's a perfectly good
process out there to get a NIC certified by your regulatory domain, please
go and engage someone to do that for you and pay the relevant fees.

If a company wishes to grab this work and certify existing 802.11n NICs
for work in these bands then please be my guest.  The AR9280 works fine
on the correct fractional synth channels (49x2 and 49x7Mhz) so you don't
need to get certification for that. But the 500KHz offset hack may have
the above issues (spur, distortion, accuracy, etc) so you will need to
get the NIC recertified.

Please note that it's also CARD dependent.  Just because the RF synth
will behave correctly doesn't at all mean that the card design will also
behave correctly.  So no, I won't enable this by default if someone
verifies a specific AR5416/AR9280 NIC works.  Please don't ask.

Tested:

I used the following NICs to do basic interoperability testing at
half and quarter rates.  However, I only did very minimal spectrum
analyser testing (mostly "am I about to blow things up" testing;
not "certification ready" testing):

* AR5212 + AR5112 synth
* AR5413 + AR5413 synth
* AR5416 + AR5113 synth
* AR9280
2012-10-04 15:42:45 +00:00
Adrian Chadd
0eb8162623 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.)
2012-10-03 23:23:45 +00:00
Adrian Chadd
08977788d5 Track the last ANI TX/RX sample correctly.
This doesn't specifically fix the issue(s) i'm seeing in this 2GHz
environment (where setting/increasing spur immunity causes OFDM restart
errors to skyrocket through the roof; but leaving it at 0 would leave
the environment cleaner..)

Pointy-hat-to:	me, for committing this broken code in the first place.
2012-09-27 06:05:54 +00:00
Adrian Chadd
7403d1b9b2 Map the non-QoS TID to the voice queue, in order to ensure important
things like EAPOL frames make it out.

After a whole bunch of hacking/testing, I discovered that they weren't
being early-dropped by the stack (but I should look at ensuring that
later..) but were even making to the hardware transmit queue.
They were mostly even being received by the remote end.  However, the
remote end was completely ignoring them.

This didn't happen under 150-170MBit TCP tests as I'm guessing the TX
queue stayed very busy and the STA didn't do any scanning. However, when
doing 100Mbit/s of TCP traffic, the STA would do background scanning -
which involves it coming in and out of powersave mode with the AP.

Now, this is a total and utter hack around the real problems, which are:

* I need to implement proper power save handling and integrate it into
  the filtered frames support, so the driver/stack doesn't send frames
  whilst the station is actually in sleep;

* .. but frames were actually making it to the STA (macbook pro) and
  the AP did receive an ACK; but a tcpdump on the receiving side showed
  the EAPOL frame never made it. So the stack was dropping it for
  some reason;

* Importantly - the EAPOL frames are currently going into the non-QoS
  TID, which maps to the BE queue and is susceptible to that queue being
  busy doing other things, but;

* There's other traffic going on in the non-QoS TID from other contexts
  when scanning is going on and it's possible there's some races causing
  sequence number/IV issues, but;

* Importantly importantlly, I think the interaction with TID 16 multicast
  traffic in power save mode is causing issues - since I -believe- the
  sequence number space being used by the EAPOL frames on TID 16 overlaps
  with the multicast frames that have sequence numbers allocated and
  are then stuffed on the cabq.  Since with EAPOL frames being in TID 16
  and queued to the BE queue, it's going to be waiting to be serviced
  with all of the aggregate traffic going on - and if the CABQ gets
  emptied beforehand, those TID 16 multicast frames with sequence numbers
  will go out beforehand.

Now, there's quite likely a bunch of "stuff happening slightly out of
sequence" going on due to the nature of the TX path (read: lots of
overlapping and concurrent ath_start() and ath_raw_xmit() calls going
on, sigh) but I thought I had caught them all and stuffed each TID TX
behind a lock (that lasted as long as it needed to in order to get
the frame onto the relevant destination queue - thus keeping things
in order.)

Unfortunately the last problem is the big one and I'm going to stare at
it some more.  If it _is_

So this is a work around for now to ensure that EAPOL frames actually
make it out before any other stuff in the non-QoS TID and HOPEFULLY
before the CABQ gets active.

I'm now going to spend a little time in the TX path figuring out exactly
why the sender is rejecting things. There's two (well, three if you count
EAPOL contents invalid) possibilities:

* The sequence number is out of order (ie, something else like the multicast
  traffic on CABQ) is going out first on TID 16;
* The CCMP IV is out of order (similar to above - but less likely,  as the
  TX key for multicast traffic is different to unicast traffic);
* EAPOL contents strangely invalid.

AP: Ubiquiti RSPRO, AR9160/AR9220 NICs
STA: Macbook Pro, Broadcom 11n NIC
2012-09-26 03:45:42 +00:00
Adrian Chadd
0a54471901 Oops - don't do the clrdmask check in ath_tx_xmit_normal() - the wrong
lock may be held.

Kim reported that the TID lock wasn't held when ath_tx_update_clrdmask()
was called. Well, the underlying hardware TXQ for that TID.

I'm betting it's the cabq stuff. ath_tx_xmit_normal() can be called
for both real and software cabq.  For software cabq, the real destination
txq is different to the txq. So, the lock check will fail.

Reported by:	Kim Culhan <w8hdkim@gmail.com>
2012-09-25 20:41:43 +00:00
Adrian Chadd
23f44d2b30 Call ath_tx_tid_unsched() after the node has been flushed, so the
state can be printed correctly.
2012-09-25 05:56:59 +00:00
Adrian Chadd
0368251456 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.
2012-09-24 20:35:56 +00:00
Adrian Chadd
6d24c7dbab Debugging output fixes:
* use the correct frame status - although the completion descriptor is
  the _last_ in the frame/aggregate, the status is currently stored in
  the _first_ buffer.

* Print out ath_buf specific fields once, not per descriptor in an ath_buf.
2012-09-24 19:48:41 +00:00
Adrian Chadd
0c54de88e6 Prepare for software retransmission of non-aggregate frames but ensure
it's disabled.

The previous commit to enable CLRDMASK setting didn't do it at all
correctly for non-aggregate sessions - so the CLRDMASK bit would be
cleared and never re-set.

* move ath_tx_update_clrdmask() to be called by functions that setup
  descriptors and queue frames to the hardware, rather than scattered
  everywhere.

* Force CLRDMASK to be set on all non-aggregate session frames being
  transmitted.

* Use ath_tx_normal_comp() now on non-aggregate sessoin frames
  that are queued via ath_tx_xmit_normal().  That way the TID hwq is
  updated and they can trigger (eventual) filter frame queue resets
  and software retransmits.

There's still a bit more work to do in this area to reverse the silly
short-sightedness on my part, however it's likely going to be better
to fix this now than just reverting the patch.

Thanks to people on the freebsd-wireless@ mailing list for promptly
pointing this out.
2012-09-24 06:42:20 +00:00
Adrian Chadd
94eefcf1dc In (eventual) preparation for supporting disabling the whole 11n/software
retry path - add some code to make it obvious (to me!) how to disable
the software tx path.
2012-09-24 06:00:51 +00:00
Adrian Chadd
4e81f27c59 Introduce the CLRDMASK gating based on tid->clrdmask, enabling filtered
frames to occur.

* Create a new function which will set the bf_flags CLRDMASK bit
  if required.
* For raw frames, always set CLRDMASK.
* For BAR, ADDBA frames, always set CLRDMASK.
* For everything else, check if CLRDMASK needs to be set before
  calling tx_setds() or tx_setds11n().
* When unpausing a queue or drain/resetting it, set tid->clrdmask=1
  just to ensure traffic starts flowing.

What I need to do:

* Modify that function to _clear_ the CLRDMASK if it's not required,
  or retried frames may have CLRDMASK set when they don't need to.
  (Which isn't a huge deal, but..)

Whilst I'm here:

* ath_tx_normal_xmit() should really act like the AMPDU session TX
  functions - any incomplete frames will end up being assigned
  ath_tx_normal_comp() which will decrement tid->hwq_depth - but that
  won't have been incremented.

  So whilst I'm here, add a comment to do that.

* Fix the debug print function to be slightly clearer about things;
  it's not a good sign when I can't interpret my own debugging output.

I've done some testing on AR9280/AR5416/AR9160 STA and AP modes.
2012-09-20 03:13:20 +00:00
Adrian Chadd
d05b576d61 Place the comment where it should be. 2012-09-20 03:04:19 +00:00
Adrian Chadd
088d8b81f3 Add a work-around for some strange net80211 BAR races in the wireless
stack.

There are unfortunately quite a few odd cases in BAR TX and BAR TX
retransmission that I haven't yet fully diagnosed.  So for now, add
this work-around so the resume() function isn't called too often,
decrementing pause to -1 (and causing things to stay paused.)
2012-09-20 03:03:01 +00:00
Adrian Chadd
0aa5c1bbf5 Oops - take a copy of ath_tx_status from the buffer before the TX processing
is done.

The aggregate path was definitely accessing 'ts' before it was actually
being assigned.

This had the side effect of over-filtering frames, since occasionally that
bit would be '1'.

Whilst here, do the same thing in the non-aggregate completion function -
as calling the filter function may also invalidate bf.

Pointy hat to: adrian, for not noticing this over many, many code reviews.
2012-09-18 20:33:04 +00:00
Adrian Chadd
f1bc738ece Implement my first cut at filtered frames in aggregation sessions.
The hardware can optionally "filter" frames if successive transmissions
to a given node (ie, "entry in the keycache") fail.  That way the hardware
can implement a kind of early abort of all the other frames queued to
that destination, rather than simply trying to TX each frame to that
destination (and failing.)

The background:

* If a frame comes back as being filtered, the hardware didn't try to
  TX it (or it was outside the TX burst opportunity.) So, take it as a hint
  that some (but not all, see below) frames to the destination may be
  filtered.

* If the CLRDMASK bit is set in a TX descriptor, the "filter to this
  destination" bit in the keycache entry is cleared and TX to that host
  will be unconditionally retried.

* Right now everything has the CLRDMASK bit set, so filtered frames
  tend to be aggregates and frames that fall outside of the WME burst
  window. It was a bit worse in the past as I had messed up the TX
  flags and CLRDMASK wasn't being set on aggregate frames.

The annoying bits:

* It's easy (ish) to do for aggregate session frames - firstly, they
  can be retried in any order as long as they're within the BAW, and
  there's already a bunch of infrastructure tracking how many frames
  the TID has queued to the hardware (tid->hwq_depth.) However, for
  frames that bypassed the software queue, hwq_depth doesn't get
  incremented. I'll fix that in a subsequent commit.

* For non-aggregate session frames, the only retries that can occur
  are ones for sequence numbers that hvaen't successfully been TXed yet.
  Since there's no re-ordering going on in non-aggregate sessions, if any
  subsequent seqno frames make it out, any filtered frames before that
  seqno need to be dropped.

  Hence why this initially is just for aggregate session frames.

* Since there may be intermediary frames to the destination that
  have CLRDMASK set - for example, any directly dispatched management
  frames to that destination - it's possible that there will be some
  filtered frames followed up by some non filtered frames.  Thus,
  it can't be assumed that once you see a filtered frame for the given
  destination node, all subsequent frames for all TIDs will be filtered.

Ok, with that in mind:

* Create a per-TID filtered frame queue for frames that the hardware
  returns as filtered.

* Track filtered frames per-tid, rather than per-node.  It just makes
  the locking much easier.

* When a filtered frame appears in the completion function, the node
  transitions to "filtered", and all subsequent completed error frames
  (filtered or otherwise) are put on the filtered frame queue.  The TID
  is paused once (during the transition from non-filtered to filtered).

* If a filtered frame retry count exceeds SWMAX_RETRIES, a BAR should be
  sent.

* Once all the frames queued to the hardware for the given filtered frame
  TID, transition back from filtered frame to non-filtered frame, which
  means pre-pending all the filtered frames onto the head of the software
  queue, clearing the filtered frame state and unpausing the TID.

Things get quite hairy around handling completion (aggr, non-aggr, norm,
direct-dispatched frames to a hardware queue); whether it's an "error",
"cleanup" or "BAR" state as well as filtered, which order to do things
in (eg do filtered BEFORE checking for BAR, as the filter completion
may be needed to actually transmit a BAR frame.)

This work has definitely reminded me that I have to tidy up all the locking
and remove some of the ridiculous lock/unlock/lock/unlock going on in the
completion functions.

It's also reminded me that I should really split out TID versus hardware TXQ
locking, even if the underlying locking is still the destination hardware TXQ.

Finally, this is all pre-requisite for working on AP mode power save support
(PS-POLL, uAPSD) as well as improving performance to misbehaving nodes (as
they can transition into filter mode, stopping any TX until everything has
caught up.)

Finally (ish) - this should also be done for non-aggregate sessions as
there are still plenty of laptops and mobile devices that don't speak
802.11n but do wish for stable, useful power save AP support where packets
aren't simply dropped.  This requires software retransmission for
non-aggregate sessions to be implemented, which includes the caveats I've
mentioned above.

Finally finally - this doesn't yet do anything about the CLRDMASK bit in the
TX descriptor.  That's still unconditionally set to 1.  I'll debug the
current work (mostly ensuring I haven't busted up the hairy transitions
between BAR, filtered, error (all frames in an aggregate failing) and
cleanup (when transitioning from aggregation -> non-aggregation.))

Finally finally finally - this is all original work by yours truely, rather
than ported from the Atheros internal driver codebase or Linux ath9k.

Tested:
 * AR9280, AR5416 in STA mode
 * AR9280, AR9130 in hostap mode
 * Lots and lots of iperf testing in very marginal and non-marginal conditions,
   complete with inducing filtered frames + BAR TX conditions.
2012-09-18 10:14:17 +00:00