On Wed, Feb 06, 2013 at 06:44:16PM +0100, Johannes Berg wrote: > > I haven't considered wl1251 specifically, only enough to update it so > > that it continues to build. > > Ah, wl1251 is the weird thing that wants to be told when to wake up/go > to sleep, and then sends nulldata packets itself ... so when we send > nulldata packets *again* for off-channel, because it also uses software > scanning. Like I said before -- "stupidest powersave implementation on > the planet". Ah, I had wondered what hardware that code was there for :-) So I think the approach I'm advocating could possibly make things better for wl1251. If it's told about going to off-channel powersave rather than being told it's leaving powersave, maybe it can do the right thing with the nullfunc frames without mac80211 generating the extra nullfunc. I don't know that for sure though because I don't understand how the hardware works. > > So using these definition powersave is already a mandatory feature for > > any hardware which uses software scanning. > > Even offloaded scanning, it's just not visible to mac80211 then. Okay, sure. I'm just thinking of things from the mac80211 perspective. > > 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. > > Ok, so maybe just calling it offchannel makes more sense, although that > really interacts only this way with powersave in managed mode, in P2P GO > mode .... oh well. I admit I've only been considering managed mode and know next to nothing about P2P GO mode. If I'm creating problems for any other modes I'd definitely like to know about it so I can take it into consideration. Seth -- 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
