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

[Seth Forshee <seth.forshee@canonical.com>]

On Wed, Feb 06, 2013 at 05:48:10PM +0100, Johannes Berg wrote:
> 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? :)

PS_DOZE means it actually supports putting the hardware into a low-power
state for powersave. I did take the term from the spec (802.11-2012). It
is usually used with regard to mesh, but it also appears wrt
infrastructure BSS (see especially 10.2.1.2 which defines both awake and
doze in the context of infrastructure networks).

I'm open to other terms, doze just seems to be consistent with the spec.

I haven't considered wl1251 specifically, only enough to update it so
that it continues to build.

> > 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?

Yes.

Maybe what's confusing here is that I'm making a differentiation between
"powersave" as a mac-level feature and "powersave" as a low-power
hardware state. Which is why I'm trying to change the mac80211
terminology around so that "doze" now means the low-power state and
"powersave" refers only to the state in which the AP is bufferring
frames for us.

So using these definition powersave is already a mandatory feature for
any hardware which uses software scanning. All I'm really doing is
making this explicit, and drivers would now opt in to being placed into
the doze state rather than opting into powersave in general. And of
course drivers are now told about transitions to the non-doze powersave
state (what I'm calling offchannel), so that drivers which need to do
hardware configuration for this state can do so.

> > 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 :)

I've got working patches now, so maybe those will make everything clear.
I need to do a little more testing and give them a quick review, then
I'll send them out.

Seth