K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-10-04T06:46:12.783201Z
K 7
svn:log
V 2152
Begin fleshing out queue handling during reset conditions.

Right now, all TX/RX queues are flushed during a reset. For non-11n
and 11n in non-addba, this just shows up as packet loss.

But for 11n + addba, this introduces holes in the TX/RX BAW tracking
algorithm and can result in traffic actually hanging.

The eventual aim here is to select whether to flush the TX/RX queue
during a reset, or handle the RX frames and reschedule the incomplete
TX frames.

There are complications however!

* If the flush is due to a stuck beacon or non-opmode config change
  (eg interference mitigation) then it's pretty clear, we can reschedule
  TX frames.

* If the flush is due to a frequency change, then yes, we have to flush
  everything and (I -think-) re-establish association and TX/RX addba state.
  I'll have to go over the spec (and implementations) to see what to do.

* If the flush is due to a channel width change, then we could in theory
  just handle all RX frames and resubmit all the TX frames for retransmission
  after correctly adjusting the rate control for the new width/GI.
  However we don't currently have a separate call for that - it's just done
  as a channel change.

* On a reset, we need to stop the RX DMA (so the MAC doesn't ACK any further
  frames) before we handle what's in the queue - and we need to ensure that
  the PCU and PCU RX DMA isn't re-enabled.

* If _any_ frames are dropped in an active aggregation session (and it's not
  a full reset due to a channel change) then we're going to have to TX a BAR
  frame. This is likely going to crop up if we're doing things like channel
  width management as I bet the general implementations out there expect to
  be able to do this without dropping the association and addba state.

In addition, we can't just call ath_rx_proc() from ath_reset() as things
stand because it's quite possible that ath_reset() will be called from a non-
taskqueue context (ie, an ioctl via net80211, or a net80211 task/callout.)
So before we can properly handle RX (and maybe TX, I haven't yet fully audited
all of that) we'll need to introduce the PCU locking to ensure things don't
race.

END