[PATCH AUTOSEL 6.18] HID: Elecom: Add support for ELECOM M-XT3DRBK (018C)

[PATCH AUTOSEL 6.18] HID: Elecom: Add support for ELECOM M-XT3DRBK (018C)

[Sasha Levin]

From: Arnoud Willemsen <mail@lynthium.com>

[ Upstream commit 12adb969658ec39265eb8c7ea9e1856867fb9ceb ]

Wireless/new version of the Elecom trackball mouse M-XT3DRBK has a
product id that differs from the existing M-XT3DRBK.
The report descriptor format also seems to have changed and matches
other (newer?) models instead (except for six buttons instead of eight).
This patch follows the same format as the patch for the M-XT3URBK (018F)
by Naoki Ueki (Nov 3rd 2025) to enable the sixth mouse button.

dmesg output:
[  292.074664] usb 1-2: new full-speed USB device number 7 using xhci_hcd
[  292.218667] usb 1-2: New USB device found, idVendor=056e, idProduct=018c, bcdDevice= 1.00
[  292.218676] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  292.218679] usb 1-2: Product: ELECOM TrackBall Mouse
[  292.218681] usb 1-2: Manufacturer: ELECOM

usbhid-dump output:
001:006:000:DESCRIPTOR         1765072638.050578
 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
 29 05 15 00 25 01 95 08 75 01 81 02 95 01 75 00
 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
 95 02 81 06 C0 A1 00 05 01 09 38 15 81 25 7F 75
 08 95 01 81 06 C0 A1 00 05 0C 0A 38 02 95 01 75
 08 15 81 25 7F 81 06 C0 C0 06 01 FF 09 00 A1 01
 85 02 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0
 05 0C 09 01 A1 01 85 05 15 00 26 3C 02 19 00 2A
 3C 02 75 10 95 01 81 00 C0 05 01 09 80 A1 01 85
 03 19 81 29 83 15 00 25 01 95 03 75 01 81 02 95
 01 75 05 81 01 C0 06 BC FF 09 88 A1 01 85 04 95
 01 75 08 15 00 26 FF 00 19 00 2A FF 00 81 00 C0
 06 02 FF 09 02 A1 01 85 06 09 02 15 00 26 FF 00
 75 08 95 07 B1 02 C0

Signed-off-by: Arnoud Willemsen <mail@lynthium.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of HID: Elecom: Add support for ELECOM M-XT3DRBK (018C)

### 1. COMMIT MESSAGE ANALYSIS

The commit adds support for a new USB product ID (0x018c) for a wireless
variant of the ELECOM M-XT3DRBK trackball mouse. The message indicates:
- It's a wireless/new version of an existing supported device
- The report descriptor format differs from the older variant
- The patch enables the sixth mouse button
- dmesg output confirms the device identification

### 2. CODE CHANGE ANALYSIS

**hid-ids.h:**
- Renames `USB_DEVICE_ID_ELECOM_M_XT3DRBK` →
  `USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC` (clarifying the existing ID)
- Adds new `USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C` = 0x018c

**hid-elecom.c:**
- Updates references to use the renamed constant `_00FC`
- Adds a new case in the switch statement for `_018C` calling
  `mouse_button_fixup()` with parameters specific to this device's HID
  report descriptor: `(22, 30, 24, 16, 6)`
- Adds the new device ID to `elecom_devices[]` table

**hid-quirks.c:**
- Updates reference to use renamed constant
- Adds new device ID to `hid_have_special_driver[]`

### 3. CLASSIFICATION

This is a **NEW DEVICE ID** addition to an existing driver - one of the
explicitly allowed categories for stable backports:
- The driver (hid-elecom) already exists in stable trees
- Only adding a USB product ID to enable new hardware
- Uses existing `mouse_button_fixup()` infrastructure

### 4. SCOPE AND RISK ASSESSMENT

- **Size:** ~15 lines added across 3 files
- **Complexity:** Very low - follows identical patterns to existing
  devices
- **Risk:** Minimal - change is isolated to this specific USB device ID
- **Subsystem:** HID drivers are mature and this pattern is well-
  established

### 5. USER IMPACT

- **Affected users:** Owners of wireless ELECOM M-XT3DRBK (018C)
  trackball mouse
- **Without fix:** The sixth mouse button doesn't work
- **With fix:** Full hardware functionality enabled
- **Severity:** Functional hardware issue - extra button is non-
  functional without this fix

### 6. STABILITY INDICATORS

- Signed off by Jiri Kosina (HID subsystem maintainer)
- Follows exact same pattern as other Elecom devices
- Includes device testing evidence (dmesg/usbhid-dump output)

### 7. DEPENDENCY CHECK

- No dependencies on other patches
- All required infrastructure (`mouse_button_fixup()`,
  `elecom_report_fixup()`) exists in stable trees
- Self-contained change

### VERDICT

This commit is a textbook example of what **IS** appropriate for stable
backporting. It adds a new USB device ID to an existing driver to enable
hardware support - explicitly allowed under stable rules. The change is:
- Small and surgical
- Low risk (isolated to specific hardware)
- Uses existing patterns and infrastructure
- Enables real hardware to work correctly
- Has no behavioral changes to existing code paths

The only modification beyond adding the new ID is renaming the existing
`USB_DEVICE_ID_ELECOM_M_XT3DRBK` to
`USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC` for clarity, which is a harmless
naming change that doesn't affect functionality.

**YES**

 drivers/hid/hid-elecom.c | 15 +++++++++++++--
 drivers/hid/hid-ids.h    |  3 ++-
 drivers/hid/hid-quirks.c |  3 ++-
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-elecom.c b/drivers/hid/hid-elecom.c
index 981d1b6e96589..2003d2dcda7cc 100644
--- a/drivers/hid/hid-elecom.c
+++ b/drivers/hid/hid-elecom.c
@@ -77,7 +77,7 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		break;
 	case USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB:
 	case USB_DEVICE_ID_ELECOM_M_XT3URBK_018F:
-	case USB_DEVICE_ID_ELECOM_M_XT3DRBK:
+	case USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC:
 	case USB_DEVICE_ID_ELECOM_M_XT4DRBK:
 		/*
 		 * Report descriptor format:
@@ -102,6 +102,16 @@ static const __u8 *elecom_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		 */
 		mouse_button_fixup(hdev, rdesc, *rsize, 12, 30, 14, 20, 8);
 		break;
+	case USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C:
+		/*
+		 * Report descriptor format:
+		 * 22: button bit count
+		 * 30: padding bit count
+		 * 24: button report size
+		 * 16: button usage maximum
+		 */
+		mouse_button_fixup(hdev, rdesc, *rsize, 22, 30, 24, 16, 6);
+		break;
 	case USB_DEVICE_ID_ELECOM_M_DT2DRBK:
 	case USB_DEVICE_ID_ELECOM_M_HT1DRBK_011C:
 		/*
@@ -122,7 +132,8 @@ static const struct hid_device_id elecom_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20DLBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index bec913a005a5d..b75d9d2f4dc73 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -455,7 +455,8 @@
 #define USB_DEVICE_ID_ELECOM_M_XGL20DLBK	0x00e6
 #define USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB	0x00fb
 #define USB_DEVICE_ID_ELECOM_M_XT3URBK_018F	0x018f
-#define USB_DEVICE_ID_ELECOM_M_XT3DRBK	0x00fc
+#define USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC	0x00fc
+#define USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C	0x018c
 #define USB_DEVICE_ID_ELECOM_M_XT4DRBK	0x00fd
 #define USB_DEVICE_ID_ELECOM_M_DT1URBK	0x00fe
 #define USB_DEVICE_ID_ELECOM_M_DT1DRBK	0x00ff
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index d6e42125d9189..e823661389016 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -413,7 +413,8 @@ static const struct hid_device_id hid_have_special_driver[] = {
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XGL20DLBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_00FB) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3URBK_018F) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_00FC) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT3DRBK_018C) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_XT4DRBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1URBK) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_M_DT1DRBK) },
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list

[Sasha Levin]

From: Chris Chiu <chris.chiu@canonical.com>

[ Upstream commit c06bc3557542307b9658fbd43cc946a14250347b ]

Another Chicony Electronics HP 5MP Camera with USB ID 04F2:B882
reports a HID sensor interface that is not actually implemented.

Add the device to the HID ignore list so the bogus sensor is never
exposed to userspace. Then the system won't hang when runtime PM
tries to wake the unresponsive device.

Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: HID Quirks for Chicony HP 5MP Camera

### 1. COMMIT MESSAGE ANALYSIS

The commit message is clear and explains:
- A specific Chicony HP 5MP Camera (USB ID 04F2:B882) reports a HID
  sensor interface that **is not actually implemented**
- Without this fix, **the system hangs** when runtime PM tries to wake
  the unresponsive device
- Solution: Add to `hid_ignore_list` so the bogus sensor is never
  exposed to userspace

Key phrase: "the system won't hang" - this is a **system hang fix**.

### 2. CODE CHANGE ANALYSIS

The change is minimal and surgical:

**hid-ids.h:** Adds one new device ID define
```c
#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3    0xb882
```

**hid-quirks.c:** Adds device to the ignore list
```c
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) },
```

This follows an **already-established pattern** - there are already two
similar entries:
- `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA` (0xb824)
- `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2` (0xb82c)

### 3. CLASSIFICATION

This falls into **two explicit exception categories** that are allowed
in stable:

1. **Device ID addition:** Adding a USB ID to an existing driver's quirk
   list
2. **Hardware quirk/workaround:** Fixing a broken device that falsely
   advertises a non-functional HID sensor interface

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Assessment |
|--------|------------|
| Lines changed | 2 |
| Files touched | 2 |
| Complexity | Trivial - just adding ID to a list |
| Risk level | **Extremely low** |

The change only affects this specific USB device (04F2:B882). No logic
changes, no control flow modifications. The `hid_ignore_list` mechanism
is mature and proven.

### 5. USER IMPACT

- **Severity:** HIGH - Prevents **system hangs** on affected HP laptops
- **Affected users:** Anyone with an HP laptop containing this specific
  Chicony 5MP camera
- **Real-world evidence:** The author is from Canonical (Ubuntu),
  suggesting this was discovered through real user bug reports

### 6. STABILITY INDICATORS

- Accepted by Benjamin Tissoires (HID maintainer)
- Uses identical mechanism to existing, proven entries
- Canonical developer submission suggests tested on real hardware

### 7. DEPENDENCY CHECK

**No dependencies.** The `hid_ignore_list` infrastructure exists in all
stable kernel versions. This is a completely standalone device ID
addition.

---

## Conclusion

This commit is a **textbook example** of what should be backported to
stable:

✅ **Fixes a real bug:** System hang during runtime PM suspend/resume
✅ **Fixes an important issue:** System hangs are severe user-facing bugs
✅ **Small and contained:** Only 2 lines, no logic changes
✅ **Obviously correct:** Follows exact pattern of existing similar
entries
✅ **Hardware quirk exception:** Explicitly allowed by stable kernel
rules
✅ **No dependencies:** Standalone addition
✅ **Zero risk:** Only affects one specific USB device ID

The bug is severe (system hang), the fix is trivial (add device to
ignore list), and the mechanism is well-proven with existing similar
entries. This is exactly what stable backports are for.

**YES**

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

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c4589075a5ed6..3a22129fb7075 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -317,6 +317,7 @@
 #define USB_DEVICE_ID_CHICONY_ACER_SWITCH12	0x1421
 #define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA	0xb824
 #define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2	0xb82c
+#define USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3	0xb882
 
 #define USB_VENDOR_ID_CHUNGHWAT		0x2247
 #define USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH	0x0001
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index c89a015686c07..3cf7971d49743 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -769,6 +769,7 @@ static const struct hid_device_id hid_ignore_list[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA3) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL, USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] HID: multitouch: add MT_QUIRK_STICKY_FINGERS to MT_CLS_VTL

[Sasha Levin]

From: DaytonCL <artem749507@gmail.com>

[ Upstream commit ff3f234ff1dcd6d626a989151db067a1b7f0f215 ]

Some VTL-class touchpads (e.g. TOPS0102:00 35CC:0104) intermittently
fail to release a finger contact. A previous slot remains logically
active, accompanied by stale BTN_TOOL_DOUBLETAP state, causing
gestures to stay latched and resulting in stuck two-finger
scrolling and false right-clicks.

Apply MT_QUIRK_STICKY_FINGERS to handle the unreleased contact correctly.

Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1225
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: DaytonCL <artem749507@gmail.com>
Signed-off-by: DaytonCL <artem749507@gmail.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of HID Multitouch Quirk Addition

### 1. COMMIT MESSAGE ANALYSIS

The commit clearly describes a **real user-visible bug**:
- VTL-class touchpads (specifically TOPS0102:00 35CC:0104)
  intermittently fail to release finger contacts
- This causes gestures to stay latched - stuck two-finger scrolling and
  false right-clicks
- Links to a libinput bug report:
  https://gitlab.freedesktop.org/libinput/libinput/-/issues/1225
- Has `Tested-by:` from the reporter and `Suggested-by:` from Benjamin
  Tissoires (HID maintainer)
- Signed off by the maintainer (Benjamin Tissoires)

### 2. CODE CHANGE ANALYSIS

The change is **extremely minimal** - adding one line:
```c
MT_QUIRK_STICKY_FINGERS |
```

to the existing `MT_CLS_VTL` class definition. This enables an already-
existing quirk flag (`MT_QUIRK_STICKY_FINGERS`) for VTL-class devices.

The quirk mechanism handles cases where a touchpad firmware fails to
properly report when a finger has been lifted. Without it, the system
thinks the finger is still touching, causing "sticky" gestures. The
quirk infrastructure already exists and is well-tested - this commit
just enables it for another device class.

### 3. CLASSIFICATION

This falls squarely into the **QUIRKS and WORKAROUNDS exception
category**:
- Hardware-specific quirk for buggy/non-compliant devices
- The quirk code already exists in mainline - only enabling it for VTL
  class
- Fixes real-world hardware behavior issues

This is NOT:
- A new feature or API
- A new driver
- Code refactoring

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | 1 |
| Files touched | 1 |
| Complexity | Trivially low |
| Subsystem | HID multitouch (mature, stable) |
| Risk | Very low |

The worst case scenario: if the quirk somehow caused issues on a
specific VTL device, it would only affect that device class. But the
current behavior is already broken for affected users, so this is a
clear improvement.

### 5. USER IMPACT

- **Affected users**: Anyone with VTL-class touchpads
- **Symptoms**: Stuck two-finger scrolling, false right-clicks - these
  are highly disruptive daily-use issues
- **Severity**: Medium-high for affected users (makes touchpad
  unreliable)
- **Evidence of real impact**: Linked bug report from libinput tracker

### 6. STABILITY INDICATORS

- `Tested-by:` tag from the reporter who experienced the issue
- Suggested and signed off by HID subsystem maintainer
- The `MT_QUIRK_STICKY_FINGERS` quirk has existed since ~Linux 3.15
- The `MT_CLS_VTL` class has existed since ~Linux 4.13
- Well-established quirk pattern used by many other device classes
  (FLATFROG, LG, ASUS, etc.)

### 7. DEPENDENCY CHECK

- **No dependencies** on other commits
- Both the quirk flag and VTL class exist in all recent stable trees
- Should apply cleanly without modification

### STABLE KERNEL RULES ASSESSMENT

| Criterion | Met? |
|-----------|------|
| Obviously correct and tested | ✅ Yes - trivial change, has Tested-by |
| Fixes a real bug | ✅ Yes - documented hardware issue with bug report |
| Important issue | ✅ Yes - stuck gestures/false clicks affect daily use
|
| Small and contained | ✅ Yes - 1 line in 1 file |
| No new features | ✅ Yes - uses existing quirk mechanism |
| Applies cleanly | ✅ Yes - no dependencies |

### CONCLUSION

This is an **ideal stable backport candidate**:

1. **Minimal risk**: Single-line addition of an existing, well-tested
   quirk flag
2. **Real user benefit**: Fixes stuck gestures and false clicks on VTL
   touchpads
3. **Proper testing**: Has Tested-by tag and maintainer approval
4. **Falls under hardware quirk exception**: Hardware quirks/workarounds
   are explicitly allowed in stable even though they add code
5. **Self-contained**: No dependencies, applies cleanly to stable trees

The fix is small, surgical, obviously correct, and addresses a real
user-visible hardware issue. This is exactly the type of hardware quirk
addition that stable trees should accept.

**YES**

 drivers/hid/hid-multitouch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 179dc316b4b51..a0c1ad5acb670 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -393,6 +393,7 @@ static const struct mt_class mt_classes[] = {
 	{ .name = MT_CLS_VTL,
 		.quirks = MT_QUIRK_ALWAYS_VALID |
 			MT_QUIRK_CONTACT_CNT_ACCURATE |
+			MT_QUIRK_STICKY_FINGERS |
 			MT_QUIRK_FORCE_GET_FEATURE,
 	},
 	{ .name = MT_CLS_GOOGLE,
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.15] HID: playstation: Center initial joystick axes to prevent spurious events

[Sasha Levin]

From: Siarhei Vishniakou <svv@google.com>

[ Upstream commit e9143268d259d98e111a649affa061acb8e13c5b ]

When a new PlayStation gamepad (DualShock 4 or DualSense) is initialized,
the input subsystem sets the default value for its absolute axes (e.g.,
ABS_X, ABS_Y) to 0.

However, the hardware's actual neutral/resting state for these joysticks
is 128 (0x80). This creates a mismatch.

When the first HID report arrives from the device, the driver sees the
resting value of 128. The kernel compares this to its initial state of 0
and incorrectly interprets this as a delta (0 -> 128). Consequently, it
generates EV_ABS events for this initial, non-existent movement.

This behavior can fail userspace 'sanity check' tests (e.g., in
Android CTS) that correctly assert no motion events should be generated
from a device that is already at rest.

This patch fixes the issue by explicitly setting the initial value of the
main joystick axes (e.g., ABS_X, ABS_Y, ABS_RX, ABS_RY) to 128 (0x80)
in the common ps_gamepad_create() function.

This aligns the kernel's initial state with the hardware's expected
neutral state, ensuring that the first report (at 128) produces no
delta and thus, no spurious event.

Signed-off-by: Siarhei Vishniakou <svv@google.com>
Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: "HID: playstation: Center initial joystick axes
to prevent spurious events"

### 1. COMMIT MESSAGE ANALYSIS

The commit describes a clear, specific bug:
- PlayStation gamepads (DualShock 4, DualSense) have joysticks that rest
  at value 128 (0x80)
- The kernel initializes the axis value to 0 by default
- When the first HID report arrives with the resting value of 128, the
  kernel interprets this as actual movement
- This generates spurious EV_ABS events for non-existent movement
- The problem causes Android CTS test failures and potentially confuses
  userspace applications

The bug has user-visible impact ("Reported-by" pattern implied through
CTS test context).

### 2. CODE CHANGE ANALYSIS

**The fix is minimal and surgical:**
```c
gamepad->absinfo[ABS_X].value = 128;
gamepad->absinfo[ABS_Y].value = 128;
gamepad->absinfo[ABS_RX].value = 128;
gamepad->absinfo[ABS_RY].value = 128;
```

- 5 lines added (1 comment + 4 value assignments)
- Single file: `drivers/hid/hid-playstation.c`
- Single function: `ps_gamepad_create()`
- Only affects joystick axes (ABS_X, ABS_Y, ABS_RX, ABS_RY), correctly
  leaves triggers (ABS_Z, ABS_RZ) at 0

**Technical correctness:** The fix is obviously correct. After
`input_set_abs_params()` sets up the axis with range 0-255, manually
setting `.value = 128` aligns the kernel's initial state with the
hardware's physical resting position at center (128).

### 3. CLASSIFICATION

- **Type:** Bug fix (not a feature)
- **Category:** Input device initialization fix
- **No new API or behavior change:** Just corrects initial state values
- **No new features:** Purely corrects existing incorrect behavior

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment |
|--------|------------|
| Lines changed | 5 (very small) |
| Files changed | 1 |
| Complexity | Trivial |
| Subsystem | HID - PlayStation driver (mature) |
| Risk of regression | Very low |

The change is confined to initialization code and cannot affect any
existing logic paths. Setting an initial value cannot break anything
because:
1. The value 128 is within the valid range (0-255)
2. The hardware reports 128 at rest anyway
3. This aligns kernel state with reality

### 5. USER IMPACT

**Who is affected:**
- All users of DualShock 4 and DualSense controllers
- Android users (CTS compliance)
- Applications that validate initial input state

**Severity:** Medium - Not a crash or data corruption, but:
- Causes spurious input events at device connect
- Breaks CTS conformance tests
- May confuse input-sensitive applications

### 6. STABILITY INDICATORS

- **Reviewed-by:** Benjamin Tissoires (HID maintainer) ✓
- **Signed-off-by:** Maintainer sign-off ✓
- The fix is simple enough to verify correctness by inspection

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- `ps_gamepad_create()` has existed since the driver was introduced
- Uses standard input subsystem patterns (`absinfo[].value`)
- Should apply cleanly to any stable tree containing this driver

### STABLE KERNEL CRITERIA EVALUATION

| Criterion | Status |
|-----------|--------|
| Obviously correct and tested | ✓ Reviewed by maintainer |
| Fixes a real bug | ✓ Spurious input events |
| Important issue | ✓ Breaks CTS, affects popular hardware |
| Small and contained | ✓ 5 lines, 1 file |
| No new features | ✓ Pure correctness fix |
| No new APIs | ✓ |

### RISK VS BENEFIT

**Benefits:**
- Fixes spurious input events on popular consumer hardware
- Fixes Android CTS test failures
- Aligns kernel state with hardware reality
- Affects millions of PlayStation controller users

**Risks:**
- Essentially zero - the change is trivially correct
- No logic changes, just initialization values

### CONCLUSION

This commit is an excellent candidate for stable backporting:

1. **Fixes a real bug** that causes spurious input events and test
   failures
2. **Small and surgical** - only 5 lines in one function
3. **Obviously correct** - aligns initial value with hardware's physical
   state
4. **Low risk** - cannot introduce regressions
5. **Well-reviewed** - HID maintainer reviewed and signed off
6. **Widely applicable** - affects popular consumer hardware
   (PlayStation controllers)
7. **No dependencies** - self-contained fix

The fix meets all stable kernel criteria: it's obviously correct, fixes
a real bug, is small in scope, and introduces no new features. The fact
that it fixes CTS compliance issues makes it particularly valuable for
Android device manufacturers using stable kernels.

**YES**

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

diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 128aa6abd10be..e4dfcf26b04e7 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -753,11 +753,16 @@ ps_gamepad_create(struct hid_device *hdev,
 	if (IS_ERR(gamepad))
 		return ERR_CAST(gamepad);
 
+	/* Set initial resting state for joysticks to 128 (center) */
 	input_set_abs_params(gamepad, ABS_X, 0, 255, 0, 0);
+	gamepad->absinfo[ABS_X].value = 128;
 	input_set_abs_params(gamepad, ABS_Y, 0, 255, 0, 0);
+	gamepad->absinfo[ABS_Y].value = 128;
 	input_set_abs_params(gamepad, ABS_Z, 0, 255, 0, 0);
 	input_set_abs_params(gamepad, ABS_RX, 0, 255, 0, 0);
+	gamepad->absinfo[ABS_RX].value = 128;
 	input_set_abs_params(gamepad, ABS_RY, 0, 255, 0, 0);
+	gamepad->absinfo[ABS_RY].value = 128;
 	input_set_abs_params(gamepad, ABS_RZ, 0, 255, 0, 0);
 
 	input_set_abs_params(gamepad, ABS_HAT0X, -1, 1, 0, 0);
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] HID: intel-ish-hid: Reset enum_devices_done before enumeration

[Sasha Levin]

From: Zhang Lixu <lixu.zhang@intel.com>

[ Upstream commit 56e230723e3a818373bd62331bccb1c6d2b3881b ]

Some systems have enabled ISH without any sensors. In this case sending
HOSTIF_DM_ENUM_DEVICES results in 0 sensors. This triggers ISH hardware
reset on subsequent enumeration after S3/S4 resume.

The enum_devices_done flag was not reset before sending the
HOSTIF_DM_ENUM_DEVICES command. On subsequent enumeration calls (such as
after S3/S4 resume), this flag retains its previous true value, causing the
wait loop to be skipped and returning prematurely to hid_ishtp_cl_init().
If 0 HID devices are found, hid_ishtp_cl_init() skips getting HID device
descriptors and sets init_done to true. When the delayed enumeration
response arrives with init_done already true, the driver treats it as a bad
packet and triggers an ISH hardware reset.

Set enum_devices_done to false before sending the enumeration command,
consistent with similar functions like ishtp_get_hid_descriptor() and
ishtp_get_report_descriptor() which reset their respective flags.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: HID: intel-ish-hid: Reset enum_devices_done
before enumeration

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a **bug in suspend/resume (S3/S4)
handling**:
- Systems with ISH enabled but no sensors return 0 devices from
  HOSTIF_DM_ENUM_DEVICES
- The `enum_devices_done` flag wasn't reset before sending enumeration
  commands
- On subsequent enumerations (after resume), the stale `true` value
  causes the wait loop to be skipped
- This leads to a race where delayed responses are treated as bad
  packets
- Result: **ISH hardware reset** during resume

Key indicators:
- "S3/S4 resume" - power management bug affecting real user workflows
- Clear explanation of the timing/race condition
- Acked-by Srinivas Pandruvada (Intel ISH maintainer)

### 2. CODE CHANGE ANALYSIS

The diff shows a **single line addition**:
```c
+       client_data->enum_devices_done = false;
```

Added immediately before the `HOSTIF_DM_ENUM_DEVICES` command is sent.
The logic:
- The function sends an enumeration request and waits for
  `enum_devices_done` to become true
- Without resetting it first, a stale `true` value from a previous call
  causes immediate exit from the wait loop
- This creates a race: the response arrives after `init_done` is already
  set, triggering a hardware reset

The fix follows the **established pattern** in the same driver - the
commit message notes that `ishtp_get_hid_descriptor()` and
`ishtp_get_report_descriptor()` already reset their respective flags
similarly.

### 3. CLASSIFICATION

- **Bug fix**: Yes - fixes incorrect state handling causing hardware
  reset
- **Feature addition**: No
- **API change**: No
- **Hardware quirk**: No - this is a driver logic bug, not a hardware
  workaround

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Value |
|--------|-------|
| Lines changed | 1 |
| Files touched | 1 |
| Complexity | Very low |
| Risk | Minimal |

The change:
- Sets a boolean flag to false before an operation that expects it to
  transition to true
- Follows identical patterns elsewhere in the same file
- Cannot break any existing functionality that works correctly
- Isolated to Intel ISH subsystem

### 5. USER IMPACT

**Affected users:** Laptop users with Intel Sensor Hub hardware (common
in modern Intel laptops)

**Symptom:** ISH hardware reset during S3/S4 resume, which can cause:
- Delays in resume
- Sensor hub functionality issues after resume
- System instability during power transitions

**Severity:** Moderate-High - affects common laptop power management
workflows

### 6. STABILITY INDICATORS

- **Acked-by:** Srinivas Pandruvada (Intel ISH maintainer) - domain
  expert approval
- **Signed-off-by:** Benjamin Tissoires (HID maintainer)
- Pattern-following fix consistent with other similar functions in the
  driver

### 7. DEPENDENCY CHECK

This commit:
- Is self-contained with no dependencies
- Modifies code that has existed in stable trees for years
- The `enum_devices_done` flag, `client_data` structure, and
  `ishtp_enum_enum_devices()` function are all well-established

---

## Summary

**What it fixes:** Race condition during S3/S4 resume where stale
boolean flag causes ISH hardware reset

**Why it matters:** Users with Intel Sensor Hub hardware experience
hardware reset/instability on resume from suspend/hibernate - a common
laptop workflow

**Stable criteria met:**
- ✅ Obviously correct (follows existing pattern in same driver)
- ✅ Fixes real bug (hardware reset during resume)
- ✅ Small and contained (1 line, 1 file)
- ✅ No new features
- ✅ No API changes
- ✅ Has maintainer acknowledgment

**Risk assessment:** Very low - single boolean assignment following
established pattern

**Benefit:** Fixes real user-facing bug affecting laptop power
management

This is an ideal stable candidate: a minimal, surgical fix for a real
bug affecting common hardware in a common usage scenario, with
maintainer review and following established driver patterns.

**YES**

 drivers/hid/intel-ish-hid/ishtp-hid-client.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
index d8c3c54a8c0f2..537145ec50586 100644
--- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -495,6 +495,7 @@ static int ishtp_enum_enum_devices(struct ishtp_cl *hid_ishtp_cl)
 	int rv;
 
 	/* Send HOSTIF_DM_ENUM_DEVICES */
+	client_data->enum_devices_done = false;
 	memset(&msg, 0, sizeof(struct hostif_msg));
 	msg.hdr.command = HOSTIF_DM_ENUM_DEVICES;
 	rv = ishtp_cl_send(hid_ishtp_cl, (unsigned char *)&msg,
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier QR30 (2d99:a101)

[Sasha Levin]

From: Rodrigo Lugathe da Conceição Alves <lugathe2@gmail.com>

[ Upstream commit 85a866809333cd2bf8ddac93d9a3e3ba8e4f807d ]

The USB speaker has a bug that causes it to reboot when changing the
brightness using the physical knob.

Add a new vendor and product ID entry in hid-ids.h, and register
the corresponding device in hid-quirks.c with the required quirk.

Signed-off-by: Rodrigo Lugathe da Conceição Alves <lugathe2@gmail.com>
Reviewed-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of Commit: HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier
QR30

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly states:
- **Problem:** USB speaker has a bug causing it to reboot when changing
  brightness using the physical knob
- **Solution:** Apply `HID_QUIRK_ALWAYS_POLL` quirk to this device
- Has "Reviewed-by:" and "Signed-off-by:" from the HID maintainer (Jiri
  Kosina)

### 2. CODE CHANGE ANALYSIS

The changes are minimal and straightforward:

**hid-ids.h:** Adds 2 new defines
```c
#define USB_VENDOR_ID_EDIFIER      0x2d99
#define USB_DEVICE_ID_EDIFIER_QR30 0xa101
```

**hid-quirks.c:** Adds 1 entry to the quirks table
```c
{ HID_USB_DEVICE(USB_VENDOR_ID_EDIFIER, USB_DEVICE_ID_EDIFIER_QR30),
HID_QUIRK_ALWAYS_POLL },
```

The `HID_QUIRK_ALWAYS_POLL` quirk is well-established and used by dozens
of other devices in this same file (Corsair, Dell, Elan, HP, etc.). It
forces continuous polling which prevents certain hardware misbehaviors.

### 3. CLASSIFICATION

This falls into the **"QUIRKS and WORKAROUNDS" exception category** that
is explicitly allowed in stable:
- Hardware-specific quirk for a buggy/non-compliant device
- Uses existing, well-tested quirk infrastructure
- Pattern matches many other similar entries already in stable trees

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 3 lines added (2 defines + 1 quirk entry)
- **Files touched:** 2 (hid-ids.h, hid-quirks.c)
- **Risk level:** Extremely low
- **Blast radius:** Only affects users with this specific Edifier QR30
  device
- **Regression potential:** Zero for other devices - the quirk entry is
  device-specific by USB vendor/product ID

### 5. USER IMPACT

- **Severity:** Device rebooting is a significant user-visible bug
- **Affected users:** Anyone with an Edifier QR30 USB speaker
- **Fix quality:** Complete fix for the reported issue

### 6. STABILITY INDICATORS

- Reviewed by Terry Junge (HID reviewer)
- Signed off by Jiri Kosina (HID subsystem maintainer)
- The `HID_QUIRK_ALWAYS_POLL` mechanism is mature and stable

### 7. DEPENDENCY CHECK

- No dependencies on other commits
- The quirk infrastructure exists in all stable trees
- The change is self-contained

### Summary

This is a textbook example of a stable-worthy commit:
1. **Fixes a real bug:** Device rebooting when using physical controls
2. **Small and surgical:** Only 3 lines, no logic changes
3. **Uses existing infrastructure:** `HID_QUIRK_ALWAYS_POLL` is well-
   established
4. **Device-specific:** Only affects this one USB speaker model
5. **Zero regression risk:** Cannot affect other devices
6. **Falls into explicit exception:** Device ID + quirk additions are
   explicitly allowed in stable

This matches the pattern of hundreds of similar HID quirk entries that
have been backported to stable kernels. The fix is trivial, low-risk,
and solves a real user-facing problem.

**YES**

 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 3a22129fb7075..bec913a005a5d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -439,6 +439,9 @@
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001	0xa001
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002	0xc002
 
+#define USB_VENDOR_ID_EDIFIER		0x2d99
+#define USB_DEVICE_ID_EDIFIER_QR30	0xa101	/* EDIFIER Hal0 2.0 SE */
+
 #define USB_VENDOR_ID_ELAN		0x04f3
 #define USB_DEVICE_ID_TOSHIBA_CLICK_L9W	0x0401
 #define USB_DEVICE_ID_HP_X2		0x074d
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 3cf7971d49743..d6e42125d9189 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -81,6 +81,7 @@ static const struct hid_device_id hid_quirks[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU), HID_QUIRK_MULTI_INPUT },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER), HID_QUIRK_MULTI_INPUT | HID_QUIRK_NOGET },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_EDIFIER, USB_DEVICE_ID_EDIFIER_QR30), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, HID_ANY_ID), HID_QUIRK_ALWAYS_POLL },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700), HID_QUIRK_NOGET },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II), HID_QUIRK_MULTI_INPUT },
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.12] HID: logitech: add HID++ support for Logitech MX Anywhere 3S

[Sasha Levin]

From: Dennis Marttinen <twelho@welho.tech>

[ Upstream commit d7f6629bffdcb962d383ef8c9a30afef81e997fe ]

I've acquired a Logitech MX Anywhere 3S mouse, which supports HID++ over
Bluetooth. Adding its PID 0xb037 to the allowlist enables the additional
features, such as high-resolution scrolling. Tested working across multiple
machines, with a mix of Intel and Mediatek Bluetooth chips.

[jkosina@suse.com: standardize shortlog]
Signed-off-by: Dennis Marttinen <twelho@welho.tech>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of HID: logitech: add HID++ support for Logitech MX Anywhere
3S

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "HID: logitech: add HID++ support for Logitech MX Anywhere
3S"

The commit message explains:
- Author acquired an MX Anywhere 3S mouse that supports HID++ over
  Bluetooth
- Adding PID 0xb037 to the allowlist enables additional features (high-
  resolution scrolling)
- Tested on multiple machines with Intel and Mediatek Bluetooth chips
- Has proper sign-offs from author and maintainer (Jiri Kosina)

No `Cc: stable` or `Fixes:` tags are present, but as noted, that's
expected for commits undergoing manual review.

### 2. CODE CHANGE ANALYSIS

The actual change is minimal:

```c
+       { /* MX Anywhere 3S mouse over Bluetooth */
+         HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb037) },
```

This adds exactly **2 lines** - one comment and one device ID entry to
the `hidpp_devices[]` table. Looking at the context, this table already
contains many similar Logitech Bluetooth device entries:
- MX Master (0xb012), MX Master 2S (0xb019), MX Master 3 (0xb023), MX
  Master 3S (0xb034)
- MX Anywhere 3 (0xb025), MX Anywhere 3SB (0xb038)
- M720 Triathlon (0xb015), MX Ergo (0xb01d), MX Vertical (0xb020), etc.

The new entry follows the exact same pattern as all existing entries.

### 3. CLASSIFICATION

This is a **NEW DEVICE ID** addition - one of the explicitly allowed
exception categories for stable kernels:

> "Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers - These
are trivial one-line additions that enable hardware support"

Key points:
- The hid-logitech-hidpp driver already exists in stable kernels
- The HID++ protocol support is fully implemented
- Only the Bluetooth device ID 0xb037 is being added
- This is not a new driver or new functionality - it's enabling an
  existing driver for new hardware

### 4. SCOPE AND RISK ASSESSMENT

**Risk: EXTREMELY LOW**

| Factor | Assessment |
|--------|------------|
| Lines changed | 2 |
| Files touched | 1 |
| Code logic changed | None |
| Complexity | Zero - pure data table entry |
| Subsystem maturity | Very mature (HID drivers) |

This cannot introduce regressions because:
- No code paths are modified
- No functions are changed
- Only users with this specific mouse over Bluetooth are affected
- If there were somehow an issue, it would only affect that specific
  hardware

### 5. USER IMPACT

**Who benefits:** Users with Logitech MX Anywhere 3S mice using
Bluetooth connection

**Without this fix:** The mouse works via basic HID, but lacks:
- High-resolution scrolling
- Battery status reporting
- Other HID++ features that premium Logitech mice support

**Impact level:** The MX Anywhere 3S is a current-generation retail
product that users are actively purchasing. Stable kernel users expect
their hardware to work properly.

### 6. STABILITY INDICATORS

- ✅ Tested by author on multiple machines with different Bluetooth chips
- ✅ Reviewed and signed off by HID maintainer Jiri Kosina
- ✅ Pattern is identical to many existing, working entries

### 7. DEPENDENCY CHECK

**Dependencies:** None

This is a pure data addition. The driver framework already exists in all
stable kernels that have the hid-logitech-hidpp driver. No other commits
are required.

---

## Summary

This commit is a **textbook example of a stable-appropriate device ID
addition**:

1. ✅ **Trivial 2-line change** - Just a device ID added to an existing
   table
2. ✅ **No code modifications** - Pure data entry
3. ✅ **Driver already exists** - hid-logitech-hidpp is well-established
   in stable
4. ✅ **Follows existing pattern** - Identical format to dozens of other
   entries
5. ✅ **Tested** - Verified on multiple hardware configurations
6. ✅ **Zero regression risk** - Only affects users with this specific
   hardware
7. ✅ **Real user benefit** - Enables proper hardware support for
   current-generation product
8. ✅ **No dependencies** - Can be cleanly cherry-picked to any stable
   kernel

The stable kernel rules explicitly allow device ID additions because
they enable hardware support with virtually zero risk. This is precisely
what the "device ID exception" exists for.

**YES**

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

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index a88f2e5f791c6..9b612f62d0fba 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4661,6 +4661,8 @@ static const struct hid_device_id hidpp_devices[] = {
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb025) },
 	{ /* MX Master 3S mouse over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+	{ /* MX Anywhere 3S mouse over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb037) },
 	{ /* MX Anywhere 3SB mouse over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
 	{}
-- 
2.51.0