> -----Original Message----- > From: Christian Kellner <ckellner@xxxxxxxxxx> > Sent: Monday, July 29, 2019 9:33 AM > To: linux-bluetooth@xxxxxxxxxxxxxxx > Cc: Limonciello, Mario > Subject: BT advertising packets and s2idle issue > > > [EXTERNAL EMAIL] > > > Hi all, > > I have been wondering what to do about the bug that advertising packet > will wake systems from s2idle when a device was previously paired with > the HCI_AUTO_CONN_ALWAYS flag (kernel bug #200039[1]). I was thinking of > creating a patch for bluez that would create a "delay lock"[2] and > de-register any such device from the kernel before entering s2idle, but > I wanted to check first if that is the best approach. > In comment #27 it is suggested that using a "LE Privacy v1.2" feature > could fix the issue as well. Is there some more information about this > available somewhere? II can help out with development and testing as I > have an affected system myself. > > Cheers, > CK > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=200039 > [2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/ > > -- > Dr. Christian J. Kellner > Desktop Hardware Enablement > Red Hat If I'm not mistaken, even unpaired LE devices can cause the wakeup. Any device with an advertisement report will cause the wakeup. So de-registering all devices from kernel before entering s2idle wouldn't solve the problem. My opinion is there should be a dedicated kernel freeze handler that does the following: 1) If LE Privacy 1.2 "in use", handle regular suspend/resume flow 2) If LE Privacy 1.1in use, power off the radio in freeze, power back on in resume. For now, since LE privacy 1.2 not yet enabled, this would at least help with this situation as reported. Of course this will mean BT devices can't wake the system anymore if s2i, so maybe the behavior should be put behind a module parameter or sysfs file. BLE devices are so prevalent though; I find it a hard time imagining anyone wants it the way it exists today.
