[RFC/WIP 00/33] ath9k_htc AP mode

[RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

This series is the preliminary work for enabling AP mode for ath9k_htc.

A firmware update is needed, place look at:
http://wireless.kernel.org/en/users/Drivers/ath9k_htc#AP_Mode

Known issues:

* Beacon misses under heavy TX load
  ( hopefully, a fix would be sent out soon).

This has not been tested rigorously, so consider this series as
experimental code.

Sujith

Sujith Manoharan (33):
  ath9k_htc: Allow upto two simultaneous interfaces
  ath9k_htc: Unify target capability updation
  ath9k_htc: Fix error handling in add_interface
  ath9k_htc: Remove OP_PREAMBLE_SHORT
  ath9k_htc: Remove OP_PROTECT_ENABLE
  ath9k_htc: Remove OP_ASSOCIATED variable
  ath9k_htc: Set the BSSID mask for multiple interfaces
  ath9k_htc: Make sequence number calculation per-VIF
  ath9k_htc: Use VIF from the packet's control data
  ath9k_htc: Protect ampdu_action with a mutex
  ath9k_htc: Fix WMI and beacon header
  ath9k_htc: Maintain individual counters for interfaces
  ath9k_htc: Allow AP interface to be created
  ath9k_htc: Calculate and set the HW opmode
  ath9k_htc: Add ANI for AP mode
  ath9k_htc: Disable powersave if an AP interface is present
  ath9k_htc: Configure beacon timers in AP mode
  ath9k_htc: Add beacon slots
  ath9k_htc: Fix TBTT calculation for IBSS mode
  ath9k_htc: Add TSF adjust capability
  ath9k_htc: Configure the beacon queue
  ath9k_htc: Handle buffered frames in AP mode
  ath9k_htc: Enable AP mode
  ath9k_htc: Fix beacon miss under heavy load
  ath9k_htc: Queue WMI events
  ath9k_htc: Handle BSSID/AID for multiple interfaces
  ath9k_htc: Move debug code to a separate file
  ath9k_htc: Add RX error statistics
  ath9k_htc: Fix RX length check
  ath9k_htc: Fix host RX initialization
  ath9k_htc: Remove unused WMI commands
  ath9k_htc: Use SKB's private area for TX parameters
  ath9k_htc: Drain packets on station removal

 drivers/net/wireless/ath/ath9k/Makefile         |    2 +
 drivers/net/wireless/ath/ath9k/hif_usb.c        |   51 ++-
 drivers/net/wireless/ath/ath9k/htc.h            |  133 ++++-
 drivers/net/wireless/ath/ath9k/htc_drv_beacon.c |  432 ++++++++++++++--
 drivers/net/wireless/ath/ath9k/htc_drv_debug.c  |  310 +++++++++++
 drivers/net/wireless/ath/ath9k/htc_drv_init.c   |   14 +-
 drivers/net/wireless/ath/ath9k/htc_drv_main.c   |  649 +++++++++++------------
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c   |  127 +++--
 drivers/net/wireless/ath/ath9k/htc_hst.c        |   23 +-
 drivers/net/wireless/ath/ath9k/htc_hst.h        |    7 +-
 drivers/net/wireless/ath/ath9k/wmi.c            |   89 ++--
 drivers/net/wireless/ath/ath9k/wmi.h            |   18 +-
 12 files changed, 1329 insertions(+), 526 deletions(-)
 create mode 100644 drivers/net/wireless/ath/ath9k/htc_drv_debug.c

-- 
1.7.3.5

[RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

Sujith wrote:
> This series is the preliminary work for enabling AP mode for ath9k_htc.
> 

A unified patchset can be obtained here:
http://wireless.kernel.org/en/users/Drivers/ath9k_htc#AP_Mode

Sujith

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Christian Lamparter]

On Friday 21 January 2011 03:55:51 Sujith wrote:
> This series is the preliminary work for enabling AP mode for ath9k_htc.
> 
> A firmware update is needed, place look at:
> http://wireless.kernel.org/en/users/Drivers/ath9k_htc#AP_Mode
> 
> Known issues:
> 
> * Beacon misses under heavy TX load
>   ( hopefully, a fix would be sent out soon).
> 
> This has not been tested rigorously, so consider this series as
> experimental code.
> 
Hey that's great! I gave this series a quick whirl and it worked on the first try!
I had no probles getting ath9k to connect, well apart form a WARN_ON_ONCE

WARNING: at net/mac80211/tx.c:57 ieee80211_duration+0x50/0x1b3 [mac80211]()
Call Trace:
[  322.971940]  [<ffffffffa01d1cb0>] ? ieee80211_duration+0x50/0x1b3 [mac80211]
[  322.979297]  [<ffffffffa01d33d5>] ? invoke_tx_handlers+0xf65/0x1001 [mac80211]
[  322.987053]  [<ffffffffa01d0f2d>] ? ieee80211_prepare_and_rx_handle+0x7ff/0x845 [mac80211]
[  322.995865]  [<ffffffffa0004f5d>] ? usb_hcd_giveback_urb+0x76/0xa5 [usbcore]

but that's ok, ieee80211_duration does not make sense when
the rate control is done by the firmware.

--------

But what seems to be strange is the tx feedback...
Because it looks like ath9k_htc just sets IEEE80211_TX_STAT_ACK
for every frame, which obviously can't be "true", right? ;)

This might also break mac80211's *unicast buffering*.

Because the code in ieee80211_tx_status - net/mac80211/status.c
works like this:

211  acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
212  if (!acked && test_sta_flags(sta, WLAN_STA_PS_STA)) {
213		/*
214		 * The STA is in power save mode, so assume
215		 * that this TX packet failed because of that.
216		 */
217		ieee80211_handle_filtered_frame(local, sta, skb);
218		rcu_read_unlock();
219		return;
220	}
...
239	if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
240		ieee80211_handle_filtered_frame(local, sta, skb);
241		rcu_read_unlock();
242		return;
243	} else {
244		if (!acked)
245			sta->tx_retry_failed++;
246		sta->tx_retry_count += retry_count;
247	}

so, mac80211 will never know when it needs to resend certain
frame which could be affected by the race between the "sleepy"
station sending a frame with a PSM-bit set and mac80211 finally
updating the WLAN_STA_PS_STA flag.
[see long comment in mac80211/status.c @ line 73]

unless of course, you don't need it and the firmware can
buffer those frames until the STA comes back?!

Best regards,
	Christian

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

Christian Lamparter wrote:
> But what seems to be strange is the tx feedback...
> Because it looks like ath9k_htc just sets IEEE80211_TX_STAT_ACK
> for every frame, which obviously can't be "true", right? ;)
> 
> This might also break mac80211's *unicast buffering*.
> 
> Because the code in ieee80211_tx_status - net/mac80211/status.c
> works like this:
> 
> 211  acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
> 212  if (!acked && test_sta_flags(sta, WLAN_STA_PS_STA)) {
> 213		/*
> 214		 * The STA is in power save mode, so assume
> 215		 * that this TX packet failed because of that.
> 216		 */
> 217		ieee80211_handle_filtered_frame(local, sta, skb);
> 218		rcu_read_unlock();
> 219		return;
> 220	}
> ...
> 239	if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> 240		ieee80211_handle_filtered_frame(local, sta, skb);
> 241		rcu_read_unlock();
> 242		return;
> 243	} else {
> 244		if (!acked)
> 245			sta->tx_retry_failed++;
> 246		sta->tx_retry_count += retry_count;
> 247	}
> 
> so, mac80211 will never know when it needs to resend certain
> frame which could be affected by the race between the "sleepy"
> station sending a frame with a PSM-bit set and mac80211 finally
> updating the WLAN_STA_PS_STA flag.
> [see long comment in mac80211/status.c @ line 73]

What about hardware that doesn't report any kind of TX status information at all ?
Currently, there is no way to determine whether the frame has actually gone out,
all that can be known is that it was pushed to the target.

> unless of course, you don't need it and the firmware can
> buffer those frames until the STA comes back?!

Hm, unfortunately the firmware has no such feature currently.

Sujith

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

Sujith wrote:
> Sujith wrote:
> > What about hardware that doesn't report any kind of TX status information at all ?
> > Currently, there is no way to determine whether the frame has actually gone out,
> > all that can be known is that it was pushed to the target.
> 
> Am curious how carl9170 gets the TX status ?
> Is there a separate endpoint ?

I looked a bit into carl9170 and it looks like the TX status
is obtained as incoming data through the CMD endpoint, am I correct ?

And the cookie is used to match the status information with the approporiate
packet ?

Though for ath9k_htc this would mean changes in both the host and FW, the host has to queue
up packets in some kind of queue and process them on reception of status interrupts.
The FW has to be changed to actually deliver the TX status information. :)

It does make it a bit neat to have such a mechanism. And for AP mode, I would think
that it's kinda essential unless someone comes with an ingenious way of solving
the PS race for drivers that don't set IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)

Sujith

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Christian Lamparter]

On Saturday 22 January 2011 04:32:02 Sujith wrote:
> Sujith wrote:
> > Sujith wrote:
> > > What about hardware that doesn't report any kind of TX status information at all ?
> > > Currently, there is no way to determine whether the frame has actually gone out,
> > > all that can be known is that it was pushed to the target.
> > 
> > Am curious how carl9170 gets the TX status ?
> > Is there a separate endpoint ?
> 
> I looked a bit into carl9170 and it looks like the TX status
> is obtained as incoming data through the CMD endpoint, am I correct ?
yes and no ;).

The tx status is obtained from the (RX-) DATA [stream/] endpoint.
The (USB?) CMD endpoint is only being used for fatal 0xc6
watchdog events [which are generated by the bootloader].

> And the cookie is used to match the status information with the approporiate
> packet ?
The driver also gets the used ac queue index from the tx feedback message.
So it knows in which tx_status queue it has to look, but that's only
a minor detail.

> Though for ath9k_htc this would mean changes in both the host and FW, 
> the host has to queue up packets in some kind of queue and process them
> on reception of status interrupts. The FW has to be changed to actually
> deliver the TX status information. :)
You only have to have a sane tx status if the IEEE80211_TX_CTL_REQ_TX_STATUS
flag is set. In all other cases, the IEEE80211_TX_STAT_ACK handling is
*optional*. In fact if you don't set the TX_STAT_ACK flag, mac80211 will
automatically do the right thing when it sees that a STA has become
"temporarily" unavailable.

> It does make it a bit neat to have such a mechanism. And for AP mode,
> I would think that it's kinda essential unless someone comes with an
> ingenious way of solving the PS race for drivers that don't set
> IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)
Sure, IEEE80211_HW_REPORTS_TX_ACK_STATUS would be the way to go.
Especially because IEEE80211_HW_PS_NULLFUNC_STACK also benefits
from it.

Best regards,
	Chr

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

Christian Lamparter wrote:
> You only have to have a sane tx status if the IEEE80211_TX_CTL_REQ_TX_STATUS
> flag is set. In all other cases, the IEEE80211_TX_STAT_ACK handling is
> *optional*. In fact if you don't set the TX_STAT_ACK flag, mac80211 will
> automatically do the right thing when it sees that a STA has become
> "temporarily" unavailable.

Looking at mac80211, IEEE80211_TX_CTL_REQ_TX_STATUS is set only for mgmt and
a couple of action frames now, but of course this could be fixed for other
use cases too.

> Sure, IEEE80211_HW_REPORTS_TX_ACK_STATUS would be the way to go.
> Especially because IEEE80211_HW_PS_NULLFUNC_STACK also benefits
> from it.

Yeah, agreed.
Well, let's see how things turn out. :)

Sujith

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Johannes Berg]

On Sat, 2011-01-22 at 09:02 +0530, Sujith wrote:

> It does make it a bit neat to have such a mechanism. And for AP mode, I would think
> that it's kinda essential unless someone comes with an ingenious way of solving
> the PS race for drivers that don't set IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)

Well, you can handle the PS stuff in the device completely -- or do it
like iwlwifi does, where it doesn't rely on the ACK to detect the race,
but the firmware will reject TX frames to sleeping stations until the
driver tells it the station woke up.

How it works is like this:

STA AWAKE -> ASLEEP transition:
  - firmware marks station as asleep
  - firmware rejects TX frames for this station that are in queue
  - driver keeps track of # of such frames, and uses
    ieee80211_sta_block_awake() to block this station while it has
    frames in the queue
  - rejected frames are rejected to mac80211 and queued up

ASLEEP -> AWAKE:
  - due to ieee80211_sta_block_awake() wakeup is blocked until the
    queue has drained as well (if station very quick wakes up), then
    when both conditions are met,
  - driver tells device that this station woke up
  - mac80211 re-transmits all those frames
  - driver queues up all those frames

johannes

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Sujith]

Johannes Berg wrote:
> On Sat, 2011-01-22 at 09:02 +0530, Sujith wrote:
> 
> > It does make it a bit neat to have such a mechanism. And for AP mode, I would think
> > that it's kinda essential unless someone comes with an ingenious way of solving
> > the PS race for drivers that don't set IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-)
> 
> Well, you can handle the PS stuff in the device completely -- or do it
> like iwlwifi does, where it doesn't rely on the ACK to detect the race,
> but the firmware will reject TX frames to sleeping stations until the
> driver tells it the station woke up.
> 
> How it works is like this:
> 
> STA AWAKE -> ASLEEP transition:
>   - firmware marks station as asleep
>   - firmware rejects TX frames for this station that are in queue
>   - driver keeps track of # of such frames, and uses
>     ieee80211_sta_block_awake() to block this station while it has
>     frames in the queue
>   - rejected frames are rejected to mac80211 and queued up
> 
> ASLEEP -> AWAKE:
>   - due to ieee80211_sta_block_awake() wakeup is blocked until the
>     queue has drained as well (if station very quick wakes up), then
>     when both conditions are met,
>   - driver tells device that this station woke up
>   - mac80211 re-transmits all those frames
>   - driver queues up all those frames

Thanks for the explanation, but ath9k_htc has deeper problems in AP mode. :)

* The FW doesn't mark stations or add them to a filter list on receiving a
  PS-enable frame from a station.

* The host driver has no way of knowing if the FW failed to send out a frame,
  so keeping track of pending frames is impossible. Am not sure if ATH9K_TXERR_FILT
  is similar to TX_STATUS_FAIL_DEST_PS in iwlagn (I think not), so that can't be used
  either.
  
Sujith

Re: [RFC/WIP 00/33] ath9k_htc AP mode

[Johannes Berg]

On Sun, 2011-01-23 at 15:31 +0530, Sujith wrote:

> * The host driver has no way of knowing if the FW failed to send out a frame,
>   so keeping track of pending frames is impossible. Am not sure if ATH9K_TXERR_FILT
>   is similar to TX_STATUS_FAIL_DEST_PS in iwlagn (I think not), so that can't be used
>   either.

I don't know, but I thought it was supposed to be? At least mac80211
calls this "filtered" as well, which surely comes from Atheros
terminology.

johannes