Hi Luiz,
>>>>> This introduces HCI_CONN_FLAG_DEVICE_PRIVACY which can be used by
>>>>> userspace to indicate to the controller to use Device Privacy Mode to a
>>>>> specific device.
>>>>>
>>>>> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
>>>>> ---
>>>>> include/net/bluetooth/hci_core.h | 1 +
>>>>> net/bluetooth/mgmt.c | 12 ++++++++++++
>>>>> 2 files changed, 13 insertions(+)
>>>>>
>>>>> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
>>>>> index fc93a1907c90..9c94d1c49b25 100644
>>>>> --- a/include/net/bluetooth/hci_core.h
>>>>> +++ b/include/net/bluetooth/hci_core.h
>>>>> @@ -153,6 +153,7 @@ struct bdaddr_list_with_irk {
>>>>>
>>>>> enum hci_conn_flags {
>>>>> HCI_CONN_FLAG_REMOTE_WAKEUP,
>>>>> + HCI_CONN_FLAG_DEVICE_PRIVACY,
>>>>
>>>> coming this now, I wonder if we better call them FLAG_REMOTE_WAKEUP_SUPPORT and FLAG_DEVICE_PRIVACY_SUPPORT. If I am not mistaken, then these are for indicating support for it.
>>>
>>> These flags are used in multiple places:
>>>
>>> hci_dev->conn_flags
>>> hci_conn_params->conn_flags
>>> bdaddr_list_with_flags->flags
>>>
>>> Which is one of the reason I made them all use DECLARE_BITMAP(flags,
>>> __HCI_CONN_NUM_FLAGS) so they are in sync, the use of them in
>>> hci_dev->conn_flags means they are supported but in the other 2 it
>>> means they are in use, so I prefer leave as they are.
>>
>> is my comment wrong? Don’t they always indicate the support for it?
>
> Support vs Use, anyway I always think about the shortest form for
> defines and having some term like SUPPORT sounds a little superfluous
> for me, but I'm fine adding it if you really think that is necessary
> in this case.
I already applied 1/4 and 2/4. So just re-spin them to make them apply to bluetooth-next.
Regards
Marcel
