Re: [BlueZ PATCH v3 1/5] mgmt: Add docs for Set Wake Capable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 29, 2020 at 10:06 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>
> Hi Abhishek,
>
> >>> Add docs for new management operation to mark a device as wake capable.
> >>>
> >>> ---
> >>>
> >>> Changes in v3: None
> >>> Changes in v2:
> >>> * Separated docs/mgmt-api.txt into its own patch
> >>>
> >>> doc/mgmt-api.txt | 19 +++++++++++++++++++
> >>> 1 file changed, 19 insertions(+)
> >>>
> >>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> >>> index 1e59acc54..8a73a9bb9 100644
> >>> --- a/doc/mgmt-api.txt
> >>> +++ b/doc/mgmt-api.txt
> >>> @@ -3047,6 +3047,25 @@ Load Blocked Keys Command
> >>>      Possible errors:        Invalid Parameters
> >>>                              Invalid Index
> >>>
> >>> +Set Wake Capable Command
> >>> +===========================
> >>> +
> >>> +     Command Code:           0x0047
> >>> +     Controller Index:       <controller id>
> >>> +     Command Parameters:     Address (6 Octets)
> >>> +                             Address_Type (1 Octet)
> >>> +                             Wake Capable (1 Octet)
> >>> +     Return Parameters:      Address (6 Octets)
> >>> +                             Address_Type (1 Octet)
> >>> +                             Wake Capable (1 Octet)
> >>> +
> >>> +     This command sets whether a bluetooth device is capable of waking the
> >>> +     system from suspend. This property is used to set the event filter and
> >>> +     LE whitelist when the system enters suspend.
> >>> +
> >>> +     Possible errors:        Failed
> >>> +                             Invalid Parameters
> >>> +                             Invalid Index
> >>>
> >>
> >> my current thinking goes into this API addition:
> >>
> >> --- a/doc/mgmt-api.txt
> >> +++ b/doc/mgmt-api.txt
> >> @@ -2003,6 +2003,7 @@ Add Device Command
> >>                0       Background scan for device
> >>                1       Allow incoming connection
> >>                2       Auto-connect remote device
> >> +               3       Allow incoming connection to wake up the system
> >>
> >>        With the Action 0, when the device is found, a new Device Found
> >>        event will be sent indicating this device is available. This
> >> @@ -2018,6 +2019,9 @@ Add Device Command
> >>        and if successful a Device Connected event will be sent. This
> >>        action is only valid for LE Public and LE Random address types.
> >>
> >> +       With the Action 3, the device is allowed to connect the same way
> >> +       as with Action 1, but allows to wake up the system from suspend.
> >> +
> >>        When a device is blocked using Block Device command, then it is
> >>        valid to add the device here, but all actions will be ignored
> >>        until the device is unblocked.
> >>
> >> Since we are really talking about incoming connections, then the Add Device command is the one that handles this. Giving a device the option to wake us up that is not set up for incoming connections makes no sense. We can discuss if certain LE advertising packets should wake us up, but that is a total different API in my book.
> >
> > I originally tried implementing this with the Add Device api as you
> > suggested in the RFC email back in November (when we first talked
> > about this). I had trouble figuring out when/where in bluez to
> > actually send the Add Device command.
> >
> > Whether a device supports wake-up is a profile level setting (i.e. HID
> > only so far). As far as I can tell, Add Device is called before the
> > profile connection is established. Bluez has two apis that call
> > MGMT_OP_ADD_DEVICE:
> > * adapter_auto_connect_add (this seems to be LE)
> > * adapter_whitelist_add (this seems to be BR/EDR)
> >
> > Both seem to be called BEFORE the registered profiles have a chance to
> > accept the connection.
>
> this is something for Luiz or Johan to comment on. Maybe our code is not as good as I was thinking in this regard. Or maybe this is actually legacy code that I am trying to rid of by requiring a mgmt API revision that has Add Device support.
>
> In general once we bonded with a device, we should be able to assign certain properties to it that are kept persistently.
>

It looks like add_device would work if I opted to use it as an
"update_device_params" type of function (I think I can use it in the
same location I currently use adapter_set_wake_capable; I would just
check that the device has already been added first).

You would still need to make a separate call from the original
add_device so your original criticism of requiring another mgmt call
for every param being set is still there. I could refactor the action
parameter to accept flags (i.e. 0x3 = Set connection parameters) and
then add a uint16_t flags parameter (i.e. 1 << 0: Allow wakeup from
incoming connection).

What do you think?

> Regards
>
> Marcel
>




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux