On Mon, 2009-11-30 at 09:22 -0800, Luis R. Rodriguez wrote: > >> > + ieee80211_queue_work(&local->hw, &local->recalc_smps); > >> > >> OK from what I gather so far we just queue work if we received an ACK > >> from the action frame we sent. Since we tell the device to > >> ieee80211_stop_device() the device should have stopped RX'ing and that > >> *should* mean preventing processing future tx status reports. We'll > >> find out if that assumption is wrong. > > > > It's not about receiving -- only about transmitting. > > Yes but this is not about a actual transmit but a tx status. Right. > > But yeah, we'll > > find out. I have a patch pending that'll flush queues etc., that would > > make it completely impossible if implemented by the driver, but I don't > > think we need to worry about it. > > What I mean is that technically a driver could have called even this > new tx flush and yet *after* that was called a tx status for a > *previously* transmitted frame could have come through hardware, which > is why I mentioned hw stop. hw stop would seem to be the only thing > ensuring we don't queue more work if we'd try to pm-suspend between > the point where we enabled smps and before the AP sent an ACK to us > for the action frame. Yeah, I see what you're saying, I just don't think it'll actually happen. I guess we will find out by the warning if it ever does. > OK I see. Then the next question is can iwl3945 and iwlagn report tx > status for a nullfunc sent to an AP? It doesn't matter for them -- they do it all in the firmware. hw_scan and complete PS mode offload. > > Well, it doesn't matter either way. However, it was easier this way for > > iwlwifi because ultimately we want to turn off all but one chain if > > non-HT and/or static SMPS. So at least there it made sense to use STATIC > > here to avoid the extra check. But other drivers may or may not want to > > ignore it completely in the HT case. I've documented that it sets it to > > STATIC when a non-HT association is used just for more use. It could be > > anything really, or even an invalid value. Also remember that SMPS_OFF > > means all chains turned on. > > Hm -- so hardware would *typically* leave all chains on even for > legacy mode of operation? It depends on what you're after. You can leave them all on, and you'll have better reception. Or you can turn off all but one, and you'll save power. Better reception doesn't help you _much_ because the AP still also has to receive your stuff, and if it's a legacy AP it only has one chain so you receiving it well won't necessarily mean it receives you well enough for a connection -- we would therefore like to save more power and use only one chain on a legacy AP. Hence the default here, it makes it easier the way iwlwifi is done. I had "Automatic" here as the default in my first iteration of the patch but it just ended up being a few lines of code more in iwlwifi and no real difference in mac80211. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
