On Wed, 2013-01-16 at 23:34 -0600, Seth Forshee wrote: > On Thu, Jan 17, 2013 at 12:32:43AM +0100, Johannes Berg wrote: > > On Wed, 2013-01-09 at 07:40 -0600, Seth Forshee wrote: > > > > > > It turns out that fixing problem #1 (i.e. patch 2) probably isn't > > > > necessary with the other changes, as no frames should be sent while > > > > off-channel PS is enabled. Does this still seem like a problem worth > > > > fixing? > > > > > > This is incorrect. We actually do need patch 2 for some hardware. I > > > forgot that when I was testing with BCM43224 I found that PM gets > > > actively set or cleared based on the device configuration. It's > > > impossible to enable PS at the AP without informing the driver. > > > > Hm, don't understand. If we're not sending any packets to the AP, why > > does this matter? > > > > Or are you saying it wants nullfunc frames generated in software, but > > then changes the PM bit in them? > > Exactly. At least that's what it looks like to me. I lack detailed > knowledge of how to handle powersave on Broadcom, but I do know that the > PM bit is under the control of the MCTL_HPS field. Experimentally it > appears that the hardware actively clears PM when this field is 0 and > actively sets it when this field is 1, for all frames including > nullfuncs. Hm maybe that also answers my other question :-) Maybe for the benefit of such drivers instead of splitting the powersave state it would be easier to introduce a "PM bit state"? I don't know ... johannes -- 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
