[PATCH 03/11] wpa_s: use sched_scan in driver init

[Bondar, Alexander]

> Hi Alex,
> 
> On Wed, 2011-10-05 at 12:38 +0200, Bondar, Alexander wrote:
> > > diff --git a/wpa_supplicant/sme.c b/wpa_supplicant/sme.c index
> > > dbf385e..4cb5062 100644
> > > --- a/wpa_supplicant/sme.c
> > > +++ b/wpa_supplicant/sme.c
> > > @@ -237,6 +237,7 @@ void sme_authenticate(struct wpa_supplicant
> *wpa_s,
> > >  	}
> > >  #endif /* CONFIG_P2P */
> > >
> > > +	wpa_supplicant_cancel_sched_scan(wpa_s);
> > >  	wpa_supplicant_cancel_scan(wpa_s);
> >
> > Don't you need to wait for EVENT_SCHED_SCAN_STOPPED before
> proceeding
> > with authentication flow? There may be race condition when
> authentication request is set to the driver while sched_scan is still in
> progress.
> 
> I don't see a problem with that.  Nothing prevents the driver and the
> firmware from supporting authentication while a sched_scan is running (in
> theory).  If it cannot be done, the lower driver/hardware can always send a
> sched_scan stopped event before continuing with authentication (like the
> wl12xx driver does by checking the mac80211 idle flag).
> 
> And furthermore, here it's the same thing as with normal scan.  We don't
> want to keep scanning after we found what we want, so we call
> cancel_scan().  But we don't really care if the scan keeps running during
> authentication.

I see. Also from my discussion with Johannes I understood that we can assume canceling scheduled scan as synchronous flow.
When it returns we can consider scheduled scan is stopped.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.