Linux-Bluetooth Archive on
 help / color / Atom feed
From: Abhishek Pandit-Subedi <>
To: Marcel Holtmann <>,
	Johan Hedberg <>,
	Yoni Shavit <>,
Subject: RFC: Managing devices around system suspend in bluez
Date: Thu, 7 Nov 2019 18:04:14 -0800
Message-ID: <> (raw)

On ChromeOS, we are currently trying to design how bluez should behave
during system suspend. This is motivated by the fact that bluetooth
can be a noisy source of wakeups on a system and historically has been
noisy on ChromeOS.

Here are some problems we've seen:
- If the system suspends while discovery is active, advertisements
will continue arriving on the host and will wake the system
- Pairing a LE keyboard/mouse and disconnecting it (via link loss)
results in a passive scan of all advertisements (and these will wake
the host)

To resolve this, we propose adding a SuspendImminent and SuspendDone
dbus api to inform bluez that suspend is about to occur and the system
has resumed.
(These names are based off the ChromeOS Power Manager's existing

In the suspend imminent handler, we would do the following in order:
* Pause any discovery
* Set an event filter for all paired devices capable of waking the
system (anything that creates uhid or uinput virtual devices)
* Disconnect all connected devices (with a soft disconnect)
* Enable background scan with whitelist of devices that should be able
to wake the system (** see below for comments about IRK resolution)

In the suspend done handler, we would do the following in order:
* Clear the event filter
* Enable background scan with non-suspend logic (** see below for
comments about IRK resolution)
* Unpause discovery (if it was running before suspend)

We expect this will result in the following:
* Classic: A paired device can wake the host if it's in the event filter
* LE: A paired device can wake the host if it's in the whitelist and
it sends an advertisement (undirected if in the whitelist, directed if
targeting our host; i.e. filter_policy = 0x1 or 0x3)

Do you think the actions taken in the suspend handlers are sufficient?
Any concerns or things to look out for?


IRK Resolution:
With this design, we have some problems with IRK resolution on BT
version < 4.2. Devices supporting BT Privacy 1.2 may start using
resolvable private addresses for both initiator and destination.
Without address resolution in the controller, we have to set the
filter policy to 0 (allow all) so that we can do address resolution on
the host.
Implementing these privacy features are outside the scope of this RFC
so we will disallow wake up from suspend for these devices (set filter
policy to accept only whitelist and directed). Once bluez supports
Privacy 1.2, wakeup from these devices will work on controllers with
BT version >= 4.2.

             reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  2:04 Abhishek Pandit-Subedi [this message]
2019-11-09  2:24 ` Marcel Holtmann
2019-11-12  1:16   ` Abhishek Pandit-Subedi
2019-11-12  8:14     ` Marcel Holtmann

Reply instructions:

You may reply publically 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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ \
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone