From: Abhishek Pandit-Subedi <firstname.lastname@example.org> To: Marcel Holtmann <email@example.com>, Johan Hedberg <firstname.lastname@example.org>, Yoni Shavit <email@example.com>, firstname.lastname@example.org Cc: email@example.com Subject: RFC: Managing devices around system suspend in bluez Date: Thu, 7 Nov 2019 18:04:14 -0800 Message-ID: <CANFp7mVOh5KPYPPnbGO_YnV-mBGTV3gYgWcPNSMq+=aBzBM00Q@mail.gmail.com> (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 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.
next 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: 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='CANFp7mVOh5KPYPPnbGO_YnV-mBGTV3gYgWcPNSMq+=aBzBM00Q@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
Linux-Bluetooth Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-bluetooth/0 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/ https://lore.kernel.org/linux-bluetooth \ firstname.lastname@example.org public-inbox-index linux-bluetooth Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth AGPL code for this site: git clone https://public-inbox.org/public-inbox.git