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

Arik Nemtsov arik
Wed Apr 30 00:34:02 PDT 2014


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



More information about the Hostap mailing list