[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200624112428.1.Ib42ab202cfd82e7734571c302071da30a24ea27b@changeid>
Date: Wed, 24 Jun 2020 11:24:30 -0700
From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To: marcel@...tmann.org, linux-bluetooth@...r.kernel.org
Cc: chromeos-bluetooth-upstreaming@...omium.org,
Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
Johan Hedberg <johan.hedberg@...il.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH] Bluetooth: btusb: BTUSB_WAKEUP_DISABLE prevents wake
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 <abhishekpandit@...omium.org>
---
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
Powered by blists - more mailing lists