[PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER

Nícolas F. R. A. Prado posted 1 patch 2 months, 1 week ago
There is a newer version of this series
drivers/hid/hid-quirks.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
Posted by Nícolas F. R. A. Prado 2 months, 1 week ago
The Logitech Bolt receiver once connected to a wireless device will
generate data on interface 2. If this data isn't polled, when the USB
port it is connected to gets suspended (and if that happens within 5
minutes of the last input from the wireless device), it will trigger a
remote wakeup 3 seconds later, which will result in a spurious system
wakeup if the port was suspended as part of system sleep.

Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
always polled and this spurious wakeup never happens.

With this change in place the system can be suspended with the receiver
plugged in and the system can be woken up when an input is sent from the
wireless device.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
Hi,

Given that the polling only needs to happen before the device goes into
suspend, I wonder if it might make sense to introduce a new quirk type
that only does a poll before the device goes into suspend (both for
system sleep and runtime suspend). It would reduce the extra bit of USB
traffic that ends up happening in this case with ALWAYS_POLL every time
a wireless device connects to the receiver.
---
 drivers/hid/hid-quirks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 02f7db5c1056..eb811b1fb80f 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -134,6 +134,7 @@ static const struct hid_device_id hid_quirks[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093), HID_QUIRK_ALWAYS_POLL },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS), HID_QUIRK_NOGET },

---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260407-logi-bolt-hid-quirk-always-poll-5d9c9238c924

Best regards,
-- 
Nícolas F. R. A. Prado <nfraprado@collabora.com>

Re: [PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
Posted by Jiri Kosina 2 months ago
On Tue, 7 Apr 2026, Nícolas F. R. A. Prado wrote:

> The Logitech Bolt receiver once connected to a wireless device will
> generate data on interface 2. If this data isn't polled, when the USB
> port it is connected to gets suspended (and if that happens within 5
> minutes of the last input from the wireless device), it will trigger a
> remote wakeup 3 seconds later, which will result in a spurious system
> wakeup if the port was suspended as part of system sleep.
> 
> Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
> always polled and this spurious wakeup never happens.
> 
> With this change in place the system can be suspended with the receiver
> plugged in and the system can be woken up when an input is sent from the
> wireless device.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
> Hi,
> 
> Given that the polling only needs to happen before the device goes into
> suspend, I wonder if it might make sense to introduce a new quirk type
> that only does a poll before the device goes into suspend (both for
> system sleep and runtime suspend). It would reduce the extra bit of USB
> traffic that ends up happening in this case with ALWAYS_POLL every time
> a wireless device connects to the receiver.

I don't think it's worth the hassle, but if you feel strongly about it, I 
wouldn't object too strongly.

In the meantime, I am applying this one. Thanks,

-- 
Jiri Kosina
SUSE Labs