Hi Szymon,
On Thu, Dec 04, 2014, Szymon Janc wrote:
> On Thursday 04 of December 2014 11:38:35 Marcel Holtmann wrote:
> > Hi Szymon,
> >
> > >>>>> The Bluetooth core specification defines the value 127 as invalid for
> > >>>>> RSSI values. So instead of hard coding it, lets add a constant for it.
> > >>>>>
> > >>>>> Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
> > >>>>> ---
> > >>>>> include/net/bluetooth/hci.h | 1 +
> > >>>>> 1 file changed, 1 insertion(+)
> > >>>>>
> > >>>>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> > >>>>> index 569c077778b6..b6f7be1eb919 100644
> > >>>>> --- a/include/net/bluetooth/hci.h
> > >>>>> +++ b/include/net/bluetooth/hci.h
> > >>>>> @@ -412,6 +412,7 @@ enum {
> > >>>>>
> > >>>>> /* The core spec defines 127 as the "not available" value */
> > >>>>> #define HCI_TX_POWER_INVALID 127
> > >>>>> +#define HCI_RSSI_INVALID 127
> > >>>>
> > >>>> Isn't that value depending on command, event, link and controller type?
> > >>>
> > >>> we use it for the mgmt side of things and there it is whatever we want it to be.
> > >>
> > >> At least for inquiry result (no RSSI) 0 is passed to mgmt_device_found() and that seems
> > >> to be used by userspace as RSSI unavailable.
> > >
> > > Which is strange btw, since both for LE and BR/EDR this is legal RSSI value...
> >
> > I checked for LE. There is clearly says 127 means RSSI not available.
>
> I meant that 0 RSSI is legal for both LE and BR/EDR but it is used in mgmt device
> found event as 'RSSI not available'.
On adapters that generate such events you will never see any other type
of discovery results (because the HW isn't capable of it), so what the
value is doesn't really matter if all the events have the same one. For
consistency however we could change this from 0 to 127.
Johan
--
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
