Hi Abhishek.
> When the system is suspended, only some connected Bluetooth devices
> cause user input that should wake the system (mostly HID devices). Add
> a list to keep track of devices that can wake the system and add
> a management API to let userspace tell the kernel whether a device is
> wake capable or not.
>
> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx>
> ---
>
> Changes in v2: None
>
> include/net/bluetooth/hci_core.h | 1 +
> include/net/bluetooth/mgmt.h | 7 ++++++
> net/bluetooth/hci_core.c | 1 +
> net/bluetooth/mgmt.c | 40 ++++++++++++++++++++++++++++++++
> 4 files changed, 49 insertions(+)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 89ecf0a80aa1..ce4bebcb0265 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -394,6 +394,7 @@ struct hci_dev {
> struct list_head mgmt_pending;
> struct list_head blacklist;
> struct list_head whitelist;
> + struct list_head wakeable;
I have the feeling that using a separate list is making this more complicated for us than it needs to be. I think in parts this comes through the fact that BR/EDR devices are handled via the whitelist list and for LE devices we are using the conn params “framework”.
So maybe it is actually better to store in wakeable list just the BR/EDR devices. And ensure that wakeable is a subset of the whitelist list. And for LE we store it in the conn params lists.
At some point, I think we need to merge whitelist and wakeable list for BR/EDR into a proper structure that can hold this information and maybe also revamp the inquiry cache we are using.
I will comment on the rest when I go through the LE whitelist update patch (and yes, I realize or variable whitelist for BR/EDR is confusing).
Regards
Marcel
