[PATCH AUTOSEL 6.18] HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP

[PATCH AUTOSEL 6.18] HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP

[Sasha Levin]

From: Maximilian Pezzullo <maximilianpezzullo@gmail.com>

[ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ]

When sensor discovery fails on systems without AMD SFH sensors, the
code already emits a warning via dev_warn() in amd_sfh_hid_client_init().
The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP
return value is redundant and causes unnecessary alarm.

Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who
have no AMD SFH sensors.

Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available")
Reported-by: Casey Croy <ccroy@bugzilla.kernel.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099
Signed-off-by: Maximilian Pezzullo <maximilianpezzullo@gmail.com>
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
index 1d9f955573aa4..4b81cebdc3359 100644
--- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
+++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
@@ -413,7 +413,8 @@ static void sfh_init_work(struct work_struct *work)
 	rc = amd_sfh_hid_client_init(mp2);
 	if (rc) {
 		amd_sfh_clear_intr(mp2);
-		dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
+		if (rc != -EOPNOTSUPP)
+			dev_err(&pdev->dev, "amd_sfh_hid_client_init failed err %d\n", rc);
 		return;
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] HID: roccat: fix use-after-free in roccat_report_event

[Sasha Levin]

From: Benoît Sevens <bsevens@google.com>

[ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ]

roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.

Protect the readers list traversal with the readers_lock mutex.

Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/hid/hid-roccat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
index c7f7562e22e56..e413662f75082 100644
--- a/drivers/hid/hid-roccat.c
+++ b/drivers/hid/hid-roccat.c
@@ -257,6 +257,7 @@ int roccat_report_event(int minor, u8 const *data)
 	if (!new_value)
 		return -ENOMEM;
 
+	mutex_lock(&device->readers_lock);
 	mutex_lock(&device->cbuf_lock);
 
 	report = &device->cbuf[device->cbuf_end];
@@ -279,6 +280,7 @@ int roccat_report_event(int minor, u8 const *data)
 	}
 
 	mutex_unlock(&device->cbuf_lock);
+	mutex_unlock(&device->readers_lock);
 
 	wake_up_interruptible(&device->wait);
 	return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER

[Sasha Levin]

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

[PATCH AUTOSEL 6.18] HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs

[Sasha Levin]

From: Even Xu <even.xu@intel.com>

[ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ]

Add Nova Lake THC QuickSPI device IDs to support list.

Signed-off-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 6 ++++++
 drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
index 14cabd5dc6ddb..f0830a56d556b 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c
@@ -37,6 +37,10 @@ struct quickspi_driver_data arl = {
 	.max_packet_size_value = MAX_PACKET_SIZE_VALUE_MTL,
 };
 
+struct quickspi_driver_data nvl = {
+	.max_packet_size_value = MAX_PACKET_SIZE_VALUE_LNL,
+};
+
 /* THC QuickSPI ACPI method to get device properties */
 /* HIDSPI Method: {6e2ac436-0fcf-41af-a265-b32a220dcfab} */
 static guid_t hidspi_guid =
@@ -984,6 +988,8 @@ static const struct pci_device_id quickspi_pci_tbl[] = {
 	{PCI_DEVICE_DATA(INTEL, THC_WCL_DEVICE_ID_SPI_PORT2, &ptl), },
 	{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT1, &arl), },
 	{PCI_DEVICE_DATA(INTEL, THC_ARL_DEVICE_ID_SPI_PORT2, &arl), },
+	{PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT1, &nvl), },
+	{PCI_DEVICE_DATA(INTEL, THC_NVL_H_DEVICE_ID_SPI_PORT2, &nvl), },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, quickspi_pci_tbl);
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
index c30e1a42eb098..bf5e18f5a5f42 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-dev.h
@@ -23,6 +23,8 @@
 #define PCI_DEVICE_ID_INTEL_THC_WCL_DEVICE_ID_SPI_PORT2 	0x4D4B
 #define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT1 	0x7749
 #define PCI_DEVICE_ID_INTEL_THC_ARL_DEVICE_ID_SPI_PORT2 	0x774B
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT1	0xD349
+#define PCI_DEVICE_ID_INTEL_THC_NVL_H_DEVICE_ID_SPI_PORT2	0xD34B
 
 /* HIDSPI special ACPI parameters DSM methods */
 #define ACPI_QUICKSPI_REVISION_NUM			2
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] HID: playstation: validate num_touch_reports in DualShock 4 reports

[Sasha Levin]

From: Benoît Sevens <bsevens@google.com>

[ Upstream commit 82a4fc46330910b4c1d9b189561439d468e3ff11 ]

The DualShock 4 HID driver fails to validate the num_touch_reports field
received from the device in both USB and Bluetooth input reports.
A malicious device could set this field to a value larger than the
allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
leading to an out-of-bounds read in dualshock4_parse_report().

This can result in kernel memory disclosure when processing malicious
HID reports.

Validate num_touch_reports against the array size for the respective
connection types before processing the touch data.

Signed-off-by: Benoît Sevens <bsevens@google.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 enough information to make my analysis. Let me compile the
complete assessment.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parse**
Record: `[HID: playstation:]` `[validate]` - validates
`num_touch_reports` in DualShock 4 USB and Bluetooth input reports to
prevent out-of-bounds reads from malicious HID devices.

**Step 1.2: Commit message tags**
Record:
- `Signed-off-by: Benoît Sevens <bsevens@google.com>` - author from
  Google (security researcher who has found and fixed multiple HID/USB
  vulnerabilities)
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>` - HID subsystem
  maintainer applied it
- **No** `Fixes:`, `Reported-by:`, `Reviewed-by:`, `Tested-by:`,
  `Link:`, or `Cc: stable` tags (expected absence of stable tag - that's
  why review is needed)

**Step 1.3: Commit body analysis**
Record: The commit explicitly describes a security vulnerability: a
malicious HID device can set `num_touch_reports` in the input report
payload to an arbitrary u8 value (0-255). Since the `touch_reports[]`
arrays are fixed at size 3 (USB) and 4 (Bluetooth), values >3/4 cause
out-of-bounds reads in `dualshock4_parse_report()`, leading to **kernel
memory disclosure**. Root cause: missing bounds check on device-supplied
count.

**Step 1.4: Hidden bug fix detection**
Record: Not hidden - the commit is explicitly a security fix. The
language "validate" + "malicious device" + "kernel memory disclosure" +
"out-of-bounds read" is textbook security fix vocabulary.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file (`drivers/hid/hid-playstation.c`), 12 lines added, 0
removed. Modifies one function: `dualshock4_parse_report()`.
Classification: single-file surgical fix.

**Step 2.2: Code flow change**
Record:
- Before: Code blindly trusted `usb->num_touch_reports` and
  `bt->num_touch_reports` from device, used them as loop bound for
  `touch_reports[]` array access at line 2482.
- After: Validates both fields against `ARRAY_SIZE(touch_reports)`
  before use; returns `-EINVAL` with `hid_err()` log on bogus values.

**Step 2.3: Bug mechanism**
Record: Category (f) memory safety / bounds check fix. The
`num_touch_reports` is a u8 field in the HID report, attacker-controlled
(up to 255). The later loop `for (i = 0; i < num_touch_reports; i++) {
struct dualshock4_touch_report *touch_report = &touch_reports[i]; ...}`
dereferences each `touch_report` and reads `.contact`, `.x_hi`, `.x_lo`,
`.y_hi`, `.y_lo` fields, then feeds them into `input_report_abs()`. With
`num_touch_reports=255` (u8 max) × 9 bytes per `dualshock4_touch_report`
= up to 2,295 bytes of OOB read beyond the 64-byte USB (or 78-byte BT)
report buffer. Disclosed content can potentially leak to userspace via
the resulting input events.

**Step 2.4: Fix quality**
Record: Obviously correct - `ARRAY_SIZE()` is the canonical sizeof-based
macro, the comparison is unsigned-safe, and the return path properly
propagates the error. Zero regression risk: only an early return when
invalid input is detected; valid devices (which set num_touch_reports ≤
3 or ≤ 4) are completely unaffected. No locking, memory, or API changes.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: The buggy loop `for (i = 0; i < num_touch_reports; i++)` was
introduced in commit `752038248808a` ("HID: playstation: add DualShock4
touchpad support") by Roderick Colenbrander, 2022-10-29. The BT path
(`bt->num_touch_reports = ...`) was added in `2d77474a239294` same day.
`git describe --contains 752038248808a7` returns `v6.2-rc1~115^2~2^2~11`
— so the bug landed in **v6.2**.

**Step 3.2: Fixes: tag**
Record: No Fixes: tag present. However, git blame clearly points to
`752038248808a` (v6.2) and `2d77474a239294` (v6.2) as the introducing
commits. Neither exists in pre-6.2 stable trees (5.15.y, 5.10.y, 4.19.y,
etc.).

**Step 3.3: File history**
Record: File has seen churn (cleanup commits from Cristian Ciocaltea in
2025-06: u8 migration `134a40c9d6d9b`, alignment fixes `56d7f285bfaa38`,
guard/scoped_guard refactoring `a38d070ffe338`), but none that would
significantly affect the specific hunks modified by this patch. The
`num_touch_reports` access pattern and struct layout are unchanged since
v6.2.

**Step 3.4: Author's other commits**
Record:
```
d802d848308b3 HID: roccat: fix use-after-free in roccat_report_event
2f1763f62909c HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq
082dd785e2086 media: uvcvideo: Refactor frame parsing code...
b909df18ce2a9 ALSA: usb-audio: Fix potential out-of-bound accesses for
Extigy and Mbox
ecf2b43018da9 media: uvcvideo: Skip parsing frames of type
UVC_VS_UNDEFINED
```
Record: Benoît Sevens is a Google security researcher. His HID/USB bug
fixes (e.g., wacom OOB) have been AUTOSEL'd into stable 5.10–6.19.
Strong trust indicator.

**Step 3.5: Dependencies**
Record: Standalone patch. Uses only `ARRAY_SIZE()`, `hid_err()`, and
struct fields that have existed since v6.2. No prerequisites.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original submission**
Record: `b4 dig -c 82a4fc4633091` found it immediately at `https://lore.
kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`. Only v1
exists — no review iterations.

**Step 4.2: Recipients**
Record: `b4 dig -w` shows To: Roderick Colenbrander (original DS4
author, Sony), Jiri Kosina (HID maintainer, jikos@kernel.org), Benjamin
Tissoires (HID co-maintainer, bentiss@kernel.org), Cc: linux-input,
linux-kernel. Maintainer-appropriate recipient list.

**Step 4.3: Discussion thread**
Record: Thread saved to `/tmp/playstation-thread.mbox`. Only one reply -
from Jiri Kosina:
> "Applied now to hid.git#for-7.0/upstream-fixes, thanks!"

Applied to the "upstream-fixes" branch, i.e., treated as a bug fix for
the current merge window, not "next". No NAK, no concerns raised. No
explicit stable nomination in the thread, but the maintainer considered
it an urgent fix (upstream-fixes branch).

**Step 4.4: Related series**
Record: Not part of a series - single standalone patch.

**Step 4.5: Stable list history**
Record: No prior stable discussion found for this specific bug. Similar
sibling fix (`HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq`
by the same author) was AUTOSEL'd to stable 5.10-6.19 per public archive
— same author, same class of fix, same quality profile.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
Record: Only `dualshock4_parse_report()`.

**Step 5.2: Callers**
Record: `dualshock4_parse_report` is assigned to `ps_dev->parse_report`
(line 2720) and called via the dongle path at line 2603 and ultimately
from `ps_raw_event` (line 2824-2825) which is the `.raw_event` callback
in `ps_driver` (line 2923). The chain is: HID core `hid_input_report()`
→ driver's `.raw_event` → `ps_raw_event` → `dualshock4_parse_report`.
This is called for **every input report** from any device matching Sony
PS4 controller USB/BT IDs.

**Step 5.3: Callees**
Record: Inside the loop, `input_mt_slot()`,
`input_mt_report_slot_state()`, `input_report_abs()` consume data read
from `touch_reports[i]`. Reading OOB does not crash directly (these are
arithmetic operations on u8 fields) but the leaked data flows as input
coordinates and touchpoint activity to userspace input event consumers.

**Step 5.4: Reachability**
Record: Triggerable by any device that enumerates with USB VID/PID or BT
identification matching `USB_VENDOR_ID_SONY` +
`USB_DEVICE_ID_SONY_PS4_CONTROLLER[_2]` (list at lines 2893-2903).
Attacker scenarios:
- Physical USB plug of a crafted device
- Bluetooth-proximate attacker masquerading as a DualShock 4
No root privileges required - kernel trusts device-reported data.

**Step 5.5: Similar patterns**
Record: Other HID drivers have similar validation patterns added
recently (wacom_intuos_bt_irq length checks, `HID: multitouch: Check to
ensure report responses match the request`). Same author has
systematically audited HID drivers for malicious-device OOB reads. This
fits the established pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code presence in stable**
Record: Verified with `git cat-file -p v6.2:drivers/hid/hid-
playstation.c` through `v6.15`. All versions from v6.2 onward contain
the identical vulnerable code (`num_touch_reports` usage). `v6.1` does
NOT contain DS4 support in this file. Affected stable trees: **6.6.y,
6.12.y, 6.15.y, 6.16.y, 6.17.y and any active stable ≥ 6.2**. NOT
affected: 6.1.y, 5.15.y, 5.10.y, 4.19.y.

**Step 6.2: Backport difficulty**
Record: Minor context differences — in pre-2025 stable trees (e.g.,
v6.6), the `u32` is spelled `uint32_t` and `u8` is spelled `uint8_t`.
The actual changed lines (`if (usb->num_touch_reports >
ARRAY_SIZE(usb->touch_reports))`) use only struct field names and
`ARRAY_SIZE`, which are identical across all affected stable trees.
Expected to apply cleanly with a tiny fuzz or minor manual adjustment.
In v6.12+, structs already use `u8` so the patch applies 1:1.

**Step 6.3: Related fixes in stable**
Record: No prior fix for this specific issue in stable.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/hid/` - HID subsystem, specifically the generic `hid-
playstation` driver covering a widely-used gaming controller family.
IMPORTANT criticality (widely used on desktops, laptops, SteamOS/Steam
Deck, and gaming setups). Security-relevant because HID devices can be
hot-plugged by untrusted users.

**Step 7.2: Subsystem activity**
Record: Active subsystem — 69 commits to this file since initial
addition. Regular fixes and feature additions. Maintainer is responsive
(applied patch within weeks).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected users**
Record: Anyone with `CONFIG_HID_PLAYSTATION=m/y` (common default in
distros) who connects a DualShock 4 — real or attacker-crafted. Applies
across USB and Bluetooth. Config-dependent but the config is widely
enabled.

**Step 8.2: Trigger conditions**
Record: A device that identifies as Sony PS4 controller (USB VID 0x054C
+ PID 0x05C4/0x09CC, or BT equivalent) sends a crafted input report with
`num_touch_reports > 3` (USB) or `> 4` (BT). Unprivileged attacker can
trigger via physical USB access or Bluetooth proximity + pairing. No
local privileges needed.

**Step 8.3: Severity**
Record: **HIGH severity**. Out-of-bounds read of ~2 KB of adjacent
kernel memory per malicious report. Consequences:
- Kernel memory disclosure (KASLR bypass via pointer leakage, leaking
  kernel data structures, potentially credentials/secrets if mapped
  nearby)
- No direct crash (no memory writes, no deref of wild pointers) but
  information leak is a well-recognized security class
- Sets the stage for chained exploitation

**Step 8.4: Risk-benefit**
Record:
- BENEFIT: High - fixes an exploitable kernel information disclosure in
  a widely-deployed driver
- RISK: Very low - 12 lines added, pure input validation, no behavior
  change for valid devices, no locking/memory model changes, returns
  -EINVAL which drops the report (graceful)
- Ratio: Strongly favors backporting.

## PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
FOR:
- Explicit security fix (kernel memory disclosure) from a Google
  security researcher
- Trivially correct input validation (compared with compile-time
  ARRAY_SIZE)
- Zero regression risk: only drops malformed reports that already would
  have led to OOB reads
- Maintainer applied to `for-7.0/upstream-fixes` (treated as fix-track,
  not feature)
- Same author's sibling HID fixes (wacom OOB) have been AUTOSEL'd into
  stable
- Reachable by unprivileged users via USB/BT
- Affects all stable trees ≥ 6.2

AGAINST: None material. (Lack of Cc: stable / Fixes: tag is expected and
not a negative signal per the instructions.)

UNRESOLVED: None of substance.

**Step 9.2: Stable rules check**
1. Obviously correct/tested: YES — code is trivially correct; maintainer
   applied it
2. Real bug affecting users: YES — any malicious/broken HID device
   triggers it
3. Important issue: YES — kernel information disclosure, security-
   relevant
4. Small and contained: YES — 12 lines, single file, single function
5. No new features/APIs: YES — pure validation
6. Applies to stable: YES — minor context adjustments for uint8_t/u8 in
   older trees, otherwise clean

**Step 9.3: Exception category**
Record: Security fix for existing, shipped, widely-deployed driver -
meets the "fixes a real bug" criterion directly; not needed as a special
exception.

**Step 9.4: Decision**
Backport recommended.

## Explanation

The commit fixes a real kernel information disclosure vulnerability in
the `hid-playstation` driver. A malicious USB or Bluetooth device
advertising Sony PS4 controller IDs can provide a `num_touch_reports`
value larger than the fixed `touch_reports[3]` (USB) or
`touch_reports[4]` (BT) arrays in the HID report struct. The subsequent
loop in `dualshock4_parse_report()` reads up to ~2 KB of adjacent kernel
memory and feeds it to userspace input events, leaking kernel data.

The fix is textbook stable material: 12 lines of added input validation,
zero behavioral change for legitimate devices, no locking/memory model
changes, and no new APIs. The author (Benoît Sevens, Google) has a track
record of similar HID fixes (roccat UAF, wacom OOB) where comparable
fixes have been AUTOSEL'd into stable 5.10–6.19. The HID maintainer
(Jiri Kosina) applied the patch to the upstream-fixes branch, signaling
he considers it a fix rather than a feature.

The buggy code landed in v6.2 (commits `752038248808a`,
`2d77474a239294`), so stable trees ≥ 6.2 (6.6.y, 6.12.y, etc.) are all
affected and should receive this fix. The patch should apply cleanly
with only minor context fuzz in pre-`u8` stable branches.

## Verification

- [Phase 1] Parsed tags: only SoB tags, no Reported-by/Fixes/Cc:stable.
  Verified by reading commit message.
- [Phase 2] Diff analysis: verified 12 added lines in
  `dualshock4_parse_report()` - two parallel `if (usb->num_touch_reports
  > ARRAY_SIZE(usb->touch_reports))` / `... bt->... >
  ARRAY_SIZE(bt->touch_reports)` checks with `hid_err()` + `return
  -EINVAL`.
- [Phase 2] Verified struct layouts: `struct
  dualshock4_input_report_usb.touch_reports[3]` (line 482), `struct
  dualshock4_input_report_bt.touch_reports[4]` (line 492),
  `num_touch_reports` is u8 (lines 481, 491).
- [Phase 2] Verified consumer loop at line 2482: `for (i = 0; i <
  num_touch_reports; i++) { struct dualshock4_touch_report *touch_report
  = &touch_reports[i]; ... }` confirms OOB read.
- [Phase 3] `git blame -L 2482,2483` confirmed buggy loop introduced by
  commit `752038248808a7` (Roderick Colenbrander, 2022-10-29).
- [Phase 3] `git blame -L 2380,2396` confirmed BT path introduced by
  `2d77474a239294`.
- [Phase 3] `git describe --contains 752038248808a7` =
  `v6.2-rc1~115^2~2^2~11`; `2d77474a239294` = `v6.2-rc1~115^2~2^2~4` —
  both are pre-v6.2 rc1, so land in v6.2.
- [Phase 3] Author commit list: `git log --author="bsevens"` shows
  roccat UAF, wacom OOB, ALSA Extigy OOB - consistent security fix
  pattern.
- [Phase 4] `b4 dig -c 82a4fc4633091` found submission at `https://lore.
  kernel.org/all/20260323124737.3223129-1-bsevens@google.com/`.
- [Phase 4] `b4 dig -a`: only v1 - no review iterations.
- [Phase 4] `b4 dig -w`: recipients = Roderick Colenbrander (Sony), Jiri
  Kosina, Benjamin Tissoires, linux-input. Appropriate.
- [Phase 4] `b4 dig -m` + read /tmp/playstation-thread.mbox: Jiri Kosina
  reply confirms "Applied now to hid.git#for-7.0/upstream-fixes,
  thanks!" - treated as fix.
- [Phase 4] Web search confirmed sibling `HID: wacom: fix out-of-bounds
  read in wacom_intuos_bt_irq` was AUTOSEL'd to 5.10-6.19 stable.
- [Phase 5] Verified call chain: `.raw_event = ps_raw_event` (line 2923)
  → `ps_raw_event` (2819) → `dev->parse_report` (2825) assigned to
  `dualshock4_parse_report` at line 2720.
- [Phase 5] Verified ID table at lines 2893-2903 (Sony PS4 USB + BT
  IDs).
- [Phase 6] `git cat-file -p vX:drivers/hid/hid-playstation.c | grep
  num_touch_reports` for v6.2-v6.15 each returned 6 matches — consistent
  code present across all post-v6.2 trees; v6.1 returned 0 (driver path
  absent).
- [Phase 6] Verified v6.6 struct definitions (uint8_t spelling) — patch
  would need trivial context refit for pre-2025 stable trees but target
  lines are identical.
- UNVERIFIED: Whether the raw HID buffer passed into `raw_event` in
  practice is always exactly 64/78 bytes or larger (irrelevant to
  decision — even at 64+7 bytes, 255 touch entries still far exceeds the
  buffer, so the security impact holds).

**YES**

 drivers/hid/hid-playstation.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 3c0db8f93c829..c43caac20b61b 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2377,6 +2377,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
 		struct dualshock4_input_report_usb *usb =
 			(struct dualshock4_input_report_usb *)data;
 
+		if (usb->num_touch_reports > ARRAY_SIZE(usb->touch_reports)) {
+			hid_err(hdev, "DualShock4 USB input report has invalid num_touch_reports=%d\n",
+				usb->num_touch_reports);
+			return -EINVAL;
+		}
+
 		ds4_report = &usb->common;
 		num_touch_reports = usb->num_touch_reports;
 		touch_reports = usb->touch_reports;
@@ -2391,6 +2397,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
 			return -EILSEQ;
 		}
 
+		if (bt->num_touch_reports > ARRAY_SIZE(bt->touch_reports)) {
+			hid_err(hdev, "DualShock4 BT input report has invalid num_touch_reports=%d\n",
+				bt->num_touch_reports);
+			return -EINVAL;
+		}
+
 		ds4_report = &bt->common;
 		num_touch_reports = bt->num_touch_reports;
 		touch_reports = bt->touch_reports;
-- 
2.53.0

[PATCH AUTOSEL 6.18] HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3

[Sasha Levin]

From: leo vriska <leo@60228.dev>

[ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ]

According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.

[1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/

Signed-off-by: leo vriska <leo@60228.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/hid/hid-ids.h    | 3 +++
 drivers/hid/hid-quirks.c | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d9d354f1b8847..a245928933454 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -22,6 +22,9 @@
 #define USB_DEVICE_ID_3M2256		0x0502
 #define USB_DEVICE_ID_3M3266		0x0506
 
+#define USB_VENDOR_ID_8BITDO		0x2dc8
+#define USB_DEVICE_ID_8BITDO_PRO_3	0x6009
+
 #define USB_VENDOR_ID_A4TECH		0x09da
 #define USB_DEVICE_ID_A4TECH_WCP32PU	0x0006
 #define USB_DEVICE_ID_A4TECH_X5_005D	0x000a
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3217e436c052c..f6be3ffee0232 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -25,6 +25,7 @@
  */
 
 static const struct hid_device_id hid_quirks[] = {
+	{ HID_USB_DEVICE(USB_VENDOR_ID_8BITDO, USB_DEVICE_ID_8BITDO_PRO_3), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_GAMEPAD), HID_QUIRK_BADPAD },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR), HID_QUIRK_BADPAD },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ADATA_XPG, USB_VENDOR_ID_ADATA_XPG_WL_GAMING_MOUSE), HID_QUIRK_ALWAYS_POLL },
-- 
2.53.0