On Sun, Dec 25, 2011 at 10:22 AM, Luciano Coelho <coelho@xxxxxx> wrote: > 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). > I was referring to sched_scan_stop op in cfg80211_ops which can return an int. This is used by ath6kl for example in ath6kl_cfg80211_sscan_stop() to return -EIO in case there's an error in stopping so userspace might get that. What's the difference between this and having our driver return an error ? Since there might be real errors which would prevent us from stopping , isn't it better to report to userspace (and let it decide what to do - retry, ignore, exit program, panic ,....) other than just silently ignore it and let the userspace think that it succeeded ? > -- > 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
