Hi Samuel,
> > > include/device.h | 9 ++++++++-
> > > plugins/iwmx.c | 3 ++-
> > > plugins/wifi.c | 5 +++--
> > > src/device.c | 6 +++---
> > > 4 files changed, 16 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/device.h b/include/device.h
> > > index a82d08d..1b54288 100644
> > > --- a/include/device.h
> > > +++ b/include/device.h
> > > @@ -47,6 +47,12 @@ enum connman_device_type {
> > > CONNMAN_DEVICE_TYPE_VENDOR = 10000,
> > > };
> > >
> > > +enum connman_device_scan_type {
> > > + CONNMAN_DEVICE_SCAN_TYPE_NORMAL = 0,
> > > + CONNMAN_DEVICE_SCAN_TYPE_FAST = 1,
> > > + CONNMAN_DEVICE_SCAN_TYPE_HIDDEN = 2,
> > > +};
> > > +
> >
> > since HIDDEN is not yet used, we might wanna leave that out for now. Or
> > what is your plan here?
> >
> > Another option instead of using scan(<type>) would be to implement a
> > fast_scan() callback. And only if the device type supports it, it will
> > be called. That allows the device driver a bit of flexibility. And the
> > core can nicely do a fallback.
> >
> > Samuel, any preference?
> The idea was to check if the driver can send several SSIDs (or even one) probe
> requests at once. If it does, we start doing a fast scan. Depending on the
> fast scan results, we may have to go through the regular scan code path. That
> is to say, if the fast scan results don't bring any of our favourite SSIDs
> back, then we fall back to a regular scan.
I realize on why we wanna do it. I would just go with the scan_fast()
callback here to clearly know with driver (and it will be only WiFi
anyway) does support such thing. Otherwise we keep calling FAST and
NORMAL all the time and let the driver figure out it. I really rather
have the driver clearly tell the core if it supports a faster scan
method in the first place.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
