Hi Johannes, > When we aren't doing anything in mac80211, we can turn off > much of the hardware, depending on the driver/hw. Not doing > anything, aka being idle, means: > > * no monitor interfaces > * no AP/mesh/wds interfaces > * any station interfaces are in DISABLED state > * any IBSS interfaces aren't trying to be in a network > * we aren't trying to scan > > By creating a new function that verifies these conditions and calling > it at strategic points where the states of those conditions change, > we can easily make mac80211 tell the driver when we are idle to save > power. > > Additionally, this fixes a small quirk where a recalculated powersave > state is passed to the driver even if the hardware is about to stopped > completely. > > This patch intentionally doesn't touch radio_enabled because that is > currently implemented to be a soft rfkill which is inappropriate here > when we need to be able to wake up with low latency. > > One thing I'm not entirely sure about is this: > > phy0: device no longer idle - in use > wlan0: direct probe to AP 00:11:24:91:07:4d try 1 > wlan0 direct probe responded > wlan0: authenticate with AP 00:11:24:91:07:4d > wlan0: authenticated > > phy0: device now idle > > phy0: device no longer idle - in use > wlan0: associate with AP 00:11:24:91:07:4d > wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1) > wlan0: associated > > Is it appropriate to go into idle state for a short time when we have > just authenticated, but not associated yet? This happens only with the > userspace SME, because we cannot really know how long it will wait > before asking us to associate. Would going idle after a short timeout > be more appropriate? We may need to revisit this, depending on what > happens. what about having the hardware set a value for how long something should be idle before you tell it. I am more thinking about some sort penalty value from the hardware that can not do this quickly. Regards Marcel -- 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