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.
