When the BTUSB_WAKEUP_DISABLE flag is set, always return true for
prevent wake. This tells the suspend notifier not to prepare the
controller for reconnections during suspend.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
---
Realtek chipsets currently lose their firmware when suspending (except
in autosuspend where they assert remote_wakeup on the usb interface).
There's no need to configure the Bluetooth stack for wake-up in this
case so use the BTUSB_WAKEUP_DISABLE flag to also prevent wakeup from
being configured.
This was tested on Chromebooks with Realtek chipsets running both 4.14
and 5.4 kernel. It was tested with suspend functional tests and
a suspend stress test for 50 iterations.
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e42fdd625eb023..7627d79696b5aa 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3727,6 +3727,9 @@ static bool btusb_prevent_wake(struct hci_dev *hdev)
{
struct btusb_data *data = hci_get_drvdata(hdev);
+ if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+ return true;
+
return !device_may_wakeup(&data->udev->dev);
}
--
2.27.0.111.gc72c7da667-goog
Hi Abhishek,
> When the BTUSB_WAKEUP_DISABLE flag is set, always return true for
> prevent wake. This tells the suspend notifier not to prepare the
> controller for reconnections during suspend.
>
> Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
> ---
> Realtek chipsets currently lose their firmware when suspending (except
> in autosuspend where they assert remote_wakeup on the usb interface).
> There's no need to configure the Bluetooth stack for wake-up in this
> case so use the BTUSB_WAKEUP_DISABLE flag to also prevent wakeup from
> being configured.
>
> This was tested on Chromebooks with Realtek chipsets running both 4.14
> and 5.4 kernel. It was tested with suspend functional tests and
> a suspend stress test for 50 iterations.
>
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel