[PATCH AUTOSEL 6.19-6.6] HID: asus: add xg mobile 2023 external hardware support

[PATCH AUTOSEL 6.19-6.6] HID: asus: add xg mobile 2023 external hardware support

[Sasha Levin]

From: Denis Benato <denis.benato@linux.dev>

[ Upstream commit 377f8e788945d45b012ed9cfc35ca56c02e86cd8 ]

XG mobile stations have the 0x5a endpoint and has to be initialized:
add them to hid-asus.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit does
This commit adds a new USB device ID (`USB_DEVICE_ID_ASUSTEK_XGM_2023 =
0x1a9a`) for the ASUS XG Mobile 2023 docking station to the hid-asus
driver. The change consists of:
1. Defining the device ID constant in `hid-ids.h` (1 line)
2. Adding the device to the `asus_devices[]` table in `hid-asus.c` (3
   lines, no quirk flags)

### Classification: New Device ID Addition
This is a textbook **new device ID addition to an existing driver**. The
hid-asus driver already exists in all stable kernel trees. Only the USB
device ID entry is new.

The commit message states: "XG mobile stations have the 0x5a endpoint
and has to be initialized: add them to hid-asus." This means the
device's HID interface (with report ID 0x5a = `FEATURE_KBD_REPORT_ID`)
needs the hid-asus driver to bind to it, rather than the generic HID
driver, for the device to function properly.

### Device entry details
The entry has **no quirk flags** set. This means minimal special
handling — the device simply needs to be claimed by hid-asus (rather
than generic HID) for proper initialization and event handling. The hid-
asus driver provides baseline handling that differs from the generic HID
driver, including filtering of `FEATURE_KBD_LED_REPORT_ID` events in the
raw_event handler.

### Risk assessment
- **Scope**: 4 lines changed across 2 files
- **Risk**: Extremely low — this only affects devices with USB VID/PID
  `0x0b05:0x1a9a`. No existing device behavior is modified.
- **Self-contained**: Yes — no dependencies on other commits. The change
  only requires the existing hid-asus driver infrastructure.

### Stable kernel criteria
- **Obviously correct**: Yes — adding a device ID to an existing table
  with established patterns
- **Fixes real issue**: Enables hardware support for users with XG
  Mobile 2023 docking stations
- **Small and contained**: 4 lines total
- **No new features/APIs**: Just a device ID, no new quirk mechanisms or
  user-visible interfaces
- **Exception category**: New Device IDs — explicitly listed as
  appropriate for stable

### Verification
- Read `asus_probe()` at hid-asus.c:1127-1248 to confirm behavior with
  zero quirk flags — device goes through standard HID parse/start path
  and gets named "Asus Keyboard"
- Confirmed `USB_DEVICE_ID_ASUSTEK_XGM_2023` is only defined and used in
  these two files (self-contained)
- Confirmed the device table entry follows the exact same pattern as
  other entries in `asus_devices[]` (e.g., `USB_DEVICE_ID_ASUS_AK1D` and
  `USB_DEVICE_ID_ASUS_MD_5110` also have no quirk flags)
- Confirmed `FEATURE_KBD_REPORT_ID` is defined as `0x5a` at line 51,
  matching the commit message about the 0x5a endpoint
- No quirk flag dependencies — the entry is independent of any other
  code changes

**YES**

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

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 8487332bf43b0..b1ad4e9f20c85 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1404,6 +1404,9 @@ static const struct hid_device_id asus_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
 	    USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X),
 	  QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_ALLY_XPAD },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+	    USB_DEVICE_ID_ASUSTEK_XGM_2023),
+	},
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
 	    USB_DEVICE_ID_ASUSTEK_ROG_CLAYMORE_II_KEYBOARD),
 	  QUIRK_ROG_CLAYMORE_II_KEYBOARD },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 85ab1ac511096..7fd67745ee010 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -229,6 +229,7 @@
 #define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_ALLY_X		0x1b4c
 #define USB_DEVICE_ID_ASUSTEK_ROG_CLAYMORE_II_KEYBOARD	0x196b
 #define USB_DEVICE_ID_ASUSTEK_FX503VD_KEYBOARD	0x1869
+#define USB_DEVICE_ID_ASUSTEK_XGM_2023	0x1a9a
 
 #define USB_VENDOR_ID_ATEN		0x0557
 #define USB_DEVICE_ID_ATEN_UC100KM	0x2004
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] HID: mcp2221: cancel last I2C command on read error

[Sasha Levin]

From: Romain Sioen <romain.sioen@microchip.com>

[ Upstream commit e31b556c0ba21f20c298aa61181b96541140b7b9 ]

When an I2C SMBus read operation fails, the MCP2221 internal state machine
may not reset correctly, causing subsequent transactions to fail.

By adding a short delay and explicitly cancelling the last command,
we ensure the device is ready for the next operation.

Fix an issue where i2cdetect was not able to detect all devices correctly
on the bus.

Signed-off-by: Romain Sioen <romain.sioen@microchip.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 a complete picture. Let me summarize the analysis.

## Analysis

### What the commit fixes

The MCP2221 is a USB-to-I2C/UART bridge chip. When an I2C SMBus read
operation exhausts its 5 retries (meaning the device didn't become
ready), the function `mcp_i2c_smbus_read` previously returned the error
immediately without cleaning up the device's internal state machine.
This left the I2C bus in a stuck state, causing subsequent I2C
transactions to fail.

The fix adds two lines before the error return:
1. `usleep_range(980, 1000)` - a small delay needed by the device
2. `mcp_cancel_last_cmd(mcp)` - sends a cancel command to reset the
   device state and free the I2C bus

### Is this a real bug fix?

Yes. The commit message explicitly states this fixes a real-world issue:
`i2cdetect` was unable to detect all devices on the bus. This is a
functional bug where failed reads leave the MCP2221 in a bad state,
breaking subsequent operations.

### Pattern consistency

The fix follows the **exact same pattern** already used in two other
places in the same driver:
1. `mcp_chk_last_cmd_status_free_bus()` (line 225-226):
   `usleep_range(980, 1000)` + `mcp_cancel_last_cmd(mcp)` on error
2. `mcp_set_i2c_speed()` (line 244-245): same pattern on error

This is simply adding the same established error recovery to a path that
was missing it.

### Scope and risk

- **2 lines added** - extremely small and surgical
- **No behavioral change** on the success path
- Only affects the error path after all 5 retries are exhausted
- Uses well-established functions already present in the driver
- Low risk of regression - the alternative (not cancelling) is already
  broken

### Stable criteria assessment

- **Obviously correct**: Follows the same pattern used elsewhere in the
  driver for the same purpose
- **Fixes a real bug**: I2C bus gets stuck, preventing device detection
- **Small and contained**: 2 lines added, single file, single error path
- **No new features**: Just error recovery

### Verification

- git log confirmed this is commit b4664742e46dc, merged recently
- Read the full `mcp_cancel_last_cmd()` function at line 204-211: sends
  `MCP2221_I2C_CANCEL` to reset device state
- Read `mcp_chk_last_cmd_status_free_bus()` at line 216-230: confirms
  the same `usleep + cancel` pattern is established
- Read `mcp_set_i2c_speed()` at line 232-249: confirms the same pattern
  in a third location
- The fix is self-contained with no dependencies on other commits
- The `mcp_cancel_last_cmd` function has existed since at least v6.1
  (introduced with the read refactoring), so it's available in stable
  trees
- Author is from Microchip (the chip vendor), adding credibility to the
  fix

**YES**

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

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 33603b019f975..ef3b5c77c38e3 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -353,6 +353,8 @@ static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 				usleep_range(90, 100);
 				retries++;
 			} else {
+				usleep_range(980, 1000);
+				mcp_cancel_last_cmd(mcp);
 				return ret;
 			}
 		} else {
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] HID: asus: avoid memory leak in asus_report_fixup()

[Sasha Levin]

From: Günther Noack <gnoack@google.com>

[ Upstream commit 2bad24c17742fc88973d6aea526ce1353f5334a3 ]

The asus_report_fixup() function was returning a newly allocated
kmemdup()-allocated buffer, but never freeing it.  Switch to
devm_kzalloc() to ensure the memory is managed and freed automatically
when the device is removed.

The caller of report_fixup() does not take ownership of the returned
pointer, but it is permitted to return a pointer whose lifetime is at
least that of the input buffer.

Also fix a harmless out-of-bounds read by copying only the original
descriptor size.

Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.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

### Problem Description

The `asus_report_fixup()` function in `drivers/hid/hid-asus.c` had a
memory leak in the `QUIRK_T100CHI | QUIRK_T90CHI` path. The buggy code
used `kmemdup()` to allocate a new report descriptor buffer, but this
buffer was never freed by anyone:

**The leak mechanism (verified by reading hid-core.c:1285-1307):**
1. Caller allocates `buf` via `kmemdup()` (line 1291)
2. Caller passes `buf` to `report_fixup()` (line 1296)
3. The old `report_fixup()` returned a *new* `kmemdup()`'d pointer,
   discarding `buf`
4. Caller does `start = kmemdup(start, size, ...)` — making *yet another
   copy* (line 1303)
5. Caller does `kfree(buf)` — frees the original, but NOT the
   intermediate kmemdup from report_fixup()
6. The intermediate buffer is **leaked**

### Fix Analysis

The fix is small (11 insertions, 4 deletions) and does three things:

1. **Switches from `kmemdup()` to `devm_kzalloc()`**: Ties the
   allocation to the HID device lifetime, so it's automatically freed on
   device removal. This eliminates the leak.

2. **Fixes error handling**: Old code returned `NULL` on allocation
   failure, which the caller doesn't handle well. New code returns the
   original `rdesc`, matching the pattern already used by
   `QUIRK_G752_KEYBOARD` in the same function.

3. **Fixes out-of-bounds read**: Old code did `kmemdup(rdesc, *rsize,
   ...)` where `*rsize` was already set to `rsize_orig + 1` (one byte
   larger than the actual descriptor). New code does `memcpy(new_rdesc,
   rdesc, rsize_orig)`, copying only the valid data.

### Stable Criteria Assessment

- **Fixes a real bug**: Yes — memory leak on every T100CHI/T90CHI
  keyboard report descriptor parse
- **Obviously correct**: Yes — follows the identical pattern used by
  QUIRK_G752_KEYBOARD in the same function (verified in the diff
  context)
- **Small and contained**: Yes — 15 lines changed in a single file
- **No new features**: Correct — pure bug fix
- **Bug has existed since 2017**: Commit 73c75d3958579 introduced
  T100CHI support with the buggy `kmemdup()` pattern, present in all
  stable trees

### Risk Assessment

**Very low risk.** The fix:
- Follows an existing pattern already proven in the same function
  (QUIRK_G752_KEYBOARD)
- Only affects ASUS T100CHI and T90CHI hardware
- The devm_kzalloc lifetime (device lifetime) is correct since the
  caller copies the returned data immediately
- No dependencies on other commits

### Verification

- **Verified caller behavior**: Read `hid-core.c:1285-1307` — confirmed
  the caller does `kmemdup()` of the returned pointer then `kfree(buf)`,
  meaning any new allocation from `report_fixup()` is leaked
- **Verified the existing devm_kzalloc pattern**: The
  QUIRK_G752_KEYBOARD block in the same function already uses
  `devm_kzalloc` with the same allocation + `return rdesc` on failure
  pattern
- **Verified bug age**: `git log --oneline` showed commit
  `73c75d3958579` (2017-08-04) introduced the T100CHI support with
  `kmemdup()`, confirmed present in stable trees via `git tag
  --contains`
- **Verified commit SHA**: `git show 5dc6c17c16935` confirmed the commit
  matches the diff under review, with upstream commit `2bad24c17742f`
- **Verified the OOB read**: Old code set `*rsize = rsize_orig + 1`
  BEFORE `kmemdup(rdesc, *rsize, ...)`, reading one byte past the
  original descriptor — confirmed by the diff context showing the order
  of operations

This is a clear, small, low-risk fix for a real memory leak (and minor
OOB read) in a HID driver, following an established pattern already in
the same function. It meets all stable kernel criteria.

**YES**

 drivers/hid/hid-asus.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 472bca54642b9..8487332bf43b0 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1306,14 +1306,21 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		 */
 		if (*rsize == rsize_orig &&
 			rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
-			*rsize = rsize_orig + 1;
-			rdesc = kmemdup(rdesc, *rsize, GFP_KERNEL);
-			if (!rdesc)
-				return NULL;
+			__u8 *new_rdesc;
+
+			new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
+						 GFP_KERNEL);
+			if (!new_rdesc)
+				return rdesc;
 
 			hid_info(hdev, "Fixing up %s keyb report descriptor\n",
 				drvdata->quirks & QUIRK_T100CHI ?
 				"T100CHI" : "T90CHI");
+
+			memcpy(new_rdesc, rdesc, rsize_orig);
+			*rsize = rsize_orig + 1;
+			rdesc = new_rdesc;
+
 			memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
 			rdesc[offs] = 0x19;
 			rdesc[offs + 1] = 0x00;
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.10] platform/x86: touchscreen_dmi: Add quirk for y-inverted Goodix touchscreen on SUPI S10

[Sasha Levin]

From: Hans de Goede <johannes.goede@oss.qualcomm.com>

[ Upstream commit 7d87ed70fc95482c12edf9493c249b6413be485e ]

The touchscreen on the SUPI S10 tablet reports inverted Y coordinates,
causing touch input to be mirrored vertically relative to the display.

Add a quirk to set the "touchscreen-inverted-y" boolean device-property
on the touchscreen device, so that the goodix_ts driver will fixup
the coordinates.

Reported-by: Yajat Kumar <yajatapps3@gmail.com>
Closes: https://lore.kernel.org/linux-input/20251230221639.582406-1-yajatapps3@gmail.com/
Tested-by: Yajat Kumar <yajatapps3@gmail.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260217132346.34535-1-johannes.goede@oss.qualcomm.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### What the commit does
This adds a DMI-based touchscreen quirk for the SUPI S10 tablet. The
tablet's Goodix touchscreen (GDIX1001) reports inverted Y coordinates,
causing touch input to be vertically mirrored. The fix adds:

1. A new property entry array `gdix1001_y_inverted_props[]` with
   `touchscreen-inverted-y`
2. A corresponding `ts_dmi_data` struct pointing to ACPI name "GDIX1001"
3. A DMI table entry matching vendor "SUPI", product "S10"

### Stable kernel criteria assessment

**Fixes a real bug:** Yes. Without this quirk, touch input is vertically
mirrored on this tablet, making it essentially unusable for touch
interaction.

**Hardware quirk exception:** This is a textbook DMI-based hardware
quirk — exactly the type explicitly listed as appropriate for stable
backporting. The `touchscreen_dmi.c` file exists solely for these
entries; it has hundreds of similar quirks already.

**Small and contained:** Yes. ~18 lines added to a single file,
following the exact same pattern as every other entry in the file.

**Risk of regression:** Extremely low. The DMI matching
(`DMI_SYS_VENDOR: "SUPI"`, `DMI_PRODUCT_NAME: "S10"`) ensures this code
only activates on the specific affected tablet. No other hardware is
impacted.

**Tested and reviewed:** Yes. Has both `Tested-by: Yajat Kumar` (the
reporter/user) and `Reviewed-by: Ilpo Järvinen` (Intel maintainer). The
commit author Hans de Goede is the well-known x86 platform maintainer
who handles most touchscreen quirks.

**No new features:** Correct. This uses existing infrastructure
(`ts_dmi_data`, `property_entry`, `dmi_system_id` matching) to fix a
specific device.

**Dependencies:** None. The `touchscreen_dmi.c` framework and the Goodix
driver's handling of `touchscreen-inverted-y` have been present for many
kernel versions.

### Verification
- The commit follows the identical pattern used by all other entries in
  `touchscreen_dmi.c` — no novel code patterns
- The `gdix1001_y_inverted_props` is a subset of the existing
  `gdix1001_upside_down_props` (which sets both inverted-x and
  inverted-y), confirming this is a well-established mechanism
- Reporter and tester are the same person (Yajat Kumar), confirming the
  fix resolves the reported issue
- The author (Hans de Goede) is the primary maintainer for x86
  touchscreen quirks
- The `Closes:` link to lore.kernel.org confirms a real user report from
  December 2025

### Risk vs benefit
- **Benefit:** Makes touchscreen usable on SUPI S10 tablets — critical
  for those users
- **Risk:** Near zero — DMI-scoped to one specific device model, uses
  existing well-tested infrastructure

**YES**

 drivers/platform/x86/touchscreen_dmi.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index bdc19cd8d3edf..d83c387821ea1 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -410,6 +410,16 @@ static const struct ts_dmi_data gdix1002_upside_down_data = {
 	.properties	= gdix1001_upside_down_props,
 };
 
+static const struct property_entry gdix1001_y_inverted_props[] = {
+	PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+	{ }
+};
+
+static const struct ts_dmi_data gdix1001_y_inverted_data = {
+	.acpi_name	= "GDIX1001",
+	.properties	= gdix1001_y_inverted_props,
+};
+
 static const struct property_entry gp_electronic_t701_props[] = {
 	PROPERTY_ENTRY_U32("touchscreen-size-x", 960),
 	PROPERTY_ENTRY_U32("touchscreen-size-y", 640),
@@ -1658,6 +1668,14 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
 			DMI_MATCH(DMI_PRODUCT_SKU, "PN20170413488"),
 		},
 	},
+	{
+		/* SUPI S10 */
+		.driver_data = (void *)&gdix1001_y_inverted_data,
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "SUPI"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "S10"),
+		},
+	},
 	{
 		/* Techbite Arc 11.6 */
 		.driver_data = (void *)&techbite_arc_11_6_data,
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.1] HID: apple: avoid memory leak in apple_report_fixup()

[Sasha Levin]

From: Günther Noack <gnoack@google.com>

[ Upstream commit 239c15116d80f67d32f00acc34575f1a6b699613 ]

The apple_report_fixup() function was returning a
newly kmemdup()-allocated buffer, but never freeing it.

The caller of report_fixup() does not take ownership of the returned
pointer, but it *is* permitted to return a sub-portion of the input
rdesc, whose lifetime is managed by the caller.

Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is very revealing. The caller's flow is:

1. `buf = kmemdup(start, size, ...)` — makes a copy of rdesc
2. `start = device->driver->report_fixup(device, buf, &size)` — calls
   the fixup, passing `buf`
3. `start = kmemdup(start, size, ...)` — copies whatever `report_fixup`
   returned
4. `kfree(buf)` — frees the original buf

**The old buggy code**: `apple_report_fixup` did `rdesc = kmemdup(rdesc
+ 1, ...)` which allocated a NEW buffer and returned it. The caller then
does `kmemdup(start, size)` (copies it again) and `kfree(buf)` (frees
the ORIGINAL `buf`). But the intermediate buffer allocated by
`apple_report_fixup` is never freed — leaked.

**The fix**: Instead of `kmemdup(rdesc + 1, ...)`, just do `rdesc =
rdesc + 1`. This returns a pointer into the caller's `buf`, which the
caller will properly copy and then free.

This is safe because:
- The caller already makes a copy of whatever is returned
  (`kmemdup(start, size)`)
- The caller then frees `buf`
- Since `rdesc + 1` points into `buf`, it's valid until `kfree(buf)`
  which happens AFTER the copy

## Analysis

**What problem the commit solves**: Every time `apple_report_fixup()` is
called for a Magic Keyboard with the `APPLE_RDESC_BATTERY` quirk, a
`kmemdup()` allocation leaks memory. This happens at device probe time,
so each time a Magic Keyboard is connected (or the driver is reloaded),
memory is leaked.

**Meets stable kernel rules**:
1. **Obviously correct and tested** — Yes, the fix simply changes
   `kmemdup(rdesc + 1, ...)` to `rdesc + 1`. The caller already copies
   the returned buffer, so the intermediate allocation was unnecessary.
2. **Fixes a real bug** — Yes, a real memory leak.
3. **Important issue** — Memory leak that occurs on every device probe
   for affected Apple Magic Keyboards. While not a crash, it's a
   persistent resource leak.
4. **Small and contained** — Yes, a 3-line change (removes kmemdup +
   error check, replaces with pointer arithmetic).
5. **No new features** — Correct, pure bug fix.

**Risk vs benefit**: Very low risk. The change simplifies the code by
removing an allocation. The caller's code in `hid-core.c` explicitly
handles this case (comment says "report_fixup() returns a sub-portion of
the input rdesc"). Benefit is fixing a real memory leak affecting Apple
keyboard users.

**Affected versions**: The buggy code was introduced in commit
`6e143293e17a7` which first appeared in v5.17-rc1. All stable trees from
5.17+ are affected (6.1.y, 6.6.y, 6.12.y, etc.).

**Dependencies**: None. The fix is self-contained and applies cleanly.

## Verification

- `git show 6e143293e17a7` confirmed this is the commit that introduced
  the buggy `kmemdup` call in `apple_report_fixup()`, first appearing in
  v5.17-rc1
- Read `hid-core.c:1285-1304` confirmed the caller does NOT take
  ownership of the returned pointer — it copies it with `kmemdup(start,
  size)` and then frees `buf`, meaning any separate allocation by
  `report_fixup` is leaked
- The caller's comment at line 1298-1301 explicitly states
  "report_fixup() returns a static read-only memory... we have no idea
  if that memory needs to be cleaned up" — confirming the caller cannot
  and does not free the report_fixup return value
- Read the fixed code at `hid-apple.c:691-692` confirming `rdesc = rdesc
  + 1` correctly returns a sub-portion of the input buffer, which the
  caller handles properly
- The fix removes 3 lines and adds 1 line — minimal change with clear
  semantics

**YES**

 drivers/hid/hid-apple.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 2f9a2e07c4263..9dcb252c5d6c7 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -689,9 +689,7 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		hid_info(hdev,
 			 "fixing up Magic Keyboard battery report descriptor\n");
 		*rsize = *rsize - 1;
-		rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
-		if (!rdesc)
-			return NULL;
+		rdesc = rdesc + 1;
 
 		rdesc[0] = 0x05;
 		rdesc[1] = 0x01;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 7c698de0dc5daa1e1a5fd1f0c6aa1b6bb2f5d867 ]

EPOMAKER TH87 has the very same ID as Apple Aluminum keyboard
(05ac:024f) although it doesn't work as expected in compatible way.

Put three entries to the non-apple keyboards list to exclude this
device: one for BT ("TH87"), one for USB ("HFD Epomaker TH87") and one
for dongle ("2.4G Wireless Receiver").

Link: https://bugzilla.suse.com/show_bug.cgi?id=1258455
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The patch just adds three string entries to the array. The only concern
is whether the exact context (previous entries) exists in stable trees,
but since this is just appending to an array, even if some intermediate
entries are missing, the patch can be trivially adjusted.

### Problem Being Fixed

The EPOMAKER TH87 keyboard uses the same USB vendor/product ID as Apple
Aluminum keyboards (05ac:024f). Without this fix, the hid-apple driver
applies Apple-specific key translation logic to this non-Apple keyboard,
causing it to not work as expected. The bug is tracked in SUSE's
bugzilla (bsc#1258455), confirming it affects real users.

### Stable Kernel Rules Assessment

1. **Obviously correct and tested**: Yes - trivial addition of string
   entries to a quirk list. Same pattern used for 10+ other keyboards.
   Comes from SUSE maintainer (Takashi Iwai).
2. **Fixes a real bug**: Yes - keyboard doesn't work correctly without
   this fix.
3. **Important issue**: Yes - keyboard malfunction for affected users
   (wrong key mappings).
4. **Small and contained**: Yes - adds 3 lines to a static array, zero
   logic changes.
5. **No new features/APIs**: Correct - uses existing infrastructure.
6. **Applies cleanly**: Should apply with trivial context adjustment if
   intermediate entries are missing.

### Risk Assessment

**Risk: Extremely low.** The change only adds entries to a name-matching
list. The matching uses `strncmp` prefix matching. The entries are
specific enough ("TH87", "HFD Epomaker TH87", "2.4G Wireless Receiver")
to only match intended devices. One concern: "2.4G Wireless Receiver" is
a somewhat generic name and could match other devices' dongles, but the
effect of matching (setting `APPLE_IS_NON_APPLE` flag which changes
fnmode default) is benign for actual non-Apple keyboards.

### Verification

- **Verified** `non_apple_keyboards` infrastructure was introduced in
  commit `a0a05054583fe` (v6.0-rc1), present in all current stable trees
  (6.1.y+).
- **Verified** the commit adds only 3 string entries to the static
  `non_apple_keyboards[]` array at line 368-370.
- **Verified** `apple_is_non_apple_keyboard()` uses `strncmp` prefix
  matching at line 380.
- **Verified** the effect of matching is setting `APPLE_IS_NON_APPLE`
  quirk bit at line 770, which changes function key behavior default.
- **Verified** the bug is tracked at
  `https://bugzilla.suse.com/show_bug.cgi?id=1258455` (referenced in
  Link: tag).
- **Verified** this follows the exact same pattern as 7+ previous non-
  apple keyboard additions (GANSS, Hailuck, Jamesdonkey, A3R, hfd.cn,
  WKB603, SONiX AK870 PRO, SONiX KN85).
- **Verified** author is Takashi Iwai (tiwai@suse.de), a senior SUSE
  kernel maintainer.

### Conclusion

This is a textbook hardware quirk addition. It adds device
identification entries to an existing mechanism, fixing a real-world
keyboard malfunction reported by users (with bugzilla link). The change
is trivial (3 lines of string data), zero risk to existing
functionality, and follows an established pattern used by many other
entries. It clearly meets all stable kernel criteria.

**YES**

 drivers/hid/hid-apple.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 233e367cce1d1..2f9a2e07c4263 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -365,6 +365,9 @@ static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
 	{ "A3R" },
 	{ "hfd.cn" },
 	{ "WKB603" },
+	{ "TH87" },			/* EPOMAKER TH87 BT mode */
+	{ "HFD Epomaker TH87" },	/* EPOMAKER TH87 USB mode */
+	{ "2.4G Wireless Receiver" },	/* EPOMAKER TH87 dongle */
 };
 
 static bool apple_is_non_apple_keyboard(struct hid_device *hdev)
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2

[Sasha Levin]

From: Julius Lehmann <lehmanju@devpi.de>

[ Upstream commit 5f3518d77419255f8b12bb23c8ec22acbeb6bc5b ]

Battery reporting does not work for the Apple Magic Trackpad 2 if it is
connected via USB. The current hid descriptor fixup code checks for a
hid descriptor length of exactly 83 bytes. If the hid descriptor is
larger, which is the case for newer apple mice, the fixup is not
applied.

This fix checks for hid descriptor sizes greater/equal 83 bytes which
applies the fixup for newer devices as well.

Signed-off-by: Julius Lehmann <lehmanju@devpi.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Problem
Battery reporting doesn't work for Apple Magic Trackpad 2 when connected
via USB if the HID descriptor is larger than exactly 83 bytes. Newer
Apple devices have expanded HID descriptors, so the original strict
equality check (`*rsize == 83`) causes the battery report fixup to be
silently skipped.

### The Fix
A single-character change: `*rsize == 83` becomes `*rsize >= 83`. This
allows the descriptor fixup to apply for newer devices with larger
descriptors.

### Safety Analysis
The fix is safe because:
1. The `>= 83` check still guarantees the descriptor is at least 83
   bytes, so accessing `rdesc[46]` and `rdesc[58]` is within bounds.
2. The additional content checks (`rdesc[46] == 0x84 && rdesc[58] ==
   0x85`) still validate the descriptor format before applying any
   modification.
3. The device type is still checked (`is_usb_magicmouse2` or
   `is_usb_magictrackpad2`), so unrelated devices are unaffected.

### Stable Criteria Assessment
- **Fixes a real bug**: Yes — battery reporting completely broken for
  newer Apple trackpad/mouse devices over USB.
- **Obviously correct**: Yes — the original check was overly
  restrictive; the `>=` check is the natural fix while maintaining
  safety through the other validation checks.
- **Small and contained**: Yes — single character change in one file,
  one driver.
- **No new features**: Correct — just enables existing battery reporting
  functionality for devices it should already work with.
- **Low regression risk**: Very low — only affects Apple Magic Mouse 2 /
  Magic Trackpad 2 USB devices, and the content validation guards
  against incorrect application.

### User Impact
Apple Magic Mouse 2 and Magic Trackpad 2 are widely used peripherals.
Users connecting via USB (e.g., for charging) lose battery level
reporting without this fix. This affects real hardware that many people
use daily.

### Verification
- `git blame` confirmed the original `*rsize == 83` check was introduced
  in commit `0b91b4e4dae63` ("HID: magicmouse: Report battery level over
  USB", Nov 2021), so the bug has existed since then.
- Read the surrounding code (lines 973-1006) to confirm the `rdesc[46]`
  and `rdesc[58]` access is safe with `>= 83` guard.
- `git log --grep` confirmed multiple battery-related fixes to this
  driver, indicating ongoing maintenance and real user interest.
- The device checks (`is_usb_magicmouse2`, `is_usb_magictrackpad2`)
  limit scope to specific Apple products only.
- The fix is self-contained with no dependencies on other commits.

**YES**

 drivers/hid/hid-magicmouse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index 91f621ceb924b..f4cf29c2e8330 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -990,7 +990,7 @@ static const __u8 *magicmouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 	 */
 	if ((is_usb_magicmouse2(hdev->vendor, hdev->product) ||
 	     is_usb_magictrackpad2(hdev->vendor, hdev->product)) &&
-	    *rsize == 83 && rdesc[46] == 0x84 && rdesc[58] == 0x85) {
+	    *rsize >= 83 && rdesc[46] == 0x84 && rdesc[58] == 0x85) {
 		hid_info(hdev,
 			 "fixing up magicmouse battery report descriptor\n");
 		*rsize = *rsize - 1;
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] HID: intel-ish-hid: ipc: Add Nova Lake-H/S PCI device IDs

[Sasha Levin]

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

[ Upstream commit 22f8bcec5aeb05104b3eaa950cb5a345e95f0aa8 ]

Add device IDs of Nova Lake-H and Nova Lake-S into ishtp support list.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.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:

## Analysis: HID: intel-ish-hid: ipc: Add Nova Lake-H/S PCI device IDs

### What the commit does

This commit adds PCI device IDs for two new Intel platforms (Nova Lake-H
and Nova Lake-S) to the existing `intel-ish-hid` driver. The changes
are:

1. Two new `#define` entries for PCI device IDs (`0xD354` for NVL_H,
   `0x6E78` for NVL_S) in `hw-ish.h`
2. Two new enum values, firmware generation string macros, driver data
   entries, and PCI ID table entries in `pci-ish.c`

### Classification: New Device IDs to Existing Driver

This falls squarely into the **"NEW DEVICE IDs"** exception category,
which is explicitly listed as appropriate for stable backports:

> Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers. These are
trivial additions that enable hardware support. The driver must already
exist in stable; only the ID is new.

The `intel-ish-hid` driver has been in the kernel for many years, with a
long list of existing Intel platform IDs (CHV, BXT, APL, SPT, CNL, GLK,
ICL, CML, CMP, EHL, TGL, ADL, RPL, MTL, ARL, LNL, PTL, WCL).

### Stable Criteria Assessment

- **Obviously correct**: Yes - follows the exact same pattern as all
  prior device ID additions (PTL, WCL, LNL, etc.)
- **Fixes a real bug**: Enables hardware that would otherwise be non-
  functional on Nova Lake platforms
- **Small and contained**: Yes - only touches two files, adds ~12 lines
  following an established pattern
- **No new features/APIs**: Correct - just enables existing driver on
  new hardware
- **Risk**: Extremely low - the new IDs only match new hardware;
  existing hardware is completely unaffected

### Review Quality

- **Reviewed-by**: Andy Shevchenko (Intel, prolific kernel reviewer)
- **Acked-by**: Srinivas Pandruvada (Intel ISH subsystem maintainer)
- **Signed-off-by**: Jiri Kosina (HID maintainer)

This has full maintainer sign-off chain.

### Risk Assessment

The risk is essentially zero. The new PCI device IDs (`0xD354`,
`0x6E78`) will only match on Nova Lake hardware. No existing systems are
affected. The code pattern is identical to the most recent additions
(WCL, PTL) which themselves followed the same pattern.

### Verification

- Verified the diff adds only PCI device ID definitions, enum values,
  firmware generation strings, driver data entries, and PCI table
  entries - no behavioral changes to existing code
- Verified the pattern matches prior additions (e.g., WCL added in the
  same manner with `ISHTP_DRIVER_DATA_WCL`, `ISH_FW_GEN_WCL`, etc.)
- Verified the driver (`intel-ish-hid`) has existed in the kernel for
  many years with 20+ existing platform IDs
- Verified no code logic changes - purely data additions
- The commit has proper review chain (Reviewed-by, Acked-by from
  subsystem maintainer, Signed-off-by from HID maintainer)

### Conclusion

This is a textbook device ID addition to an existing, well-established
driver. It enables Intel ISH (sensor hub) functionality on Nova Lake-H
and Nova Lake-S platforms. Without this, users with Nova Lake hardware
would have non-functional sensor hubs. The change is trivially safe,
well-reviewed, and follows an established pattern.

**YES**

 drivers/hid/intel-ish-hid/ipc/hw-ish.h  |  2 ++
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 12 ++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
index fa5d68c363134..27389971b96cc 100644
--- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
+++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
@@ -39,6 +39,8 @@
 #define PCI_DEVICE_ID_INTEL_ISH_PTL_H		0xE345
 #define PCI_DEVICE_ID_INTEL_ISH_PTL_P		0xE445
 #define PCI_DEVICE_ID_INTEL_ISH_WCL		0x4D45
+#define PCI_DEVICE_ID_INTEL_ISH_NVL_H		0xD354
+#define PCI_DEVICE_ID_INTEL_ISH_NVL_S		0x6E78
 
 #define	REVISION_ID_CHT_A0	0x6
 #define	REVISION_ID_CHT_Ax_SI	0x0
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 1612e8cb23f0c..ed3405c05e73c 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -28,11 +28,15 @@ enum ishtp_driver_data_index {
 	ISHTP_DRIVER_DATA_LNL_M,
 	ISHTP_DRIVER_DATA_PTL,
 	ISHTP_DRIVER_DATA_WCL,
+	ISHTP_DRIVER_DATA_NVL_H,
+	ISHTP_DRIVER_DATA_NVL_S,
 };
 
 #define ISH_FW_GEN_LNL_M "lnlm"
 #define ISH_FW_GEN_PTL "ptl"
 #define ISH_FW_GEN_WCL "wcl"
+#define ISH_FW_GEN_NVL_H "nvlh"
+#define ISH_FW_GEN_NVL_S "nvls"
 
 #define ISH_FIRMWARE_PATH(gen) "intel/ish/ish_" gen ".bin"
 #define ISH_FIRMWARE_PATH_ALL "intel/ish/ish_*.bin"
@@ -47,6 +51,12 @@ static struct ishtp_driver_data ishtp_driver_data[] = {
 	[ISHTP_DRIVER_DATA_WCL] = {
 		.fw_generation = ISH_FW_GEN_WCL,
 	},
+	[ISHTP_DRIVER_DATA_NVL_H] = {
+		.fw_generation = ISH_FW_GEN_NVL_H,
+	},
+	[ISHTP_DRIVER_DATA_NVL_S] = {
+		.fw_generation = ISH_FW_GEN_NVL_S,
+	},
 };
 
 static const struct pci_device_id ish_pci_tbl[] = {
@@ -76,6 +86,8 @@ static const struct pci_device_id ish_pci_tbl[] = {
 	{PCI_DEVICE_DATA(INTEL, ISH_PTL_H, ISHTP_DRIVER_DATA_PTL)},
 	{PCI_DEVICE_DATA(INTEL, ISH_PTL_P, ISHTP_DRIVER_DATA_PTL)},
 	{PCI_DEVICE_DATA(INTEL, ISH_WCL, ISHTP_DRIVER_DATA_WCL)},
+	{PCI_DEVICE_DATA(INTEL, ISH_NVL_H, ISHTP_DRIVER_DATA_NVL_H)},
+	{PCI_DEVICE_DATA(INTEL, ISH_NVL_S, ISHTP_DRIVER_DATA_NVL_S)},
 	{}
 };
 MODULE_DEVICE_TABLE(pci, ish_pci_tbl);
-- 
2.51.0

[PATCH AUTOSEL 6.19-5.15] HID: magicmouse: avoid memory leak in magicmouse_report_fixup()

[Sasha Levin]

From: Günther Noack <gnoack@google.com>

[ Upstream commit 91e8c6e601bdc1ccdf886479b6513c01c7e51c2c ]

The magicmouse_report_fixup() function was returning a
newly kmemdup()-allocated buffer, but never freeing it.

The caller of report_fixup() does not take ownership of the returned
pointer, but it *is* permitted to return a sub-portion of the input
rdesc, whose lifetime is managed by the caller.

Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack <gnoack@google.com>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis.

## Analysis

### What the commit fixes

The `magicmouse_report_fixup()` function was introduced in commit
`0b91b4e4dae63` (v5.16 era, 2021) and uses `kmemdup(rdesc + 1, *rsize,
GFP_KERNEL)` to create a new buffer. The caller in `hid_open_report()`
(hid-core.c) does **not** free the returned pointer — it immediately
`kmemdup()`s the result again and frees its own copy. So the buffer
allocated by magicmouse was leaked every time the device was
initialized.

The fix replaces `kmemdup(rdesc + 1, ...)` with simply `rdesc + 1`,
returning a sub-portion of the input buffer. This is explicitly
permitted by the `report_fixup()` contract as documented in
`include/linux/hid.h` (lines 839-843), and is safe because
`hid_open_report()` immediately copies the returned data.

### Stable kernel criteria assessment

1. **Fixes a real bug**: Yes — memory leak on every device probe for
   Apple Magic Mouse 2 and Magic Trackpad 2 connected via USB.
2. **Obviously correct**: Yes — the HID core immediately `kmemdup()`s
   the return value, so returning a pointer into the caller's buffer is
   safe. The documentation explicitly says "a sub-portion of it" is
   valid.
3. **Small and contained**: Yes — removes 3 lines (kmemdup + NULL
   check), changes one line. Single file, single function.
4. **No new features**: Correct — pure bug fix.
5. **Low risk**: Very low — the change is simpler than the original
   code. Removes an allocation that was never needed.

### User impact

This affects all users of Apple Magic Mouse 2 and Magic Trackpad 2 over
USB. Each time the device is probed (e.g., plugged in, resumed), ~82
bytes are leaked. While not catastrophic per-event, it's a real resource
leak that accumulates.

### Risk assessment

Minimal risk. The fix makes the code simpler and removes a dynamic
allocation. The HID core's defensive `kmemdup()` of the returned pointer
ensures the approach is safe.

### Dependency check

The buggy `kmemdup()` was introduced in commit `0b91b4e4dae63` ("HID:
magicmouse: Report battery level over USB"), which was in v5.16. This
code exists in all current stable trees (6.1.y, 6.6.y, 6.12.y). The fix
is self-contained with no dependencies on other commits.

### Verification

- **git show 0b91b4e4dae63** confirmed the kmemdup was introduced in the
  original "Report battery level over USB" commit (2021, v5.16 era)
- **hid-core.c hid_open_report()** verified: the caller kmemdup's the
  return value immediately and frees its own buffer — it does NOT take
  ownership of the returned pointer (lines 1285-1307)
- **include/linux/hid.h documentation** (lines 839-843) confirmed:
  returning "a sub-portion of it" is explicitly documented as valid
- **git log --oneline -- drivers/hid/hid-magicmouse.c** confirmed the
  commit under review (`c0993f362e2ef`) is the fix, with no other
  dependencies
- **Commit 225c43c0e9164** (the next commit after) only changes the size
  check from `== 83` to `>= 83` and does not affect the fix's
  applicability

This is a clear, small, self-contained memory leak fix in a widely-used
driver. It meets all stable kernel criteria with minimal risk.

**YES**

 drivers/hid/hid-magicmouse.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index f4cf29c2e8330..9eadf3252d0dc 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -994,9 +994,7 @@ static const __u8 *magicmouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		hid_info(hdev,
 			 "fixing up magicmouse battery report descriptor\n");
 		*rsize = *rsize - 1;
-		rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
-		if (!rdesc)
-			return NULL;
+		rdesc = rdesc + 1;
 
 		rdesc[0] = 0x05;
 		rdesc[1] = 0x01;
-- 
2.51.0