[RFC] iwlagn: reenable AP mode

[RFC] iwlagn: reenable AP mode

[John W. Linville]

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Really just poking around here...am I on the right track?  Or is the
iwlagn firmware supposed to handle buffering broadcast frames?

Looking at Johannes's docs, I don't see anything that seems
to relate to "implement sequence numbering for frames with the
IEEE80211_TX_CTL_ASSIGN_SEQ flag (or ask the hardware to do it for
those frames)".  Anyone know how to ask the hardware to do that?

I also don't see anything for "When sending probe response frames,
the timestamp must be adjusted by the hardware or firmware."  But,
I didn't look too hard -- maybe I missed it?

 drivers/net/wireless/iwlwifi/iwl-agn.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 2bbd04d..d02874e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -558,9 +558,17 @@ static void iwl_bg_beacon_update(struct work_struct *work)
 {
 	struct iwl_priv *priv =
 		container_of(work, struct iwl_priv, beacon_update);
-	struct sk_buff *beacon;
+	struct sk_buff *beacon, *skb;
 
-	/* Pull updated AP beacon from mac80211. will fail if not in AP mode */
+	/* Tx buffered bcast/mcast traffic. */
+	skb = ieee80211_get_buffered_bc(priv->hw, priv->vif);
+	while (skb) {
+		if (iwl_tx_skb(priv, skb))
+			dev_kfree_skb_any(skb);
+		skb = ieee80211_get_buffered_bc(priv->hw, priv->vif);
+	}
+
+	/* Pull updated AP beacon from mac80211. */
 	beacon = ieee80211_beacon_get(priv->hw, priv->vif);
 
 	if (!beacon) {
@@ -2316,7 +2324,8 @@ static int iwl_setup_mac(struct iwl_priv *priv)
 	hw->flags = IEEE80211_HW_SIGNAL_DBM |
 		    IEEE80211_HW_NOISE_DBM |
 		    IEEE80211_HW_AMPDU_AGGREGATION |
-		    IEEE80211_HW_SPECTRUM_MGMT;
+		    IEEE80211_HW_SPECTRUM_MGMT |
+		    IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
 
 	if (!priv->cfg->broken_powersave)
 		hw->flags |= IEEE80211_HW_SUPPORTS_PS |
@@ -2324,6 +2333,7 @@ static int iwl_setup_mac(struct iwl_priv *priv)
 
 	hw->sta_data_size = sizeof(struct iwl_station_priv);
 	hw->wiphy->interface_modes =
+		BIT(NL80211_IFTYPE_AP) |
 		BIT(NL80211_IFTYPE_STATION) |
 		BIT(NL80211_IFTYPE_ADHOC);
 
-- 
1.6.2.5

Re: [RFC] iwlagn: reenable AP mode

[John W. Linville]

On Mon, Nov 09, 2009 at 08:30:10PM -0500, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Really just poking around here...am I on the right track?  Or is the
> iwlagn firmware supposed to handle buffering broadcast frames?

This is completely untested, BTW...FYI!

John
-- 
John W. Linville                Someday the world will need a hero, and you
linville@tuxdriver.com                  might be all we have.  Be ready.

Re: [RFC] iwlagn: reenable AP mode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

On Mon, 2009-11-09 at 20:30 -0500, John W. Linville wrote:

> Really just poking around here...am I on the right track?  Or is the
> iwlagn firmware supposed to handle buffering broadcast frames?

I don't think this patch will work. When a beacon is updated and we then
send out multicast frames it's typically been quite a while since the
beacon was sent which can be quite bad for PS stations. I tried
something like this once and it didn't really work at all, ARP requests
went unanswered pretty much.

> Looking at Johannes's docs, I don't see anything that seems
> to relate to "implement sequence numbering for frames with the
> IEEE80211_TX_CTL_ASSIGN_SEQ flag (or ask the hardware to do it for
> those frames)".  Anyone know how to ask the hardware to do that?

It does that, but for legacy reasons iwlwifi makes it depend on whether
the frame is QoS or not without checking the flag. It also assigns its
own seqnos to qos frames ...

> I also don't see anything for "When sending probe response frames,
> the timestamp must be adjusted by the hardware or firmware."  But,
> I didn't look too hard -- maybe I missed it?

That is normally not required to be programmed specifically, but I don't
know in this case.

johannes

PS: you sent this patch as linville@linville-t41.local


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]