On Sun, 2011-12-25 at 01:49 +0200, Eyal Shapira wrote: > On Sun, Dec 25, 2011 at 1:48 AM, Eyal Shapira <eyal@xxxxxxxxxx> wrote: > > On Fri, Dec 23, 2011 at 10:46 AM, Luciano Coelho <coelho@xxxxxx> wrote: > >> > >> Could the code be changed so that we delay the STOP_SCHED_SCAN command > >> completion instead? Then userspace can rely on that (as it should > >> anyway, because the command can fail) instead of having to wait for the > >> stopped event (which is a change in the API). > >> > > Sounds like this would be the best way to go and I'll do that. So no need > > for these patches. I misunderstood the STOP_SCHED_SCAN NL API to be async (due to the NL events) but it can and should be synchronous AFAIU. > > (and might sleep / block). Yep, this sounds better. > > The only mac80211 change I'd be glad to add is to make sched_scan_stop op return > > a value so errors can be reported back like it's being done in the sched_scan_stop cfg80211 op Returning errors from driver errors is not exactly the same things as we already do now. If sched_scan_stop in cfg80211 fails it is either because the userspace screwed up (and sent a stop when it was not running) or because someone else already stopped the scan. In both cases, it is okay, because the userspace can just ignore it and be sure the scan is stopped. Now, if the driver fails for some other reason and we return the error to the userspace, how should it react? In this case it would mean that the scan is still running, but should the userspace try again? Or ignore? Hard to know what to do. (This was Johannes's original opinion about returning errors there, IIRC). -- Cheers, Luca. -- 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
