On Mon, Jan 31, 2011 at 04:38:16PM +0100, Ivo Van Doorn wrote: > >> > >> TODO: Split out mac80211 changes into a separate patch. We also need > >> to know if we need this check in mac80211 or in the driver. Personally I think the > >> check belongs in mac80211, but at this time that work has been deferred to the drivers. > >> However this means that a lot of logic is needed in the driver to check if the correct IE > >> is available, and then check the value, while mac80211 will obtains that exact IE anyway > >> during RX processing anyway... > > > > Hmm. I've always said that there's no efficient way to do this in > > mac80211. If you do it close to the beacon, unexpected latency means > > that we miss -- this can be severe if something else is happening in the > > system, especially with USB devices. If you do it early before the > > beacon, then you don't save much power. As a consequence, I don't really > > like this in mac80211. > > > > However, it seems you only added "stay awake after beacon" code to > > mac80211 that checks the TIM. Assuming the device actually stays awake > > for multicast traffic by itself that seems like an option, though I > > wouldn't wait for the next beacon before going to sleep again -- > > wouldn't that happen with the timer anyway? > > The timer is needed to automatically wake the device up in time to receive > the beacon. When the beacon is received all the driver needs to know if the > device should go back to sleep again for the next beacon period. > > This is a similar behavior as carl9170 driver, which currently checks for > pending Mcast/Bcast frames in the RX path just before the frame is send > to mac80211. FWIW, this bc/mc check is also on the mac80211 TODO list: http://wireless.kernel.org/en/developers/todo-list#power_saving 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
