From: Luciano Coelho <coelho@ti.com>
To: Eyal Shapira <eyal@wizery.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 0/2] report stop sched scan when actually done
Date: Sun, 25 Dec 2011 10:22:14 +0200 [thread overview]
Message-ID: <1324801334.2182.403.camel@cumari> (raw)
In-Reply-To: <CAF8O4-zLgwyUhfnZObooN=VLkkVb7QzTS+08VULJSGtGaZ3g8w@mail.gmail.com>
On Sun, 2011-12-25 at 01:49 +0200, Eyal Shapira wrote:
> On Sun, Dec 25, 2011 at 1:48 AM, Eyal Shapira <eyal@wizery.com> wrote:
> > On Fri, Dec 23, 2011 at 10:46 AM, Luciano Coelho <coelho@ti.com> 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.
next prev parent reply other threads:[~2011-12-25 8:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 10:11 [PATCH v2 0/2] report stop sched scan when actually done Eyal Shapira
2011-12-21 10:11 ` [PATCH v2 1/2] mac80211: mark stopped sched scan only after driver does Eyal Shapira
2011-12-21 10:11 ` [PATCH v2 2/2] nl80211: report " Eyal Shapira
2011-12-21 15:10 ` [PATCH v2 0/2] report stop sched scan when actually done Johannes Berg
2011-12-23 8:46 ` Luciano Coelho
[not found] ` <CAF8O4-wpjuV6j-beXn8d7bNA7jvSeCXMhV=kXDHNYKPgxQUbyw@mail.gmail.com>
2011-12-24 23:49 ` Eyal Shapira
2011-12-25 8:22 ` Luciano Coelho [this message]
2011-12-25 10:16 ` Eyal Shapira
2011-12-25 11:31 ` Luciano Coelho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1324801334.2182.403.camel@cumari \
--to=coelho@ti.com \
--cc=eyal@wizery.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox