On Thu, Dec 16, 2010 at 4:35 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2010-12-16 at 04:27 -0800, Paul Stewart wrote: > >> > 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. > > 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? >> 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. > > Hmm, I still don't get it. The "idle just changed" flag is set -- and > idle will actually be what it was at suspend time. If ath9k was simply > setting its own idle state on stop(), and returning to what mac80211 > says when it first configures the device after start(), what would the > problem be? I don't have the code in front of me (in transit at the moment), but I'm pretty sure the config routine in ath9k only checks to see whether the idle state mac80211 passes in is different from the previous passed-in value. It doesn't care what its internal state is because it believed it was computed from mac80211 passed-in values. It may be possible to rework that code. >> I fear that unless ath9k gets changed more >> substantially, it really does need to be informed of IDLE changes. > > I'd rather have ath9k change more than try to enforce this perfectly in > mac80211. I still think that's brittle, and every little bug in a corner > case will cause severe problems since it causes suspend/resume to 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
