Bluetooth: Fix Advertisement Monitor Suspend/Resume
authorManish Mandlik <mmandlik@google.com>
Tue, 21 Sep 2021 21:47:10 +0000 (14:47 -0700)
committerMarcel Holtmann <marcel@holtmann.org>
Tue, 28 Sep 2021 08:01:35 +0000 (10:01 +0200)
commitce81843be24e9d5deb0db0784815efe84c9e3f22
tree664a4b98e7c91df0863e58f845a6eafdf402a308
parent6fc165337b0d06670b3b266fc217dd72b080c870
Bluetooth: Fix Advertisement Monitor Suspend/Resume

During system suspend, advertisement monitoring is disabled by setting
the HCI_VS_MSFT_LE_Set_Advertisement_Filter_Enable to False. This
disables the monitoring during suspend, however, if the controller is
monitoring a device, it sends HCI_VS_MSFT_LE_Monitor_Device_Event to
indicate that the monitoring has been stopped for that particular
device. This event may occur after suspend depending on the
low_threshold_timeout and peer device advertisement frequency, which
causes early wake up.

Right way to disable the monitoring for suspend is by removing all the
monitors before suspend and re-monitor after resume to ensure no events
are received during suspend. This patch fixes this suspend/resume issue.

Following tests are performed:
- Add monitors before suspend and make sure DeviceFound gets triggered
- Suspend the system and verify that all monitors are removed by kernel
  but not Released by bluetoothd
- Wake up and verify that all monitors are added again and DeviceFound
  gets triggered

Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Archie Pusaka <apusaka@google.com>
Reviewed-by: Miao-chen Chou <mcchou@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
net/bluetooth/hci_request.c
net/bluetooth/msft.c
net/bluetooth/msft.h