public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
	"Jiri Kosina" <jkosina@suse.com>,
	"Sasha Levin" <sashal@kernel.org>,
	jikos@kernel.org, bentiss@kernel.org,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 7.0-5.15] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
Date: Mon, 20 Apr 2026 09:19:57 -0400	[thread overview]
Message-ID: <20260420132314.1023554-203-sashal@kernel.org> (raw)
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>

From: Nícolas F. R. A. Prado <nfraprado@collabora.com>

[ Upstream commit d4229fc0cb50c52b385538d072c5fc8827b287a9 ]

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>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the analysis.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line Parse**
- Subsystem prefix: `HID: quirks:`
- Action verb: "Set" (adds a quirk entry - this is effectively fixing
  broken hardware behavior)
- Record: HID subsystem; adding `HID_QUIRK_ALWAYS_POLL` for the Logitech
  Bolt Receiver.

**Step 1.2: All Tags**
- `Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>`
  (author)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` (HID subsystem
  maintainer)
- No Fixes:, no Cc: stable, no Reported-by:, no Link: (expected — that's
  why it needs review)
- Record: Applied by HID maintainer directly; concise author-maintainer
  chain.

**Step 1.3: Body Analysis**
- Bug mechanism: Once a wireless device connects to the Bolt receiver,
  interface 2 generates data. If not polled and the USB port is
  suspended within 5 min of last wireless input, the device triggers a
  remote wakeup 3 seconds later, causing a spurious system wakeup when
  suspended as part of system sleep.
- Symptom: **System spontaneously wakes from suspend** when Bolt
  receiver is attached.
- Author confirms testing: "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."
- Record: Real, observed, user-visible issue (spurious wake-from-
  suspend); root cause clearly identified (device emits data on
  interface 2 that triggers remote wakeup).

**Step 1.4: Hidden Bug Fix Detection**
- "Set ALWAYS_POLL" — this is a hardware workaround/quirk. Functionally,
  it is a **bug fix** for buggy hardware behavior that breaks system
  suspend for affected users.
- Record: This is a classic hardware quirk bug fix.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files: `drivers/hid/hid-quirks.c` only, +1/-0 lines.
- Functions: none — adds a single table entry to `hid_quirks[]`.
- Classification: trivial, single-file, surgical quirk table entry.

**Step 2.2: Code Flow**
- Before: device matched only by default HID logic → `usbhid_open()` and
  related code treated it like any normal device (autosuspend-enabled,
  sets `needs_remote_wakeup = 1`).
- After: the quirk flag makes `usbhid/hid-core.c` paths at lines 689,
  752, 756, 1185, 1234 bypass autosuspend/remote wakeup logic —
  `needs_remote_wakeup` stays 0 and interface 2 is always polled.
- Record: exactly the change documented in commit message.

**Step 2.3: Bug Mechanism**
- Category: (h) Hardware workaround / quirk table entry for buggy device
  behavior.
- Mechanism: `HID_QUIRK_ALWAYS_POLL` is an established mechanism used by
  many Logitech, Lenovo, Microsoft, Chicony mice/dongles for exactly
  this kind of problem (preventing spurious wakeups / keeping endpoint
  pollable). The Bolt receiver exhibits the same pattern.

**Step 2.4: Fix Quality**
- Obviously correct: trivial one-line addition to an existing quirk
  table.
- Minimal and surgical: yes.
- Regression risk: essentially zero — the quirk only affects devices
  matching vendor=0x046d, product=0xc548. All other devices are
  untouched.
- Risk introduced by the fix itself: slight extra USB traffic for Bolt
  receiver users (acknowledged by author). This is well within
  acceptable for the quirk behavior that's applied to many devices
  already.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` define added in commit
  `526748b925185` ("HID: multitouch: Add quirk for Logitech Bolt
  receiver w/ Casa touchpad") — first shipped in **v6.12**.
- Record: buggy hardware behavior exists since device was first
  supported; device ID is present in stable 6.12.y and later.

**Step 3.2: Fixes Tag**
- No Fixes: tag (device behavior is a hardware issue, not a regression
  from a specific commit). Not applicable.

**Step 3.3: File History**
- `drivers/hid/hid-quirks.c` receives quirk additions routinely (VRS
  steering wheel, Cooler Master MM712, Apple keyboards,
  Lenovo/Edifier/etc.). This is the normal pattern.
- Record: no prerequisite patches; standalone one-line addition.

**Step 3.4: Author**
- Author is a Collabora Mediatek/Genio/thermal/kernel developer (regular
  upstream contributor). Applied by HID maintainer Jiri Kosina directly.
- Record: normal maintainer acceptance path.

**Step 3.5: Dependencies**
- Uses `USB_VENDOR_ID_LOGITECH` (long-existing) and
  `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` (added in v6.12). No other
  dependencies.
- Record: applies cleanly to any stable tree ≥ 6.12. Older trees (6.6,
  6.1, 5.15, 5.10, 5.4) do not have the device ID define; backport would
  need the `hid-ids.h` define too — likely not worth doing given the
  device ID was added in 6.12.

## PHASE 4: MAILING LIST

**Step 4.1: Original thread**
- `b4 dig -c d4229fc0cb50c` → https://lore.kernel.org/all/20260407-logi-
  bolt-hid-quirk-always-poll-v1-1-4dae0fda344e@collabora.com/
- Single revision (v1). Applied as submitted.

**Step 4.2: Reviewers**
- Thread saved to mbox. Jiri Kosina (HID maintainer, `jikos@kernel.org`)
  replied: "In the meantime, I am applying this one. Thanks,"
- Author proposed possible future improvement (a "poll-before-suspend
  only" quirk) but Jiri didn't object to the current approach.
- Recipients: Jiri Kosina, Benjamin Tissoires, linux-
  input@vger.kernel.org, linux-kernel@vger.kernel.org,
  kernel@collabora.com.
- Record: patch reviewed and applied by the subsystem maintainer with no
  objections; no stable nomination request was made but also no concerns
  raised.

**Step 4.3: Bug Report**
- No Link: tag, but commit message and author's reply indicate this is a
  directly-observed reproducible issue.

**Step 4.4: Series context**
- `b4 dig -a`: only v1 exists. Standalone single patch.

**Step 4.5: Stable discussion**
- None found in thread.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
- None. Adds one table entry to `hid_quirks[]` consumed by
  `usbhid_exists_squirk()` / `hid_lookup_quirk()`.

**Step 5.2: Callers of quirk**
- `drivers/hid/usbhid/hid-core.c`: lines 689, 752, 756, 1185, 1234 all
  check `HID_QUIRK_ALWAYS_POLL` and branch accordingly in `usbhid_open`,
  `usbhid_close`, `usbhid_start`, `usbhid_stop` (standard HID USB device
  lifecycle).
- Record: well-established, widely-used quirk path.

**Step 5.3: Callees**
- N/A — this is a data table entry.

**Step 5.4: Reachability**
- Reached for any system with the Bolt receiver plugged in during device
  enumeration — every affected user.

**Step 5.5: Similar patterns**
- Many similar quirk additions in same file (Apple keyboard
  c55092187d9ad, Dell KM5221W 62cc9c3cb3ec1, VRS R295 1141ed52348d3,
  Cooler Master MM712 0be4253bf878d, Lenovo PixArt mice, etc.). This is
  a recurring, well-accepted pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code exists in stable?**
- The device ID `USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER = 0xc548` is in
  stable 6.12.y and later (added by commit 526748b925185 before v6.12).
- The `hid_quirks[]` table exists in all stable trees.
- Record: backport applicable to 6.12.y, 6.13.y, 6.14.y, 6.15.y (current
  active trees that carry the define). Not applicable to older LTS
  (6.6.y, 6.1.y, 5.15.y, 5.10.y) unless the device ID define is
  backported along.

**Step 6.2: Backport complications**
- Mainline hunk context includes neighboring entries added later (8BitDo
  Pro 3, Edifier QR30). Fuzz/minor context adjustment likely sufficient;
  any stable tree with the `LOGITECH_BOLT_RECEIVER` define will accept
  this addition trivially — the surrounding entries have been stable for
  years.
- Record: clean apply with possibly trivial fuzz on older-than-mainline
  stable.

**Step 6.3: Related fixes in stable?**
- None found.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- `drivers/hid/` — device drivers (HID, USB input).
- Criticality: IMPORTANT — keyboards, mice, and wireless receivers are
  common desktop/laptop hardware. Suspend/resume breakage affects user-
  visible laptop power management.

**Step 7.2: Activity**
- Very active file; routine quirk additions merged frequently.

## PHASE 8: IMPACT AND RISK

**Step 8.1: Affected users**
- Owners of Logitech Bolt receivers (a fairly popular wireless receiver
  used with Logitech MX-family peripherals and modern wireless
  keyboards/mice) who suspend their systems.

**Step 8.2: Trigger**
- Occurs every system suspend within 5 minutes of wireless input
  activity. Very easy to trigger on any laptop using this receiver.

**Step 8.3: Severity**
- Failure mode: **spurious wake-from-suspend** → battery drain, system
  not actually suspending, potential data/security exposure on machines
  users thought were asleep. Severity: **MEDIUM-HIGH** (not a crash, but
  a serious user-visible regression of the suspend feature; affects
  laptop battery life and sleep reliability).

**Step 8.4: Risk-benefit**
- Benefit: clear, reproducible user-facing fix for laptop suspend/resume
  with a common wireless receiver.
- Risk: one-line table entry for a specific (vendor,product) tuple;
  cannot affect other devices. Extra URB polling for the one device —
  the same trade-off accepted for dozens of similar quirks. Very low
  risk.
- Record: benefit >> risk.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
- FOR: one-line surgical quirk; applied by HID maintainer; established
  pattern (dozens of similar entries); fixes real user-visible suspend
  misbehavior; author tested both suspend and wakeup paths.
- AGAINST: none material. Adds a tiny bit of USB traffic for the one
  device (acknowledged).
- Unresolved: backport to pre-6.12 trees would additionally need the
  `hid-ids.h` define from commit 526748b925185 — but active stable trees
  (6.12.y+) already contain it.

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — matches existing pattern, maintainer-
   applied.
2. Fixes real bug affecting users? **YES** — spurious wake from suspend.
3. Important issue? **YES** — suspend/resume reliability on common
   hardware.
4. Small and contained? **YES** — 1 line, 1 file.
5. No new features/APIs? **YES** — quirk entry only.
6. Applies to stable? **YES** — for trees containing the device ID
   define (v6.12+).

**Step 9.3: Exception Category**
- Fits the explicit "QUIRKS and WORKAROUNDS" exception and "NEW DEVICE
  IDs / device-specific quirks to existing drivers" exception in stable
  rules.

**Step 9.4: Decision**
- This is a textbook stable candidate: a minimal, targeted hardware
  quirk that fixes a reproducible suspend issue for a common piece of
  hardware, applied by the subsystem maintainer, matching dozens of
  prior similar backported quirks.

## Verification

- [Phase 1] Parsed commit message: confirmed no
  Fixes/Cc:stable/Link/Reported-by; two Signed-off-bys (author + HID
  maintainer Jiri Kosina).
- [Phase 2] Diff inspection: verified the change is exactly `+1` line in
  `drivers/hid/hid-quirks.c` adding a `HID_QUIRK_ALWAYS_POLL` entry for
  `USB_VENDOR_ID_LOGITECH`/`USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER`.
- [Phase 2] Confirmed quirk semantics via `drivers/hid/usbhid/hid-
  core.c` lines 689, 752, 756, 1185, 1234 — flag bypasses
  autosuspend/remote-wakeup paths.
- [Phase 2] Verified `HID_QUIRK_ALWAYS_POLL = BIT(10)` in
  `include/linux/hid.h:406`.
- [Phase 3] `git log` on `drivers/hid/hid-quirks.c` + `rg
  USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER` → identified define introduced
  in commit `526748b925185`.
- [Phase 3] `git tag --contains 526748b925185` → device ID first shipped
  in v6.12.
- [Phase 3] `git log --oneline --grep="ALWAYS_POLL"` → verified many
  similar one-line quirk additions historically.
- [Phase 4] `b4 dig -c d4229fc0cb50c` → found original thread at
  lore.kernel.org/all/20260407-logi-bolt-hid-quirk-always-
  poll-v1-1-4dae0fda344e@collabora.com/.
- [Phase 4] `b4 dig -a` → single v1, applied as-is.
- [Phase 4] `b4 dig -m /tmp/bolt-thread.mbx` → read full thread: Jiri
  Kosina (HID maintainer) applied the patch; author confirmed testing;
  no NAKs.
- [Phase 5] Confirmed `hid_quirks[]` entries are consumed by the
  standard USB HID core paths — impact scope is exactly the one matched
  device.
- [Phase 6] Device ID present in mainline and 6.12.y+ stable branches.
- [Phase 7] `drivers/hid/` is IMPORTANT subsystem — affects HID input on
  desktops/laptops.
- [Phase 8] Failure mode: spurious system wake from suspend, confirmed
  by commit message text.
- UNVERIFIED: I did not check every LTS stable tree file-by-file for
  divergent context around the insertion point, but given this is a
  sorted alphabetical table and the neighboring Logitech entries
  (`LOGITECH_C007`, `LOGITECH_C077`, `LOGITECH_KEYBOARD_G710_PLUS`) have
  been present for many years, a clean backport is essentially
  guaranteed for 6.12+ trees.

Single-line hardware quirk entry that fixes a real, reproducible
suspend/wakeup bug affecting owners of the Logitech Bolt receiver.
Matches the "quirks and workarounds" stable exception exactly, is
maintainer-applied, carries negligible regression risk, and applies
cleanly to stable trees that carry the device ID (v6.12+).

**YES**

 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 02f7db5c10564..eb811b1fb80f9 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 },
-- 
2.53.0


  parent reply	other threads:[~2026-04-20 13:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260420132314.1023554-1-sashal@kernel.org>
2026-04-20 13:16 ` [PATCH AUTOSEL 6.18] HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP Sasha Levin
2026-04-20 13:18 ` [PATCH AUTOSEL 6.18] HID: roccat: fix use-after-free in roccat_report_event Sasha Levin
2026-04-20 13:19 ` Sasha Levin [this message]
2026-04-20 13:21 ` [PATCH AUTOSEL 6.18] HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs Sasha Levin
2026-04-20 13:21 ` [PATCH AUTOSEL 7.0-6.6] HID: playstation: validate num_touch_reports in DualShock 4 reports Sasha Levin
2026-04-20 13:22 ` [PATCH AUTOSEL 6.18] HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260420132314.1023554-203-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=bentiss@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jkosina@suse.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfraprado@collabora.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox