Hi Andre,
> >> This patch adds support for LE-Only discovery procedure through
> >> management interface.
> >>
> >> A new flag (HCI_LE_SCAN) was created to inform if the controller is
> >> performing LE scan. The HCI_LE_SCAN flag is set/cleared when the
> >> controller starts/stops scanning.
> >>
> >> Signed-off-by: Andre Guedes <andre.guedes@xxxxxxxxxxxxx>
> >> ---
> >> include/net/bluetooth/hci.h | 2 ++
> >> net/bluetooth/hci_event.c | 39 +++++++++++++++++++++++++++++++++
> >> +++---
> >> net/bluetooth/mgmt.c | 5 +++++
> >> 3 files changed, 43 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/
> >> hci.h
> >> index fb40388..c4fdeeb 100644
> >> --- a/include/net/bluetooth/hci.h
> >> +++ b/include/net/bluetooth/hci.h
> >> @@ -86,6 +86,8 @@ enum {
> >> HCI_DEBUG_KEYS,
> >>
> >> HCI_RESET,
> >> +
> >> + HCI_LE_SCAN,
> >> };
> >
> > I am really against adding any new flags here. This is a public API
> > and
> > a horrible one actually.
> >
> > We need to have these states internal and stop adding more flags to
> > this
> > public API.
>
> The HCI_LE_SCAN flag is really device/controller related as well as
> HCI_INQURY flag is. They both have similar meaning and using. Besides,
> the userspace (hciconfig) might be interested in checking this flag to
> know if the controller is carrying out the LE scan (just like it does
> with HCI_INQUIRY flag).
>
> So, may you consider we keep this flag here?
we can keep it for a little bit, but long term, these need to go away.
Especially since they are not available via the mgmt API (and that is
good this way).
Btw. it is not about telling the userspace that we currently run a
discovery procedure, it is more about how the flags are defined and how
bad off an ABI that is.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
