linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Alain Michaud <alainm@chromium.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	ChromeOS Bluetooth Upstreaming 
	<chromeos-bluetooth-upstreaming@chromium.org>
Subject: Re: [BlueZ PATCH v7 0/6] device: Allow devices to be marked as wake capable
Date: Tue, 7 Jul 2020 13:17:23 -0700	[thread overview]
Message-ID: <CANFp7mWMsWTYeTYs1wTCZgynfi_ELMnNEpFnp9v-gmVhSc1jFg@mail.gmail.com> (raw)
In-Reply-To: <CABBYNZLDBFxa4ojp5HK9YbPjm+fB=qznKzp95hHPA-dN8-UsQA@mail.gmail.com>

Thanks Luiz.

On Tue, Jul 7, 2020 at 10:50 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Abhishek,
>
> On Mon, Jul 6, 2020 at 1:25 PM Abhishek Pandit-Subedi
> <abhishekpandit@chromium.org> wrote:
> >
> >
> > Hi Luiz,
> >
> > This change accompanies a change in the kernel to allow marking devices
> > as wakeable so they can wake the system from suspend. Currently, only
> > HID devices support this and will be configured to allow this setting to
> > be changed via the WakeAllowed property.
> >
> > Accompanying kernel change: https://patchwork.kernel.org/patch/11609999/
> >
> > In order to set this flag, Bluez must call Set Device Flags with the
> > Remote Wakeup bit set. This change was tested with the accompanying
> > kernel changes on v5.4 with both manual tests and automated tests.
> >
> > Here's the tests that I ran manually:
> >   - Pair new HID device and confirm it has Wake Allowed to True
> >   (default). Verify device can be woken from suspend with device.
> >   - Restart bluetoothd, confirm Device Flags Changed event after Add
> >   Device has no Remote Wakeup flag and Set Device Flags is called
> >   afterwards to restore it. Verify wake from suspend still works.
> >   - Disable Wake allowed via dbus and confirm wake from suspend no
> >   longer works.
> >   - Restart bluetoothd and confirm Wake Allowed is still false. Verify
> >   wake from suspend does not work.
> >
> > Thanks
> > Abhishek
> >
> > Changes in v7:
> > * Fix more build issues reported by bluez.test.bot
> >
> > Changes in v6:
> > * Fix up some build issues reported by bluez.test.bot
> > * Save pending property id and emit success only after set flags returns
> > * Ignore multiple calls to set_wake_allowed to the same value
> > * Emit property error busy if same value is already sent to mgmt
> > * Fix up build issues reported by bluez.test.bot
> >
> > Changes in v5:
> > - Use device_flags mgmt op
> > * Decode device flags
> > * Refactor to use set_wake_flags and respond to device flags changed
> > * Add wake_override so we can keep track of user/profile configuration
> >   vs what is currently active
> > * Only call device_set_wake_support
> >
> > Changes in v4:
> > * Renamed wake_capable to wake_allowed
> > * Removed set_wake_capable mgmt op and updated add_device to accept
> >   flags to set whether a device is wakeable
> > * Refactored adapter_whitelist_add and adapter_auto_connect_add to call
> >   adapter_add_device
> > * Renamed WakeCapable to WakeAllowed
> > * Renamed WakeCapable to WakeAllowed
> > * Renamed device_set_profile_wake_support to just
> > device_set_wake_support
> >
> > Changes in v3:
> > * Added profile_wake_support and made wake_capable dependent on it
> > * Added documentation for WakeCapable
> > * Mark HID device to support wake from suspend
> >
> > Changes in v2:
> > * Added dbus api "WakeCapable" to set value
> > * Update device_set_wake_capable to be called by
> >   adapter_set_wake_capable_complete so we can emit property changed
> > * Newly added to show whether device is wake capable
> > * Removed automatically setting wake capable for HID devices
> >
> > Abhishek Pandit-Subedi (6):
> >   mgmt: Add mgmt op and events for device flags
> >   monitor: Decode device flags mgmt ops and event
> >   device: Support marking a device with wake allowed
> >   client: Display wake allowed property with info
> >   doc/device-api: Add WakeAllowed
> >   input: Make HID devices support wake
> >
> >  client/main.c           |   1 +
> >  doc/device-api.txt      |   5 +
> >  lib/mgmt.h              |  33 +++++++
> >  monitor/packet.c        |  70 ++++++++++++++
> >  profiles/input/device.c |   1 +
> >  profiles/input/hog.c    |   1 +
> >  src/adapter.c           |  93 ++++++++++++++++++
> >  src/adapter.h           |   3 +-
> >  src/device.c            | 210 ++++++++++++++++++++++++++++++++++++++++
> >  src/device.h            |  10 ++
> >  10 files changed, 426 insertions(+), 1 deletion(-)
> >
> > --
> > 2.27.0.212.ge8ba1cc988-goog
>
> Applied, thanks.
>
> --
> Luiz Augusto von Dentz

      reply	other threads:[~2020-07-07 20:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 20:25 [BlueZ PATCH v7 0/6] device: Allow devices to be marked as wake capable Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 1/6] mgmt: Add mgmt op and events for device flags Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 2/6] monitor: Decode device flags mgmt ops and event Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 3/6] device: Support marking a device with wake allowed Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 4/6] client: Display wake allowed property with info Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 5/6] doc/device-api: Add WakeAllowed Abhishek Pandit-Subedi
2020-07-06 20:25 ` [BlueZ PATCH v7 6/6] input: Make HID devices support wake Abhishek Pandit-Subedi
2020-07-07 17:50 ` [BlueZ PATCH v7 0/6] device: Allow devices to be marked as wake capable Luiz Augusto von Dentz
2020-07-07 20:17   ` Abhishek Pandit-Subedi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANFp7mWMsWTYeTYs1wTCZgynfi_ELMnNEpFnp9v-gmVhSc1jFg@mail.gmail.com \
    --to=abhishekpandit@chromium.org \
    --cc=alainm@chromium.org \
    --cc=chromeos-bluetooth-upstreaming@chromium.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).