Johannes Berg wrote: > On Sat, 2011-01-22 at 09:02 +0530, Sujith wrote: > > > It does make it a bit neat to have such a mechanism. And for AP mode, I would think > > that it's kinda essential unless someone comes with an ingenious way of solving > > the PS race for drivers that don't set IEEE80211_HW_REPORTS_TX_ACK_STATUS. :-) > > Well, you can handle the PS stuff in the device completely -- or do it > like iwlwifi does, where it doesn't rely on the ACK to detect the race, > but the firmware will reject TX frames to sleeping stations until the > driver tells it the station woke up. > > How it works is like this: > > STA AWAKE -> ASLEEP transition: > - firmware marks station as asleep > - firmware rejects TX frames for this station that are in queue > - driver keeps track of # of such frames, and uses > ieee80211_sta_block_awake() to block this station while it has > frames in the queue > - rejected frames are rejected to mac80211 and queued up > > ASLEEP -> AWAKE: > - due to ieee80211_sta_block_awake() wakeup is blocked until the > queue has drained as well (if station very quick wakes up), then > when both conditions are met, > - driver tells device that this station woke up > - mac80211 re-transmits all those frames > - driver queues up all those frames Thanks for the explanation, but ath9k_htc has deeper problems in AP mode. :) * The FW doesn't mark stations or add them to a filter list on receiving a PS-enable frame from a station. * The host driver has no way of knowing if the FW failed to send out a frame, so keeping track of pending frames is impossible. Am not sure if ATH9K_TXERR_FILT is similar to TX_STATUS_FAIL_DEST_PS in iwlagn (I think not), so that can't be used either. Sujith -- 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
