[bluez/bluez] 1a9634: adapter: Add btd_adapter_may_wake()

[Matthew Schwartz <noreply@github.com>]

  Branch: refs/heads/1134469
  Home:   https://github.com/bluez/bluez
  Commit: 1a96346c93b24fdc4c67a5dea420badbfd083736
      https://github.com/bluez/bluez/commit/1a96346c93b24fdc4c67a5dea420badbfd083736
  Author: Matthew Schwartz <matthew.schwartz@linux.dev>
  Date:   2026-07-25 (Sat, 25 Jul 2026)

  Changed paths:
    M src/adapter.c
    M src/adapter.h

  Log Message:
  -----------
  adapter: Add btd_adapter_may_wake()

The kernel provides no interface for querying whether a controller is
currently configured to wake the host from suspend. hci_register_dev()
marks HCI_CONN_FLAG_REMOTE_WAKEUP as supported whenever a driver
provides a wakeup callback, and btusb always does, so the supported
flags reported through mgmt say nothing about the runtime setting. The
value that matters, device_may_wakeup() on the underlying USB device,
is only evaluated during the suspend flow, and the wakeup callback is
not a pure query (btmtksdio's variant sends vendor HCI commands), so
mgmt could not simply re-evaluate it on Get Device Flags without new
kernel infrastructure.

Add btd_adapter_may_wake(), which reconstructs what btusb reports by
walking the adapter's sysfs ancestry to the closest USB device and
reading its power/wakeup attribute. A missing attribute means the
device cannot generate wake events at all, which is what btusb
arranges for the fake CSR clones by clearing the USB device's wakeup
capability. The attribute is read per call so that each query
reflects the current setting.

Only USB is handled. Controllers on other buses keep the current
behavior. btmtksdio exposes the same attribute on its SDIO function
device, but its wakeup callback can also depend on a vendor command.

Assisted-by: Claude:claude-fable-5


  Commit: 31789e8ae046cb4673634c42d5a65e8f1d29e2e1
      https://github.com/bluez/bluez/commit/31789e8ae046cb4673634c42d5a65e8f1d29e2e1
  Author: Matthew Schwartz <matthew.schwartz@linux.dev>
  Date:   2026-07-25 (Sat, 25 Jul 2026)

  Changed paths:
    M src/device.c

  Log Message:
  -----------
  device: Hide WakeAllowed when adapter cannot wake

dev_property_wake_allowed_exist() only checks whether the device has a
profile that supports wake configuration (HID/HoG), so WakeAllowed is
exposed on every input device even when the host controller cannot or
will not wake the system.

Gate the property on btd_adapter_may_wake() as well. The remote
wakeup device flag itself remains settable through mgmt and is still
stored. The kernel independently ignores it during suspend when the
controller may not wake the host, and the stored preference reapplies
once wakeup is enabled again. No PropertiesChanged signal is emitted
when the sysfs attribute changes, so clients observe the state that
is current at the time they query the property.

Assisted-by: Claude:claude-fable-5


  Commit: 68cf12fa3ae5a8a3eafacbaa3381a4b9834478c8
      https://github.com/bluez/bluez/commit/68cf12fa3ae5a8a3eafacbaa3381a4b9834478c8
  Author: Matthew Schwartz <matthew.schwartz@linux.dev>
  Date:   2026-07-25 (Sat, 25 Jul 2026)

  Changed paths:
    M doc/org.bluez.Device.rst

  Log Message:
  -----------
  doc: Mark WakeAllowed as optional

WakeAllowed is only present on devices with a profile that supports
wake configuration, and now only when the adapter itself is able to
wake the host. Mark it optional like the other conditional Device1
properties and document when it is present.


Compare: https://github.com/bluez/bluez/compare/1a96346c93b2%5E...68cf12fa3ae5

To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications