Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
From:   Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date:   Thu, 7 Nov 2019 18:04:14 -0800
Message-ID: <CANFp7mVOh5KPYPPnbGO_YnV-mBGTV3gYgWcPNSMq+=aBzBM00Q@mail.gmail.com>
Subject: RFC: Managing devices around system suspend in bluez
To:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Yoni Shavit <yshavit@chromium.org>, alainmichaud@google.com
Cc:     linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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
design: https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/docs/suspend_resume.md)

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?

Thanks
Abhishek

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.