Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 24
Dear Compex ‘s Partner and Friends We are having Chinese New Year holiday till 18th Feb 2013 . We will reply your email as soon as we back from holiday Remy Liaw Sales Account Manager www.compex.com.sg T +65 62862086 | F +65 62809947 Let's Connect! Facebook Twitter Blog Youtube Compex Systems – Your Trusted Partner in Wireless Co ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] question about ar2313
Hallo devs,
currently i porting barebox to ar2313a WiSoC. I know there is redboot,
but i do it just for fun.
Most basics are working now, including ethernet driver - except there is
one issue with it. After RX is enabled, rx ringbuffer starting getting
filled. If there is lots of broadcasts and buffer is full, first packet
of my transaction can be lost.
Are there any way to filter bcasts by hardware? Is it possible to get
documentation for this chip? It will be especially interesting then i
start to work on bootstrap part.
In attachment is the eth driver for barebox.
--
Regards,
Oleksij
/*
* ar231x.c: Linux driver for the Atheros AR231x Ethernet device.
* Based on Linux driver:
* Copyright (C) 2004 by Sameer Dekate sdek...@arubanetworks.com
* Copyright (C) 2006 Imre Kaloz ka...@openwrt.org
* Copyright (C) 2006-2009 Felix Fietkau n...@openwrt.org
* Ported to Barebox:
* Copyright (C) 2013 Oleksij Rempel bug-tr...@fisher-privat.net
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
/*
* Known issues:
* - broadcast packets are not filtered by hardware. On noisy network with
* lots of bcast packages rx_buffer can be completely filled after. It seems
* to be OK on transmission (we will clean it), but it is not nice on stand by.
* In this case we may lose first transmission after stand by.
*/
#include driver.h
#include init.h
#include mach/ar231x_platform.h
#include common.h
#include net.h
#include ar231x2.h
#include asm/addrspace.h
#include asm/io.h
#include linux/phy.h
/* Allocate 64 RX buffers. This will reduce packet loss, until we will start
* processing them. It is important in noisy network with lots of broadcasts. */
#define AR2313_RXDSC_ENTRIES 64
#define DSC_NEXT(idx)((idx + 1) (AR2313_RXDSC_ENTRIES - 1))
/* Use system default buffers size. At the moment of writing it was 1518 */
#define AR2313_RX_BUFSIZE PKTSIZE
#define CRC_LEN 4
#define virt_to_phys(x) ((u32)(x) 0x1fff)
static int ar231x_set_ethaddr(struct eth_device *edev, unsigned char *addr);
static void ar231x_reset_regs(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
struct ar231x_eth_platform_data *cfg = priv-cfg;
u32 flags;
debug(%s\n, __func__);
*priv-int_regs |= cfg-reset_mac;
mdelay(10);
*priv-int_regs = ~cfg-reset_mac;
mdelay(10);
*priv-int_regs |= cfg-reset_phy;
mdelay(10);
*priv-int_regs = ~cfg-reset_phy;
mdelay(10);
priv-dma_regs-bus_mode = DMA_BUS_MODE_SWR;
mdelay(10);
priv-dma_regs-bus_mode =
((32 DMA_BUS_MODE_PBL_SHIFT) | DMA_BUS_MODE_BLE);
priv-dma_regs-xmt_base = virt_to_phys(priv-tx_ring);
priv-dma_regs-rcv_base = virt_to_phys(priv-rx_ring);
priv-dma_regs-control =
(DMA_CONTROL_SR | DMA_CONTROL_ST | DMA_CONTROL_SF);
priv-eth_regs-flow_control = FLOW_CONTROL_FCE;
/* TODO: not sure if we need it here. */
priv-eth_regs-vlan_tag = (0x8100);
/* Enable Ethernet Interface */
flags = (MAC_CONTROL_TE | /* transmit enable */
/* MAC_CONTROL_PM - pass mcast.
* Seems like it makes no difference on some WiSoCs,
* for example ar2313. */
MAC_CONTROL_PM |
MAC_CONTROL_F | /* full duplex */
MAC_CONTROL_HBD); /* heart beat disabled */
priv-eth_regs-mac_control = flags;
}
static void ar231x_flash_rxdsc(ar231x_descr_t *rxdsc)
{
rxdsc-status = DMA_RX_OWN;
rxdsc-devcs = ((AR2313_RX_BUFSIZE DMA_RX1_BSIZE_SHIFT) |
DMA_RX1_CHAINED);
}
static void ar231x_allocate_dma_descriptors(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
u16 ar231x_descr_size = sizeof(ar231x_descr_t);
u16 i;
debug(%s\n, __func__);
priv-tx_ring = xmalloc(ar231x_descr_size);
dev_dbg(edev-dev, allocate tx_ring @ %p\n, priv-tx_ring);
priv-rx_ring = xmalloc(ar231x_descr_size * AR2313_RXDSC_ENTRIES);
dev_dbg(edev-dev, allocate rx_ring @ %p\n, priv-rx_ring);
priv-rx_buffer = xmalloc(AR2313_RX_BUFSIZE * AR2313_RXDSC_ENTRIES);
dev_dbg(edev-dev, allocate rx_buffer @ %p\n, priv-rx_buffer);
/* Initialize the rx Descriptors */
for (i = 0; i AR2313_RXDSC_ENTRIES; i++) {
ar231x_descr_t *rxdsc = priv-rx_ring[i];
ar231x_flash_rxdsc(rxdsc);
rxdsc-buffer_ptr = (uint)(priv-rx_buffer + AR2313_RX_BUFSIZE * i);
rxdsc-next_dsc_ptr = virt_to_phys(priv-rx_ring[DSC_NEXT(i)]);
}
}
static void ar231x_adjust_link(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
u32 mc;
debug(%s\n, __func__);
if (edev-phydev-duplex != priv-oldduplex) {
mc = priv-eth_regs-mac_control;
mc = ~(MAC_CONTROL_F | MAC_CONTROL_DRO);
if (edev-phydev-duplex)
mc |= MAC_CONTROL_F;
else
mc |= MAC_CONTROL_DRO;
priv-eth_regs-mac_control = mc;
priv-oldduplex = edev-phydev-duplex;
}
}
static int ar231x_eth_init(struct eth_device *edev)
{
struct ar231x_eth_priv *priv = edev-priv;
debug(%s\n, __func__);
Re: [ath9k-devel] [RFCv2 2/3] mac80211: mesh power save doze scheduling
On Mon, 2013-02-11 at 13:03 +0100, Marco Porsch wrote: On 02/08/2013 10:57 PM, Johannes Berg wrote: On Fri, 2013-02-08 at 11:09 +0100, Marco Porsch wrote: For mesh Awake Windows wakeup on SWBA (beacon_get_tim) and start a timer which triggers a doze call on expiry. That seems questionable -- drivers are not required to request each beacon. I know you only want to make it work on ath9k, but I don't think stretching the API, without even documenting it, is a good idea. Currently, we already use ieee80211_beacon_get_tim as time reference for mesh sync's adjust_tbtt. And, as far as I know, all mesh-capable drivers use the call for each and every beacon. Oops, why did I miss that before? :-) So what would you recommend: keep using beacon_get and adding documentation - or - creating an exported callback for awake_window_start? I guess you could add it... However, I don't really fully understand. There's no guarantee that fetching the beacon is done anywhere close to TBTT? Or does ath9k happen to do it just after TXing a beacon? You're encoding quite a lot of ath9k-specific assumptions here it seems? I think the assumption is currently correct for ath5k, ath9k, ath9k_htc, carl9170 and rt2800 (that's as far as I checked). All of these fetch a beacon on SWBA/PRETBTT interrupt (more or less) immediately before TBTT. It's still pretty bad to make that assumption implicitly -- I think you should at least document it as a big todo item :) johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On Wed, 2013-02-06 at 15:01 -0600, Seth Forshee wrote: The powersave configuration in struct ieee80211_conf is currently a binary state, either enabled or disabled. This is inadequate for expressing the situation during off-channel operation, when powersave is set at the AP to request bufferring of frames but the hardware remains fully awake. Some drivers (e.g. brcmsmac) need to perform configuration to support this in-between state but lack the information to do so. To prepare for adding an off-channel powersave mode, expand the current powersave configuration flag to two bits to support expressing another state. Add helper functions for setting and retrieving the state, and convert mac80211 and drivers to use these functions. In changing from a binary flag to powersave mode, also update the terminology used to name the states for clarity. The enabled state is changed to doze to indicate a low power hardware state, and the disabled state is changed to awake to indicate a fully powerd on hardware state. This is consistent with the terminology defined in IEEE 802.11-2012 section 10.2.1.2. Ok so I'm reviewing this again. I'm not really convinced this is the right thing to do. Sooner or later, multi-virtual interface support will become more relevant, and then all of this is completely moot because then powersave is entirely disabled and not handled right now. Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On Wed, Feb 13, 2013 at 04:06:10PM +0100, Johannes Berg wrote: On Wed, 2013-02-06 at 15:01 -0600, Seth Forshee wrote: The powersave configuration in struct ieee80211_conf is currently a binary state, either enabled or disabled. This is inadequate for expressing the situation during off-channel operation, when powersave is set at the AP to request bufferring of frames but the hardware remains fully awake. Some drivers (e.g. brcmsmac) need to perform configuration to support this in-between state but lack the information to do so. To prepare for adding an off-channel powersave mode, expand the current powersave configuration flag to two bits to support expressing another state. Add helper functions for setting and retrieving the state, and convert mac80211 and drivers to use these functions. In changing from a binary flag to powersave mode, also update the terminology used to name the states for clarity. The enabled state is changed to doze to indicate a low power hardware state, and the disabled state is changed to awake to indicate a fully powerd on hardware state. This is consistent with the terminology defined in IEEE 802.11-2012 section 10.2.1.2. Ok so I'm reviewing this again. I'm not really convinced this is the right thing to do. Sooner or later, multi-virtual interface support will become more relevant, and then all of this is completely moot because then powersave is entirely disabled and not handled right now. Hmm, I don't recall you really going into any detail regarding powersave, only managing the queues for off-channel. Though I can see that multi-vif throws a wrench into things, even if I don't understand all the details. Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable PS is sent the flag won't be set, as we're still on the operating channel. When we're actually off-channel the value of PM doesn't matter for the types of frames which are being sent. The only quick fix I've found is to watch out for frames with PM set and set the powersave bit while they're being transmitted. I'm going to have to spend some time trying to grok how powersave would work out with multiple interfaces. Honestly though I don't know that multiple interfaces is something that we have any interest in at the moment, and if not then it may be difficult for me to justify spending much time on it. Seth ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 25
Dear Compex ‘s Partner and Friends We are having Chinese New Year holiday till 18th Feb 2013 . We will reply your email as soon as we back from holiday Remy Liaw Sales Account Manager www.compex.com.sg T +65 62862086 | F +65 62809947 Let's Connect! Facebook Twitter Blog Youtube Compex Systems – Your Trusted Partner in Wireless Co ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] question about ar2313
I'm (slowly) working on getting approval to open up datasheets.. I'll post when this is done. Adrian On 13 February 2013 04:39, Oleksij Rempel bug-tr...@fisher-privat.net wrote: Hallo devs, currently i porting barebox to ar2313a WiSoC. I know there is redboot, but i do it just for fun. Most basics are working now, including ethernet driver - except there is one issue with it. After RX is enabled, rx ringbuffer starting getting filled. If there is lots of broadcasts and buffer is full, first packet of my transaction can be lost. Are there any way to filter bcasts by hardware? Is it possible to get documentation for this chip? It will be especially interesting then i start to work on bootstrap part. In attachment is the eth driver for barebox. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On 02/13/2013 06:04 PM, Seth Forshee wrote: Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable PS is sent the flag won't be set, as we're still on the operating channel. When we're actually off-channel the value of PM doesn't matter for the types of frames which are being sent. The only quick fix I've found is to watch out for frames with PM set and set the powersave bit while they're being transmitted. I actually don't see that one fly. The frames are posted on a DMA fifo towards the hardware so in the driver we have no clue when that frame is being processes/transmitted hence no way of knowing when to write the register(s). Gr. AvS ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On Wed, 2013-02-13 at 19:54 +0100, Arend van Spriel wrote: On 02/13/2013 06:04 PM, Seth Forshee wrote: Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable PS is sent the flag won't be set, as we're still on the operating channel. When we're actually off-channel the value of PM doesn't matter for the types of frames which are being sent. The only quick fix I've found is to watch out for frames with PM set and set the powersave bit while they're being transmitted. I actually don't see that one fly. The frames are posted on a DMA fifo towards the hardware so in the driver we have no clue when that frame is being processes/transmitted hence no way of knowing when to write the register(s). I think the various flushing would prevent issues there, no? johannes ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On Wed, Feb 13, 2013 at 01:25:19PM -0600, Seth Forshee wrote:
On Wed, Feb 13, 2013 at 07:54:19PM +0100, Arend van Spriel wrote:
On 02/13/2013 06:04 PM, Seth Forshee wrote:
Is all this really worth it? It seems a quick fix for brcmsmac might be
to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is
enabled in the config, and then go implement a real solution like I
described earlier with powersave being separated out of the core
mac80211 routines, and actually made possible for multiple interfaces?
Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable
PS is sent the flag won't be set, as we're still on the operating
channel. When we're actually off-channel the value of PM doesn't matter
for the types of frames which are being sent. The only quick fix I've
found is to watch out for frames with PM set and set the powersave bit
while they're being transmitted.
I actually don't see that one fly. The frames are posted on a DMA fifo
towards the hardware so in the driver we have no clue when that frame is
being processes/transmitted hence no way of knowing when to write the
register(s).
There's a couple of ways of doing it. I had a working patch at one point
but can't seem to find it now, so I'm not sure which way I used. You're
right though that we can't tell when the hardware is actually processing
or transmitting the frame, so in either case MCTL_HPS has to be set
before you put the frame in the tx fifo.
The first option is that for any frame with PM set, set MCTL_HPS when
mac80211 hands off the frame and clear it once it has finished
transmitting.
The second option is to look specifically for nullfunc frames and set or
clear MCTL_HPS based on the value of PM.
Either of these should work fine with the current mac80211 code, but
overall the second one is probably a little safer.
Aha, found the patch. It looks like it's the first option. I've pasted
it below. The changes look rather larger than they are in reality due to
shuffling some code around.
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c
b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 8d560b6..d1c6db6 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -825,6 +825,72 @@ static u32 brcms_c_setband_inact(struct brcms_c_info *wlc,
uint bandunit)
return macintmask;
}
+static void brcms_b_wait_for_wake(struct brcms_hardware *wlc_hw)
+{
+ /* delay before first read of ucode state */
+ udelay(40);
+
+ /* wait until ucode is no longer asleep */
+ SPINWAIT((brcms_b_read_shm(wlc_hw, M_UCODE_DBGST) ==
+ DBGST_ASLEEP), wlc_hw-wlc-fastpwrup_dly);
+}
+
+/*
+ * conditions under which the PM bit should be set in outgoing frames
+ * and STAY_AWAKE is meaningful
+ */
+static bool brcms_c_ps_allowed(struct brcms_c_info *wlc)
+{
+ struct brcms_bss_cfg *cfg = wlc-bsscfg;
+
+ /* disallow PS when one of the following global conditions meets */
+ if (!wlc-pub-associated)
+ return false;
+
+ /* disallow PS when one of these meets when not scanning */
+ if (wlc-filter_flags FIF_PROMISC_IN_BSS)
+ return false;
+
+ if (cfg-associated) {
+ /*
+* disallow PS when one of the following
+* bsscfg specific conditions meets
+*/
+ if (!cfg-BSS)
+ return false;
+
+ return false;
+ }
+
+ return true;
+}
+
+/* push sw hps and wake state through hardware */
+static void brcms_c_set_ps_ctrl(struct brcms_c_info *wlc, bool force_hps)
+{
+ u32 v1, v2;
+ bool hps = true;
+ bool awake_before;
+
+ if (!force_hps)
+ hps = brcms_c_ps_allowed(wlc);
+
+ brcms_dbg_mac80211(wlc-hw-d11core, wl%d: hps %d\n, wlc-pub-unit,
+ hps);
+
+ v1 = bcma_read32(wlc-hw-d11core, D11REGOFFS(maccontrol));
+ v2 = MCTL_WAKE;
+ if (hps)
+ v2 |= MCTL_HPS;
+
+ brcms_b_mctrl(wlc-hw, MCTL_WAKE | MCTL_HPS, v2);
+
+ awake_before = ((v1 MCTL_WAKE) || ((v1 MCTL_HPS) == 0));
+
+ if (!awake_before)
+ brcms_b_wait_for_wake(wlc-hw);
+}
+
/* process an individual struct tx_status */
static bool
brcms_c_dotxstatus(struct brcms_c_info *wlc, struct tx_status *txs)
@@ -983,6 +1049,9 @@ brcms_c_dotxstatus(struct brcms_c_info *wlc, struct
tx_status *txs)
if (txs-status TX_STATUS_ACK_RCV)
tx_info-flags |= IEEE80211_TX_STAT_ACK;
+
+ if (h-frame_control cpu_to_le16(IEEE80211_FCTL_PM))
+ brcms_c_set_ps_ctrl(wlc, false);
}
totlen = p-len;
@@ -1226,16 +1295,6 @@ static void brcms_b_info_init(struct brcms_hardware
*wlc_hw)
wlc_hw-chanspec = ch20mhz_chspec(1);
}
-static void
Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 26
Dear Compex ‘s Partner and Friends We are having Chinese New Year holiday till 18th Feb 2013 . We will reply your email as soon as we back from holiday Remy Liaw Sales Account Manager www.compex.com.sg T +65 62862086 | F +65 62809947 Let's Connect! Facebook Twitter Blog Youtube Compex Systems – Your Trusted Partner in Wireless Co ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On 02/13/2013 08:25 PM, Seth Forshee wrote: On Wed, Feb 13, 2013 at 07:54:19PM +0100, Arend van Spriel wrote: On 02/13/2013 06:04 PM, Seth Forshee wrote: Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable PS is sent the flag won't be set, as we're still on the operating channel. When we're actually off-channel the value of PM doesn't matter for the types of frames which are being sent. The only quick fix I've found is to watch out for frames with PM set and set the powersave bit while they're being transmitted. I actually don't see that one fly. The frames are posted on a DMA fifo towards the hardware so in the driver we have no clue when that frame is being processes/transmitted hence no way of knowing when to write the register(s). There's a couple of ways of doing it. I had a working patch at one point but can't seem to find it now, so I'm not sure which way I used. You're right though that we can't tell when the hardware is actually processing or transmitting the frame, so in either case MCTL_HPS has to be set before you put the frame in the tx fifo. The first option is that for any frame with PM set, set MCTL_HPS when mac80211 hands off the frame and clear it once it has finished transmitting. The second option is to look specifically for nullfunc frames and set or clear MCTL_HPS based on the value of PM. Either of these should work fine with the current mac80211 code, but overall the second one is probably a little safer. So you have verified that the last packet mac80211 sends before going off-channel is the nullfunc frame with PM bit set. I have seen packets coming in our driver during the .flush() callback, but never checked whether the last of those packets is indeed the nullfunc. Gr. AvS ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes
On Wed, Feb 13, 2013 at 10:43:14PM +0100, Arend van Spriel wrote: On 02/13/2013 08:25 PM, Seth Forshee wrote: On Wed, Feb 13, 2013 at 07:54:19PM +0100, Arend van Spriel wrote: On 02/13/2013 06:04 PM, Seth Forshee wrote: Is all this really worth it? It seems a quick fix for brcmsmac might be to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is enabled in the config, and then go implement a real solution like I described earlier with powersave being separated out of the core mac80211 routines, and actually made possible for multiple interfaces? Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable PS is sent the flag won't be set, as we're still on the operating channel. When we're actually off-channel the value of PM doesn't matter for the types of frames which are being sent. The only quick fix I've found is to watch out for frames with PM set and set the powersave bit while they're being transmitted. I actually don't see that one fly. The frames are posted on a DMA fifo towards the hardware so in the driver we have no clue when that frame is being processes/transmitted hence no way of knowing when to write the register(s). There's a couple of ways of doing it. I had a working patch at one point but can't seem to find it now, so I'm not sure which way I used. You're right though that we can't tell when the hardware is actually processing or transmitting the frame, so in either case MCTL_HPS has to be set before you put the frame in the tx fifo. The first option is that for any frame with PM set, set MCTL_HPS when mac80211 hands off the frame and clear it once it has finished transmitting. The second option is to look specifically for nullfunc frames and set or clear MCTL_HPS based on the value of PM. Either of these should work fine with the current mac80211 code, but overall the second one is probably a little safer. So you have verified that the last packet mac80211 sends before going off-channel is the nullfunc frame with PM bit set. I have seen packets coming in our driver during the .flush() callback, but never checked whether the last of those packets is indeed the nullfunc. The other set of patches I was working on ensures that the last frame before going off-channel is a nullfunc with PM set. The order of events is now: * stop the mac80211 queues with the offchannel stop reason * flush * send a nullfunc with PM set * flush again Without the first flush ath9k was often transmitting data frames with PM clear after the nullfunc. The second flush ensures the nullfunc gets sent before we go off-channel. Since the mac80211 queues are stopped during the flushes you shouldn't see any frames coming in (at least not during these flushes). I've done numerous wireshark traces with both brcmsmac and ath9k with these changes, and the nullfunc is the last thing on the air before going off-channel. Of course things still aren't working quite right with brcmsmac since the hardware is clearing the PM bit. Seth ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
