Hi, >> Add a delayed work structure which can be used to wakeup the device >> just before a beacon from the AP is expected. This then allows the device >> to receive the beacon, check if there are pending broadcast or multicast frames. >> >> 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. Ivo -- 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
