[PATCH] scan: defer scans while PNO is in progress

[Arik Nemtsov]

On Tue, Apr 29, 2014 at 6:16 PM, Jouni Malinen <j at w1.fi> wrote:
>
> On Thu, Apr 24, 2014 at 08:45:35AM +0300, Ilan Peer wrote:
> > Skipping the scan altogether will hurt auto-reconnect. Also move the PNO
> > check down - the scan might be canceled for other reasons before we
> > defer it.
>
> > diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c
> > @@ -559,11 +559,6 @@ static void wpa_supplicant_scan(void *eloop_ctx, void *timeout_ctx)
> > -     if (wpa_s->pno || wpa_s->pno_sched_pending) {
> > -             wpa_dbg(wpa_s, MSG_DEBUG, "Skip scan - PNO is in progress");
> > -             return;
> > -     }
> > -
>
> > @@ -613,6 +608,17 @@ static void wpa_supplicant_scan(void *eloop_ctx, void *timeout_ctx)
> > +     /*
> > +      * Don't cancel the scan, defer it. Some scans are used for changing
> > +      * modes inside the supplicant (roaming, auto-reconnect, etc).
> > +      * Discarding the scan might hurt these processes.
> > +      */
> > +     if (wpa_s->pno || wpa_s->pno_sched_pending) {
> > +             wpa_dbg(wpa_s, MSG_DEBUG, "Defer scan - PNO is in progress");
> > +             wpa_supplicant_req_scan(wpa_s, 0, 100000);
> > +             return;
> > +     }
>
> Hmm.. Would this result in continuous stream of 100 ms timeouts while
> PNO is running? I'd assume the host processor goes to sleep in most such
> cases, but if there are any cases where it doesn't, this does not look
> desired. Wouldn't it be cleaner to track the request to run a scan and
> execute that once PNO is stopped?

I thought it would be cleaner to just defer the scan and not add
additional state variables to the already-complicated state.

Also the potential side-effect of taking a little CPU every 100ms
doesn't seem too bad?
And again this is really theoretical, since we'll be suspended shortly
after PNO is set.

Arik