"Luis R. Rodriguez" <lrodriguez@xxxxxxxxxxx> writes: > When mac80211 was telling us to go into Powersave we listened > and immediately turned RX off. This meant hardware would not > see the ACKs from the AP we're associated with and hardware > we'd end up retransmiting the null data frame in a loop > helplessly. > > Fix this by keeping track of the transmitted nullfunc frames > and only when we are sure the AP has sent back an ACK do we > go ahead and shut RX off. [...] > This should illustrate some changes we need on mac80211 to help > with enabling and completing dynamic PS. To be exact this is not about dynamic power save but HW_PS_NULLFUNC_STACK support. > The If we don't get an ACK we be able to tell mac80211 enabling > dynamic PS failed so it can stop assuming we've successfully enabled > it. Yes, currently mac80211 assumes that the hardware will wait for the ack before turning off radios. It might be a bit tricky to implement the ack delay in mac80211, for example we need to support the case when timeout is zero. Adding more timers to mac80211 creates more bugs. Also mac80211 doesn't check at all if the nullfunc frame reached the AP or not. I think that should be also fixed because it's a problem with every driver using IEEE80211_HW_PS_NULLFUNC_STACK. > Curious how this works with other hardware. When you enable > dynamic PS can you easily check for the ACK from the AP? On stlc45xx firmware does go to sleep before ACK is received. > What can we do on mac80211 to help with this without making it > too complex? What drivers need this? I guess at least ath5k and ath9k? Is it simpler if we just implement this in driver and not in mac80211? (Just asking, I don't have an opinion yet.) -- Kalle Valo -- 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
