Re: [PATCH 5/7] mac80211: Expand powersave configuration flag to be two bits

[Johannes Berg <johannes@sipsolutions.net>]

Hi Seth,

> I've been thinking about and playing around with these ideas. I've
> implemented the CONF_PM idea, and it does end up with fewer changes, but
> I just don't think separating powersave from setting PM makes much
> sense. In the end it just seems like a kludge to fix a problem with
> Broadcom chips, and if I want a kludge I can do it entirely within the
> driver.
> 
> So what I'm planning to do know is implement the awake/doze/offchannel
> powersave modes like I had mentioned, but taking things a bit further.
> I'd change IEEE80211_HW_SUPPORTS_PS to SUPPORTS_PS_DOZE, indicating
> support for a low-power powersave state rather than support for
> powersave in general.

Hm, I'm not sure I fully understand this. What does PS_DOZE mean then? I
think in the spec doze is a specific term for mesh?

Does it just mean "I support actually turning off the radio"? But then
what's the difference to supporting powersave? Can we maybe just
disregard wl1251, which has the stupidest powersave implementation on
the planet, and solve the "normal" problems first? :)

> All hardware will be reconfigured for
> awake<->offchannel transitions (though most drivers can simply ignore
> these transitions), but hardware will only be put in the doze state if
> it indicates PS_DOZE support.
> 
> This will make it compulsory for all drivers to indicate whether or not
> they require IEEE802111_HW_PS_NULLFUNC_STACK. I'll simply set this flag
> for any drivers not currently supporting powersave.

That seems odd, why would they advertise they want null-data packets for
powersave, when they don't have powersave? Just for the interaction with
scan/offchannel?

> In practice the changes shouldn't end up much different than what I have
> in these patches, but I think it's conceptually cleaner (and less
> confusing!). Does this sound reasonable to you?

Not really sure I understand it enough to comment :)

johannes