Re: [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes

["Arend van Spriel" <arend@broadcom.com>]

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