Hi Marcel,
On Wed, Jun 29, 2011 at 08:36:57AM -0700, Marcel Holtmann wrote:
> 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.
Yes, the driver scan_fast() callback sounds like a good idea to me.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
