On Tue, Jan 6, 2009 at 10:05 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2009-01-06 at 20:36 +0100, Marcel Holtmann wrote: > >> since mac80211 gets suspend/resume support, I think it is the best that >> we signal this to wpa_supplicant. In that case it can do the hard work >> here. Either it re-connects to the last AP or signals a disconnected >> state or trigger scanning. > > Let me just say once again that all this discussion is entirely > orthogonal to properly supporting suspend/resume in mac80211, it's > always possible for userspace to do anything with the devices before > going into suspend, but the kernel should take some care to resume as it > was at suspend time, which is what we're aiming for here. Of course, > this may mean that at resume we lose the AP connection that we think we > still have right away, but that's great since then wpa_supplicant will > reconnect quickly. I second this by stressing another issue. in the point that suspend/resume events shell be present to user space regardless of mac80211 specific talk with wpa_supplicant. Not only Wifi but also in my knowledge BT and other coms need user space application to close gracefully connection before kernel shuts in down. Even sometime leavening shutting down interface managing application may reduce the crosstalk so that driver doesn't have go guess when application has finished it's shutdown. rtnl is probably not enough as there is still race who grabs it first. Thanks Tomas -- 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
