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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
