> In particular, I'm not sure what the right thing to do in regards to > PS wakeup is... Can you explain what you were _trying_ to do? I don't like calling this "driver_buffered" because that's already a term for frames that are buffered in the driver ... :-) PS is complicated, we basically transmit, in the following order: * filtered frames (tx_filtered) * buffered frames (ps_tx_buf) * regular frames This is when we _leave_ powersave. When we deliver frames while the station is sleeping (PS-Poll or U-APSD), they don't even go through the TXQ. They still come from this place, but currently go directly to the ->tx() method, which to me is actually pretty weird but that's what it is now. As I think I said in my other thread, we should probably eventually just get rid of ps_tx_buf entirely, instead just keeping the frames on the TXQ. Then, filtered can just be pushed onto txqi->frags [*], and we get rid of having that separately as well. Then, we've completely solved the wakeup scenario, we just start scheduling that TXQ normally again. For the deliver-while-sleeping (PS-Poll/U-APSD) scenario, I think the driver should still pull frames, after calling something like drv_release_buffered_frames(). We want this to be scheduled pretty much immediately, so we shouldn't just put the TXQ into the normal rotation, but otherwise it should work similarly - except limited to a certain number of frames [**]. In this case the driver probably needs to pull the frames using a different function so that we can a) tag the packets properly (more-data, EOSP) b) generate nulldata as EOSP container where needed Thus, it seems likely that we'll want a separate function, "pull for PS delivery" rather than the normal ieee80211_tx_dequeue(). johannes [*] ok not exactly, if there are frags there already things get messy. but we can probably solve that somehow without needing more special cases