On Thu, 2010-12-16 at 04:46 -0800, Paul Stewart wrote: > >> I haven't dug deep into it, but I can guess at a reason -- ath9k stores idle > >> state in two different places -- one is meant to mirror mac80211's state, > >> and the other one is internal, periodically computed from the state of all > >> wiphys. The ath9k version of the fix modified the > >> internal state without the mac80211 mirror. > > > > But at this point mac80211 doesn't care what the state is any more. > > Huh? I'm not sure I understand this statement. If mac80211 suspends > and resumes with open_count > 1 (e.g, with an associated STA), I argue > mac80211 _does_ care what the state is. In fact, although we called > stop() on the driver, there's every expectation that on resume any state > stored on suspend is recovered. Are you not assuming this? Not really -- the driver may throw away all internal state, mac80211 will (attempt to) restore it all through drv_config() with changed = ~0. Evidently ath9k has some magic that makes this fail? 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