On Wed, 2010-09-01 at 14:58 -0400, John W. Linville wrote: > On Wed, Sep 01, 2010 at 12:29:38PM +0200, Johannes Berg wrote: > > On Tue, 2010-08-31 at 15:25 -0400, John W. Linville wrote: > > > This function exists to clean-up after a hardware error or something > > > similar. The restart is accomplished using the same infrastructure used > > > to resume after a suspend. The suspend path cancels running scans, so > > > it seems appropriate to do that here as well for software-based scans. > > > If a hardware-based scan is pending, issue a warning message since this > > > indicates that the drivers has failed to clean-up after itself. > > > > Makes sense. > > > > I guess unrelated to this, I wonder if we should warn in the suspend > > case as well, rather than doing it unconditionally. Hmm. > > Maybe so, but I'm not sure what path we would hook for that. > Doesn't wiphy_suspend run before the hardware bus suspend functions? > How would the driver now in advance to cancel the hardware scan? Good point! I was just thinking that if we do a mac80211 cancel only, then the scan request struct pointer that we gave to the driver earlier suddenly becomes invalid. 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
