Ivo van Doorn <ivdoorn@xxxxxxxxx> writes: > 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. So the firmware/hardware doesn't have support for tracking and waking up for beacons? I didn't even know that such hardware exists :) Waking up for beacons from host sounds very inefficient and unrealiable. All the devices I have seen either do this in firmware or hardware due to time constraints. Even at76c50x-usb, which is ancient, does all this in firmware. Are you sure there's no way to do this with hardware? > 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... I'm worried that client power save support in mac80211 is getting quite complex already. How many drivers need this feature? And if hardware is so broken, is it really worth the effort of trying to implement power save with ugly hacks like this? If power consumption is important for the user, I would recommend just buying better hardware. -- 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
