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. Seth _______________________________________________ ath9k-devel mailing list [email protected] https://lists.ath9k.org/mailman/listinfo/ath9k-devel
