On Thu, Dec 16, 2010 at 4:04 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2010-12-16 at 03:51 -0800, Paul Stewart wrote: >> Fixing the problem in ath9k >> alone causes a separate problem. If you stop the driver from mac80211's >> pm.c, ath9k would set the device ps_idle, when mac80211 does not >> consider the device to to be idle. Thus, when we resume from suspend, >> the device stays quiescent (mac80211 has no reason to believe it needs >> to do anything special to be able to tx, receive beacons, etc.) > > How so? After resume, mac80211 will invoke start(), add interfaces and > stations back, and then invoke drv_config with all flags in "changed" > set. Therefore, at this point, the device should be reset. Where's this > not working? 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. The ath9k config() routine probably does nothing when called with "all changed" on resume because in fact, if we suspend and resume when non-idle, nothing _has_ changed from that perspective. I fear that unless ath9k gets changed more substantially, it really does need to be informed of IDLE changes. > I think the problem might be that ath9k is expecting mac80211 to > perfectly nest calls to idle/non-idle, even across suspend/resume and > device shutdown. I don't think that's feasible at all. -- Paul -- 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
