From: Thomas Fourier fourier.thomas@gmail.com
[ Upstream commit c4890963350dcf4e9a909bae23665921fba4ad27 ]
The DMA map functions can fail and should be tested for errors.
Signed-off-by: Thomas Fourier fourier.thomas@gmail.com Reviewed-by: Simon Horman horms@kernel.org Link: https://patch.msgid.link/20250624064148.12815-3-fourier.thomas@gmail.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees.
## Detailed Analysis:
**Nature of the fix:** The commit adds missing error checking for `dma_map_single()` calls in two locations within the idt77252 ATM driver:
1. **In `queue_skb()` function (line 853-854):** ```c IDT77252_PRV_PADDR(skb) = dma_map_single(&card->pcidev->dev, skb->data, skb->len, DMA_TO_DEVICE); +if (dma_mapping_error(&card->pcidev->dev, IDT77252_PRV_PADDR(skb))) + return -ENOMEM; ``` This correctly returns -ENOMEM before reaching the errout label, avoiding any cleanup issues since the DMA mapping never succeeded.
2. **In `add_rx_skb()` function (line 1857-1860):** ```c paddr = dma_map_single(&card->pcidev->dev, skb->data, skb_end_pointer(skb) - skb->data, DMA_FROM_DEVICE); +if (dma_mapping_error(&card->pcidev->dev, paddr)) + goto outpoolrm; ``` This properly jumps to the new `outpoolrm` label which removes the SKB from the pool before freeing it, maintaining correct cleanup order.
**Why this qualifies for stable backporting:**
1. **Fixes a real bug**: Missing DMA mapping error checks can cause system crashes or data corruption, especially on systems with IOMMU or SWIOTLB where DMA mapping failures are more likely.
2. **Simple and contained**: The fix adds only 5 lines of error checking code with no architectural changes.
3. **Similar to approved backports**: This follows the exact same pattern as Similar Commits #1 (eni driver) and #2 (aic94xx driver) which were both marked "YES" for backporting.
4. **Long-standing issue**: The driver has existed since at least 2005 (Linux 2.6.12-rc2), meaning this bug has been present for nearly 20 years.
5. **Minimal regression risk**: The changes only add error checking; they don't modify any existing logic paths.
6. **Proper error handling**: Both error paths are correctly implemented with appropriate cleanup sequences.
The commit clearly meets all stable tree criteria as an important bug fix with minimal risk and should be backported to protect users from potential DMA-related crashes.
drivers/atm/idt77252.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c index 7810f974b2ca9..d9ee20f0048fe 100644 --- a/drivers/atm/idt77252.c +++ b/drivers/atm/idt77252.c @@ -852,6 +852,8 @@ queue_skb(struct idt77252_dev *card, struct vc_map *vc,
IDT77252_PRV_PADDR(skb) = dma_map_single(&card->pcidev->dev, skb->data, skb->len, DMA_TO_DEVICE); + if (dma_mapping_error(&card->pcidev->dev, IDT77252_PRV_PADDR(skb))) + return -ENOMEM;
error = -EINVAL;
@@ -1857,6 +1859,8 @@ add_rx_skb(struct idt77252_dev *card, int queue, paddr = dma_map_single(&card->pcidev->dev, skb->data, skb_end_pointer(skb) - skb->data, DMA_FROM_DEVICE); + if (dma_mapping_error(&card->pcidev->dev, paddr)) + goto outpoolrm; IDT77252_PRV_PADDR(skb) = paddr;
if (push_rx_skb(card, skb, queue)) { @@ -1871,6 +1875,7 @@ add_rx_skb(struct idt77252_dev *card, int queue, dma_unmap_single(&card->pcidev->dev, IDT77252_PRV_PADDR(skb), skb_end_pointer(skb) - skb->data, DMA_FROM_DEVICE);
+outpoolrm: handle = IDT77252_PRV_POOL(skb); card->sbpool[POOL_QUEUE(handle)].skb[POOL_INDEX(handle)] = NULL;
From: Tiwei Bie tiwei.btw@antgroup.com
[ Upstream commit 2d65fc13be85c336c56af7077f08ccd3a3a15a4a ]
When compiling with clang (19.1.7), initializing *vp using a compound literal may result in excessive stack usage. Fix it by initializing the required fields of *vp individually.
Without this patch:
$ objdump -d arch/um/drivers/vector_kern.o | ./scripts/checkstack.pl x86_64 0 ... 0x0000000000000540 vector_eth_configure [vector_kern.o]:1472 ...
With this patch:
$ objdump -d arch/um/drivers/vector_kern.o | ./scripts/checkstack.pl x86_64 0 ... 0x0000000000000540 vector_eth_configure [vector_kern.o]:208 ...
Reported-by: kernel test robot lkp@intel.com Closes: https://lore.kernel.org/oe-kbuild-all/202506221017.WtB7Usua-lkp@intel.com/ Signed-off-by: Tiwei Bie tiwei.btw@antgroup.com Link: https://patch.msgid.link/20250623110829.314864-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Fixes a real bug**: The commit addresses excessive stack usage (1472 bytes) that can lead to stack overflow, especially problematic on systems with limited kernel stack space. This is a legitimate bug that affects system stability.
2. **Compiler-specific issue with real impact**: While triggered by clang 19.1.7's handling of compound literals, the resulting stack usage of 1472 bytes is genuinely excessive and dangerous regardless of the compiler quirk that exposed it.
3. **Simple and safe fix**: The change is purely mechanical - converting from compound literal initialization to field-by-field initialization: ```c // From: *vp = ((struct vector_private) { .field = value, ... }); // To: vp->field = value; ```
4. **Minimal risk**: The fix doesn't change any logic or functionality. It only changes how the structure is initialized, making it extremely unlikely to introduce regressions.
5. **Precedent from similar commits**: Looking at the historical commits marked "YES" for backporting: - Similar Commit #1: Reduced stack frame in qed driver using `noinline_for_stack` - Similar Commit #4: Reduced stack usage in ethtool with clang using `noinline_for_stack`
Both addressed the same class of problem (excessive stack usage with clang) and were considered suitable for stable.
6. **Measurable improvement**: The stack usage reduction from 1472 to 208 bytes is dramatic and well-documented by the kernel test robot, providing clear evidence of the fix's effectiveness.
The commit meets the stable kernel criteria of fixing an important bug with minimal risk and a contained change. While it doesn't explicitly include a "Cc: stable" tag, the nature of the fix (preventing potential stack overflow) makes it a good candidate for stable backporting.
arch/um/drivers/vector_kern.c | 42 +++++++++++------------------------ 1 file changed, 13 insertions(+), 29 deletions(-)
diff --git a/arch/um/drivers/vector_kern.c b/arch/um/drivers/vector_kern.c index 2baa8d4a33ed3..1a068859a4185 100644 --- a/arch/um/drivers/vector_kern.c +++ b/arch/um/drivers/vector_kern.c @@ -1600,35 +1600,19 @@ static void vector_eth_configure(
device->dev = dev;
- *vp = ((struct vector_private) - { - .list = LIST_HEAD_INIT(vp->list), - .dev = dev, - .unit = n, - .options = get_transport_options(def), - .rx_irq = 0, - .tx_irq = 0, - .parsed = def, - .max_packet = get_mtu(def) + ETH_HEADER_OTHER, - /* TODO - we need to calculate headroom so that ip header - * is 16 byte aligned all the time - */ - .headroom = get_headroom(def), - .form_header = NULL, - .verify_header = NULL, - .header_rxbuffer = NULL, - .header_txbuffer = NULL, - .header_size = 0, - .rx_header_size = 0, - .rexmit_scheduled = false, - .opened = false, - .transport_data = NULL, - .in_write_poll = false, - .coalesce = 2, - .req_size = get_req_size(def), - .in_error = false, - .bpf = NULL - }); + INIT_LIST_HEAD(&vp->list); + vp->dev = dev; + vp->unit = n; + vp->options = get_transport_options(def); + vp->parsed = def; + vp->max_packet = get_mtu(def) + ETH_HEADER_OTHER; + /* + * TODO - we need to calculate headroom so that ip header + * is 16 byte aligned all the time + */ + vp->headroom = get_headroom(def); + vp->coalesce = 2; + vp->req_size = get_req_size(def);
dev->features = dev->hw_features = (NETIF_F_SG | NETIF_F_FRAGLIST); INIT_WORK(&vp->reset_tx, vector_reset_tx);
From: Yuzuru10 yuzuru_10@proton.me
[ Upstream commit 7186b81807b4a08f8bf834b6bdc72d6ed8ba1587 ]
This patch adds DMI-based quirk for the Acer Nitro ANV15-41, allowing the internal microphone to be detected correctly on machines with "RB" as board vendor.
Signed-off-by: Yuzuru yuzuru_10@proton.me Link: https://patch.msgid.link/20250622225754.20856-1-yuzuru_10@proton.me Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Key Points Supporting Backporting:
1. **Device ID Addition**: According to the stable kernel rules in Documentation/process/stable-kernel-rules.rst:15, patches that "add a device ID" are explicitly acceptable for stable backporting. This commit adds a DMI quirk entry which is functionally equivalent to adding a device ID.
2. **Hardware Enablement Fix**: The commit fixes a real hardware issue - the internal microphone on the Acer Nitro ANV15-41 laptop doesn't work without this quirk. This is a concrete bug that affects real users.
3. **Minimal and Safe Change**: The patch adds only 7 lines to the `yc_acp_quirk_table[]` array: ```c + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "RB"), + DMI_MATCH(DMI_PRODUCT_NAME, "Nitro ANV15-41"), + } + }, ```
4. **Follows Established Pattern**: The change follows the exact same pattern as numerous other entries in the DMI quirk table. It's a simple addition to an existing table with no algorithmic changes or risk of regression.
5. **Precedent from Similar Commits**: Looking at the historical commits with similar characteristics: - commit 610010737f74 ("ASoC: amd: yc: Add DMI quirk for Lenovo Ideapad Pro 5 16ARP8") - Backported with Cc: stable - commit c6dce23ec993 ("ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VF") - Backported with Cc: stable - Multiple other similar commits were backported to stable
6. **No Risk of Regression**: The DMI matching is specific to the exact board vendor "RB" and product name "Nitro ANV15-41". This cannot affect any other hardware models.
## Analysis of the Code:
The change is in `sound/soc/amd/yc/acp6x-mach.c`, which is the machine driver for AMD Yellow Carp platform using DMIC (Digital Microphone). The `yc_acp_quirk_table[]` is a DMI (Desktop Management Interface) matching table that identifies specific laptop models that need special handling to enable their internal microphones.
Without this quirk, the AMD audio driver doesn't properly detect or initialize the internal microphone on the affected laptop model, leaving users without functioning audio input.
## Conclusion:
This is a textbook example of a commit suitable for stable backporting - it's a hardware enablement fix that adds a device-specific quirk with zero risk to other systems. The absence of an explicit "Cc: stable@vger.kernel.org" tag in the commit message doesn't disqualify it from backporting; it simply means the author didn't explicitly request it at submission time.
sound/soc/amd/yc/acp6x-mach.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c index d5dc1d48fca94..5be4e620eeba1 100644 --- a/sound/soc/amd/yc/acp6x-mach.c +++ b/sound/soc/amd/yc/acp6x-mach.c @@ -339,6 +339,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "83Q3"), } }, + { + .driver_data = &acp6x_card, + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "RB"), + DMI_MATCH(DMI_PRODUCT_NAME, "Nitro ANV15-41"), + } + }, { .driver_data = &acp6x_card, .matches = {
From: Yasmin Fitzgerald sunoflife1.git@gmail.com
[ Upstream commit 68cc9d3c8e44afe90e43cbbd2960da15c2f31e23 ]
The HP Pavilion Laptop 15-eg100 has Realtek HDA codec ALC287. It needs the ALC287_FIXUP_HP_GPIO_LED quirk to enable the mute LED.
Signed-off-by: Yasmin Fitzgerald sunoflife1.git@gmail.com Link: https://patch.msgid.link/20250621053832.52950-1-sunoflife1.git@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Hardware enablement fix**: The commit adds a single line to the `alc269_fixup_tbl[]` quirk table to enable mute LED functionality on the HP Pavilion Laptop 15-eg100: ```c SND_PCI_QUIRK(0x103c, 0x898a, "HP Pavilion 15-eg100", ALC287_FIXUP_HP_GPIO_LED), ```
2. **Minimal and contained change**: This is a one-line addition that only affects the specific hardware identified by PCI subsystem ID (0x103c, 0x898a). There are no side effects on other systems.
3. **Uses established fixup**: The `ALC287_FIXUP_HP_GPIO_LED` fixup is already well-established in the kernel and used by other HP Pavilion models including: - HP Pavilion 15-eh1xxx (0x103c, 0x88d0) - HP Pavilion Aero Laptop 13-be0xxx (0x103c, 0x8919) - HP Pavilion 14-ec1xxx (0x103c, 0x8a0f)
4. **Fixes user-visible functionality**: Without this quirk, users of the HP Pavilion Laptop 15-eg100 would have a non-functional mute LED, which is an important visual feedback mechanism for audio state.
5. **Consistent with stable backport precedent**: All five similar historical commits that enabled mute LED functionality for HP laptops were backported to stable: - "Enable Mute LED on HP Laptop 14s-fq1xxx" (YES) - "Enable Mute LED on HP Laptop 14-fq0xxx" (YES) - "fix mute led of the HP Pavilion 15-eh1xxx series" (YES) - notably uses the same ALC287_FIXUP_HP_GPIO_LED - "Enable Mute LED on HP Laptop 15s-eq2xxx" (YES) - "Enable Mute LED on HP 255 G8" (YES)
6. **No risk of regression**: The change only applies to a specific hardware configuration and cannot affect other systems. The fixup mechanism is mature and the specific fixup being applied is already proven on other HP models.
This is a textbook example of a hardware enablement quirk that should be backported to stable kernels to ensure users of the HP Pavilion Laptop 15-eg100 have properly functioning hardware across all supported kernel versions.
sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 3cacdbcb0d3ea..3f3a89ea2c2ee 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9995,6 +9995,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8975, "HP EliteBook x360 840 Aero G9", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x897d, "HP mt440 Mobile Thin Client U74", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8981, "HP Elite Dragonfly G3", ALC245_FIXUP_CS35L41_SPI_4), + SND_PCI_QUIRK(0x103c, 0x898a, "HP Pavilion 15-eg100", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x898e, "HP EliteBook 835 G9", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x898f, "HP EliteBook 835 G9", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8991, "HP EliteBook 845 G9", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED),
From: Xiaowei Li xiaowei.li@simcom.com
[ Upstream commit 0b39b055b5b48cbbdf5746a1ca6e3f6b0221e537 ]
Add support for SIMCom 8230C which is based on Qualcomm SDX35 chip. 0x9071: tty (DM) + tty (NMEA) + tty (AT) + rmnet T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9071 Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=none E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Xiaowei Li xiaowei.li@simcom.com Acked-by: Bjørn Mork bjorn@mork.no Link: https://patch.msgid.link/tencent_21D781FAA4969FEACA6ABB460362B52C9409@qq.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my detailed analysis:
## Rationale for Backporting:
1. **Stable kernel rules explicitly allow device ID additions**: According to Documentation/process/stable-kernel-rules.rst line 15, patches must "either fix a real bug that bothers people or just add a device ID." This commit clearly falls into the "add a device ID" category.
2. **Simple, low-risk change**: The commit adds exactly one line: ```c {QMI_QUIRK_SET_DTR(0x1e0e, 0x9071, 3)}, /* SIMCom 8230C ++ */ ``` This is a minimal change that only affects users with this specific hardware (vendor ID 0x1e0e, product ID 0x9071).
3. **Enables hardware that would otherwise not work**: Without this device ID entry, users with the SIMCom 8230C modem cannot use their hardware with the qmi_wwan driver. This directly impacts functionality for those users.
4. **Follows established patterns**: The commit uses `QMI_QUIRK_SET_DTR` macro, consistent with the existing SIMCom entry at line 1428: ```c {QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E ++ */ ``` This shows the vendor has a history of requiring the DTR quirk for their devices.
5. **Historical precedent supports backporting**: Of the 5 similar commits analyzed, 4 were backported to stable: - Fibocom FG132 (YES) - MeiG Smart SRM825L (YES) - Telit FN912 compositions (YES) - Telit FN920C04 compositions (YES) - Quectel RG255C (NO)
The 80% backport rate for similar device ID additions suggests this type of change is generally considered appropriate for stable.
6. **No risk to existing functionality**: The change only adds support for a new device ID (0x9071) and doesn't modify any existing device support or core driver functionality.
The commit meets all criteria for stable backporting: it's obviously correct, tested (as evidenced by the detailed USB descriptor output in the commit message), small (1 line), and enables hardware support that users need.
drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index b4c0413c6522a..96656e56e809f 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -1431,6 +1431,7 @@ static const struct usb_device_id products[] = { {QMI_QUIRK_SET_DTR(0x22de, 0x9051, 2)}, /* Hucom Wireless HM-211S/K */ {QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */ {QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E ++ */ + {QMI_QUIRK_SET_DTR(0x1e0e, 0x9071, 3)}, /* SIMCom 8230C ++ */ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */ {QMI_QUIRK_SET_DTR(0x2c7c, 0x0195, 4)}, /* Quectel EG95 */
From: Akira Inoue niyarium@gmail.com
[ Upstream commit a8905238c3bbe13db90065ed74682418f23830c3 ]
Add "Thinkpad X1 Tablet Gen 2 Keyboard" PID to hid-lenovo driver to fix trackpoint not working issue.
Signed-off-by: Akira Inoue niyarium@gmail.com Signed-off-by: Jiri Kosina jkosina@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Commit Analysis
This commit adds support for the ThinkPad X1 Tablet Thin Keyboard Gen2 by adding its USB device ID (0x60a4) to the hid-lenovo driver. The primary issue being fixed is that the trackpoint (pointing stick) is non-functional without this patch.
## Code Changes Examination
1. **drivers/hid/hid-ids.h**: Adds `USB_DEVICE_ID_LENOVO_X1_TAB2` with value 0x60a4. This follows the existing pattern where X1_TAB is 0x60a3 and X1_TAB3 is 0x60b5.
2. **drivers/hid/hid-lenovo.c**: The device ID is added to 7 locations: - `lenovo_input_mapping()`: Enables X1 tablet keyboard-specific input mappings - `attr_fn_lock_store()`: Enables FnLock LED control functionality - `lenovo_event()`: Handles special key events - `lenovo_led_brightness_set()`: Controls mute/micmute LED indicators - `lenovo_probe()`: Initializes device with tp10ubkbd infrastructure - `lenovo_remove()`: Cleanup handling - `lenovo_devices[]`: Device table entry with HID_GROUP_GENERIC
3. **drivers/hid/hid-multitouch.c**: Adds multitouch support with `MT_CLS_WIN_8_FORCE_MULTI_INPUT` class, consistent with other X1 Tablet devices.
## Stable Backport Criteria
This commit meets all the stable kernel backporting criteria:
1. **Fixes a real bug**: The trackpoint is completely non-functional without this patch, affecting users who own this hardware.
2. **Small and contained**: The changes are minimal - just adding a device ID to existing code paths. No new functionality or architectural changes.
3. **Obviously correct**: The pattern is identical to existing X1 Tablet support (Gen1 and Gen3). The commit follows established conventions.
4. **Low risk**: Cannot affect any other hardware since it's guarded by specific device ID checks.
5. **Hardware enablement**: This is pure hardware enablement for a specific device that doesn't work at all without this patch.
## Comparison with Similar Commits
Looking at the provided similar commits: - Commits adding X1 Tablet Gen3 support (Similar #2) and X12 Tab Gen2 support (Similar #4) were marked YES for backporting - Both fixed similar issues (non-working buttons, trackpoint, FnLock) - This commit follows the exact same pattern
The commit marked NO (Similar #1) only added partial multitouch support without the full hid-lenovo driver integration, which is why it wasn't suitable for stable.
## Conclusion
This is a textbook example of a commit that should be backported to stable kernels. It enables basic functionality (trackpoint) for specific hardware that is completely broken without it, using minimal, well- tested code patterns that cannot regress other devices.
drivers/hid/hid-ids.h | 1 + drivers/hid/hid-lenovo.c | 8 ++++++++ drivers/hid/hid-multitouch.c | 8 +++++++- 3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index e078d2ac92c87..60e30cc9d6ff7 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -790,6 +790,7 @@ #define USB_DEVICE_ID_LENOVO_TPPRODOCK 0x6067 #define USB_DEVICE_ID_LENOVO_X1_COVER 0x6085 #define USB_DEVICE_ID_LENOVO_X1_TAB 0x60a3 +#define USB_DEVICE_ID_LENOVO_X1_TAB2 0x60a4 #define USB_DEVICE_ID_LENOVO_X1_TAB3 0x60b5 #define USB_DEVICE_ID_LENOVO_X12_TAB 0x60fe #define USB_DEVICE_ID_LENOVO_X12_TAB2 0x61ae diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c index a4062f617ba20..90e8b6a0a873d 100644 --- a/drivers/hid/hid-lenovo.c +++ b/drivers/hid/hid-lenovo.c @@ -473,6 +473,7 @@ static int lenovo_input_mapping(struct hid_device *hdev, return lenovo_input_mapping_tp10_ultrabook_kbd(hdev, hi, field, usage, bit, max); case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: return lenovo_input_mapping_x1_tab_kbd(hdev, hi, field, usage, bit, max); default: @@ -584,6 +585,7 @@ static ssize_t attr_fn_lock_store(struct device *dev, break; case USB_DEVICE_ID_LENOVO_TP10UBKBD: case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: ret = lenovo_led_set_tp10ubkbd(hdev, TP10UBKBD_FN_LOCK_LED, value); if (ret) @@ -779,6 +781,7 @@ static int lenovo_event(struct hid_device *hdev, struct hid_field *field, return lenovo_event_cptkbd(hdev, field, usage, value); case USB_DEVICE_ID_LENOVO_TP10UBKBD: case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: return lenovo_event_tp10ubkbd(hdev, field, usage, value); default: @@ -1062,6 +1065,7 @@ static int lenovo_led_brightness_set(struct led_classdev *led_cdev, break; case USB_DEVICE_ID_LENOVO_TP10UBKBD: case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: ret = lenovo_led_set_tp10ubkbd(hdev, tp10ubkbd_led[led_nr], value); break; @@ -1293,6 +1297,7 @@ static int lenovo_probe(struct hid_device *hdev, break; case USB_DEVICE_ID_LENOVO_TP10UBKBD: case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: ret = lenovo_probe_tp10ubkbd(hdev); break; @@ -1380,6 +1385,7 @@ static void lenovo_remove(struct hid_device *hdev) break; case USB_DEVICE_ID_LENOVO_TP10UBKBD: case USB_DEVICE_ID_LENOVO_X1_TAB: + case USB_DEVICE_ID_LENOVO_X1_TAB2: case USB_DEVICE_ID_LENOVO_X1_TAB3: lenovo_remove_tp10ubkbd(hdev); break; @@ -1430,6 +1436,8 @@ static const struct hid_device_id lenovo_devices[] = { */ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB) }, + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, + USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB2) }, { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC, USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB3) }, { } diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 6386043aab0bb..becd4c1ccf93c 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -2110,12 +2110,18 @@ static const struct hid_device_id mt_devices[] = { HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC, USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_7010) },
- /* Lenovo X1 TAB Gen 2 */ + /* Lenovo X1 TAB Gen 1 */ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT, HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_X1_TAB) },
+ /* Lenovo X1 TAB Gen 2 */ + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT, + HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8, + USB_VENDOR_ID_LENOVO, + USB_DEVICE_ID_LENOVO_X1_TAB2) }, + /* Lenovo X1 TAB Gen 3 */ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT, HID_DEVICE(BUS_USB, HID_GROUP_MULTITOUCH_WIN_8,
From: Filipe Manana fdmanana@suse.com
[ Upstream commit 1961d20f6fa8903266ed9bd77c691924c22c8f02 ]
When building the free space tree with the block group tree feature enabled, we can hit an assertion failure like this:
BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---
This happens because we are processing an empty block group, which has no extents allocated from it, there are no items for this block group, including the block group item since block group items are stored in a dedicated tree when using the block group tree feature. It also means this is the block group with the highest start offset, so there are no higher keys in the extent root, hence btrfs_search_slot_for_read() returns 1 (no higher key found).
Fix this by asserting 'ret' is 0 only if the block group tree feature is not enabled, in which case we should find a block group item for the block group since it's stored in the extent root and block group item keys are greater than extent item keys (the value for BTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively). In case 'ret' is 1, we just need to add a record to the free space tree which spans the whole block group, and we can achieve this by making 'ret == 0' as the while loop's condition.
Reported-by: syzbot+36fae25c35159a763a2a@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/6841dca8.a00a0220.d4325.0020.GAE@google.... Reviewed-by: Qu Wenruo wqu@suse.com Signed-off-by: Filipe Manana fdmanana@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees, specifically to the 6.1.x and 6.6.x stable series. Here's my extensive analysis:
## Bug Severity and Impact
The commit fixes a **kernel BUG/assertion failure** that causes a system crash when rebuilding the free space tree. The stack trace shows:
``` assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 kernel BUG at fs/btrfs/free-space-tree.c:1102! ```
This is a serious issue that results in system instability and affects users who: 1. Use BTRFS with the block group tree feature enabled 2. Trigger a free space tree rebuild (e.g., during remount operations) 3. Have empty block groups in their filesystem
## Technical Analysis of the Fix
The fix is minimal and targeted:
```diff - ASSERT(ret == 0); + if (!btrfs_fs_compat_ro(trans->fs_info, BLOCK_GROUP_TREE)) + ASSERT(ret == 0); ```
and
```diff - while (1) { + while (ret == 0) { ```
The root cause is well-understood: when the block group tree feature is enabled, block group items are stored in a dedicated tree rather than the extent tree. For empty block groups, `btrfs_search_slot_for_read()` correctly returns 1 (no key found), but the old code incorrectly asserted this must be 0.
## Stable Backport Criteria
1. **Fixes a real bug affecting users**: ✓ (kernel crash) 2. **Small and contained fix**: ✓ (2 line logic changes + comments) 3. **No major side effects**: ✓ (only affects the specific error case) 4. **No architectural changes**: ✓ (simple logic adjustment) 5. **Critical subsystem but minimal risk**: ✓ (BTRFS, but very targeted fix)
## Version Considerations
Based on my repository analysis: - The block group tree feature was introduced in kernel 6.1-rc1 - Only 6.1.x and 6.6.x LTS kernels have this feature - Earlier kernels (5.10, 5.15) don't need this fix as they lack the feature
## Similar Commit Patterns
Looking at the provided similar commits: - Commits fixing free space tree corruption/crashes were marked YES for backporting - Only cosmetic or debug-related changes were marked NO - This commit follows the pattern of commits #1 and #2 which fixed actual bugs
## Conclusion
Despite lacking an explicit `Cc: stable@vger.kernel.org` tag, this commit meets all criteria for stable backporting. It fixes a kernel crash with a minimal, well-understood change that only affects systems using a specific BTRFS feature. The fix should be backported to 6.1.x and 6.6.x stable series where the block group tree feature exists.
fs/btrfs/free-space-tree.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/free-space-tree.c b/fs/btrfs/free-space-tree.c index 6a44733a95e1c..14bdb241ff6bb 100644 --- a/fs/btrfs/free-space-tree.c +++ b/fs/btrfs/free-space-tree.c @@ -1098,11 +1098,21 @@ static int populate_free_space_tree(struct btrfs_trans_handle *trans, ret = btrfs_search_slot_for_read(extent_root, &key, path, 1, 0); if (ret < 0) goto out_locked; - ASSERT(ret == 0); + /* + * If ret is 1 (no key found), it means this is an empty block group, + * without any extents allocated from it and there's no block group + * item (key BTRFS_BLOCK_GROUP_ITEM_KEY) located in the extent tree + * because we are using the block group tree feature, so block group + * items are stored in the block group tree. It also means there are no + * extents allocated for block groups with a start offset beyond this + * block group's end offset (this is the last, highest, block group). + */ + if (!btrfs_fs_compat_ro(trans->fs_info, BLOCK_GROUP_TREE)) + ASSERT(ret == 0);
start = block_group->start; end = block_group->start + block_group->length; - while (1) { + while (ret == 0) { btrfs_item_key_to_cpu(path->nodes[0], &key, path->slots[0]);
if (key.type == BTRFS_EXTENT_ITEM_KEY || @@ -1132,8 +1142,6 @@ static int populate_free_space_tree(struct btrfs_trans_handle *trans, ret = btrfs_next_item(extent_root, path); if (ret < 0) goto out_locked; - if (ret) - break; } if (start < end) { ret = __add_to_free_space_tree(trans, block_group, path2,
From: Nicolas Pitre npitre@baylibre.com
[ Upstream commit ff78538e07fa284ce08cbbcb0730daa91ed16722 ]
Programs using poll() on /dev/vcsa to be notified when VT changes occur were missing one case: the switch from gfx to text mode.
Signed-off-by: Nicolas Pitre npitre@baylibre.com Link: https://lore.kernel.org/r/9o5ro928-0pp4-05rq-70p4-ro385n21n723@onlyvoer.pbz Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **It fixes a real bug affecting userspace programs**: The commit addresses a missing notification that prevents programs using `poll()` on `/dev/vcsa` from being properly notified when the VT switches from graphics mode back to text mode. This is a functional regression that breaks userspace applications monitoring VT state changes.
2. **The fix is minimal and low-risk**: The change adds only a single line - `notify_update(vc);` - in the `do_unblank_screen()` function. This follows an established pattern where `notify_update()` is called after VT state changes to notify userspace watchers.
3. **Consistent with existing code patterns**: Looking at the codebase, `notify_update()` is already called in similar contexts throughout vt.c. For example, in `vc_do_resize()`, we see: ```c vt_event_post(VT_EVENT_RESIZE, vc->vc_num, vc->vc_num); notify_update(vc); ``` The same pattern should apply when unblanking the screen.
4. **Similar commits were backported**: The historical commits provided show that previous fixes adding or correcting `notify_update()` calls were marked for stable backporting (all three YES examples had `Cc: stable@vger.kernel.org`). These commits fixed similar issues where userspace poll() notifications were missing.
5. **Clear symptom and fix**: The bug has a clear symptom (missing notifications when switching from graphics to text mode) and a straightforward fix that directly addresses the root cause. The `leaving_gfx` parameter in `do_unblank_screen()` specifically indicates this transition scenario.
6. **No architectural changes**: This is purely a bug fix that restores expected behavior without introducing new features or changing the architecture of the VT subsystem.
The commit meets all the criteria for stable backporting: it fixes an important bug affecting userspace, the fix is minimal and contained, and it follows established patterns for similar fixes that were previously backported.
drivers/tty/vt/vt.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index e1b40a3848683..c30b4a48de644 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -4452,6 +4452,7 @@ void do_unblank_screen(int leaving_gfx) set_palette(vc); set_cursor(vc); vt_event_post(VT_EVENT_UNBLANK, vc->vc_num, vc->vc_num); + notify_update(vc); } EXPORT_SYMBOL(do_unblank_screen);
From: Zhang Heng zhangheng@kylinos.cn
[ Upstream commit 1a8953f4f7746c6a515989774fe03047c522c613 ]
MARTLINKTECHNOLOGY is a microphone device, when the HID interface in an audio device is requested to get specific report id, the following error may occur.
[ 562.939373] usb 1-1.4.1.2: new full-speed USB device number 21 using xhci_hcd [ 563.104908] usb 1-1.4.1.2: New USB device found, idVendor=4c4a, idProduct=4155, bcdDevice= 1.00 [ 563.104910] usb 1-1.4.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 563.104911] usb 1-1.4.1.2: Product: USB Composite Device [ 563.104912] usb 1-1.4.1.2: Manufacturer: SmartlinkTechnology [ 563.104913] usb 1-1.4.1.2: SerialNumber: 20201111000001 [ 563.229499] input: SmartlinkTechnology USB Composite Device as /devices/pci0000:00/0000:00:07.1/0000:04:00.3/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1.2/1-1.4.1.2:1.2/0003:4C4A:4155.000F/input/input35 [ 563.291505] hid-generic 0003:4C4A:4155.000F: input,hidraw2: USB HID v2.01 Keyboard [SmartlinkTechnology USB Composite Device] on usb-0000:04:00.3-1.4.1.2/input2 [ 563.291557] usbhid 1-1.4.1.2:1.3: couldn't find an input interrupt endpoint [ 568.506654] usb 1-1.4.1.2: 1:1: usb_set_interface failed (-110) [ 573.626656] usb 1-1.4.1.2: 1:1: usb_set_interface failed (-110) [ 578.746657] usb 1-1.4.1.2: 1:1: usb_set_interface failed (-110) [ 583.866655] usb 1-1.4.1.2: 1:1: usb_set_interface failed (-110) [ 588.986657] usb 1-1.4.1.2: 1:1: usb_set_interface failed (-110)
Ignore HID interface. The device is working properly.
Signed-off-by: Zhang Heng zhangheng@kylinos.cn Signed-off-by: Jiri Kosina jkosina@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
1. **The commit fixes a real user-visible bug**: The device causes repeated USB interface timeout errors (`usb_set_interface failed (-110)`) that spam the kernel log and potentially interfere with device operation. The error log shows five consecutive timeout failures over 25 seconds, which would significantly impact user experience.
2. **The fix is minimal and contained**: The code changes are extremely simple - just adding two lines to define the vendor/device ID in `hid-ids.h` and one line to add it to the `hid_ignore_list[]` array in `hid-quirks.c`. This is the standard pattern for HID quirks.
3. **Similar commits were backported**: This is very similar to "Similar Commit #1" (Logitech GROUP) which also dealt with HID interfaces on audio devices causing problems. That commit added `HID_QUIRK_NOGET` and was backported. The pattern is identical - an audio device with a problematic HID interface that needs to be handled via quirks.
4. **No risk of regression**: The change only affects devices with vendor ID 0x4c4a and product ID 0x4155. When a device matches this ID, the HID subsystem will simply skip it via the `hid_ignore()` function check in `hid_add_device()`. This cannot affect any other devices.
5. **The device functions properly with the fix**: The commit message explicitly states "The device is working properly" - meaning the audio functionality works fine once the HID interface is ignored. This is not breaking functionality but rather preventing the HID subsystem from interfering with a working audio device.
6. **The error pattern indicates a hardware quirk**: The continuous timeout errors (-110) when trying to set the USB interface suggests the device's HID implementation doesn't properly respond to standard HID commands. This is exactly the type of hardware-specific issue that the HID quirks system was designed to handle.
This meets all the criteria for stable backporting: it fixes a bug affecting users, is small and self-contained, has minimal risk, and follows established patterns for similar fixes that were previously backported.
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 60e30cc9d6ff7..21e0660179ee9 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -1455,4 +1455,7 @@ #define USB_VENDOR_ID_SIGNOTEC 0x2133 #define USB_DEVICE_ID_SIGNOTEC_VIEWSONIC_PD1011 0x0018
+#define USB_VENDOR_ID_SMARTLINKTECHNOLOGY 0x4c4a +#define USB_DEVICE_ID_SMARTLINKTECHNOLOGY_4155 0x4155 + #endif diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index d8c5c7d451efd..7fca632ceea79 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -885,6 +885,7 @@ static const struct hid_device_id hid_ignore_list[] = { #endif { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) }, { HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_HP_5MP_CAMERA_5473) }, + { HID_USB_DEVICE(USB_VENDOR_ID_SMARTLINKTECHNOLOGY, USB_DEVICE_ID_SMARTLINKTECHNOLOGY_4155) }, { } };
From: "Chia-Lin Kao (AceLan)" acelan.kao@canonical.com
[ Upstream commit 54bae4c17c11688339eb73a04fd24203bb6e7494 ]
The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor.
Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.
Signed-off-by: Chia-Lin Kao (AceLan) acelan.kao@canonical.com Signed-off-by: Jiri Kosina jkosina@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Key Characteristics of This Commit:
1. **Fixes a Critical User-Facing Bug**: The commit addresses system hangs that occur when userspace attempts to access non-functional HID sensor interfaces through iio_info. This is a serious usability issue that can make the system unresponsive.
2. **Minimal and Contained Changes**: The patch only adds two device IDs to existing infrastructure: - In `drivers/hid/hid-ids.h`: Added `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA` (0xb824) and `USB_DEVICE_ID_CHICONY_HP_5MP_CAMERA2` (0xb82c) - In `drivers/hid/hid-quirks.c`: Added these two devices to the `hid_ignore_list[]` array
3. **Zero Risk of Regression**: The changes only affect the specific USB devices (04F2:B824 and 04F2:B82C). No existing functionality is modified, and no code logic is changed.
## Comparison with Similar Commits:
This commit is nearly identical to **Similar Commit #1** (which was backported), where a QUANTA HP 5MP Camera (0408:5473) was added to the ignore list for the exact same reason - non-functional sensor causing system hangs. Both commits: - Target HP 5MP cameras with non-functional sensors - Use the same fix approach (adding to HID ignore list) - Prevent system hangs when accessing the sensor
## Alignment with Stable Kernel Rules:
The commit perfectly aligns with stable tree criteria: - **Fixes a real bug**: System hangs are critical issues - **Already in Linus' tree**: Signed-off by Jiri Kosina (HID maintainer) - **Small change**: Only 4 lines of actual code changes - **Obviously correct**: Simply adding device IDs to an ignore list - **No new features**: Pure bugfix - **Hardware-specific**: Only affects users with these specific cameras
## Historical Precedent:
Looking at the provided similar commits: - 4 out of 5 hardware quirk commits were backported (80% backport rate) - All commits fixing system hangs or device disconnections were backported - The only non-backported commit (#4) involved architectural changes to enum handling
This commit follows the exact pattern of successfully backported hardware quirks, making it an excellent candidate for stable inclusion.
drivers/hid/hid-ids.h | 2 ++ drivers/hid/hid-quirks.c | 2 ++ 2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 21e0660179ee9..0bbba80d6c51c 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -297,6 +297,8 @@ #define USB_DEVICE_ID_ASUS_AK1D 0x1125 #define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A 0x1408 #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_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 7fca632ceea79..b37927f909412 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -738,6 +738,8 @@ static const struct hid_device_id hid_ignore_list[] = { { HID_USB_DEVICE(USB_VENDOR_ID_AVERMEDIA, USB_DEVICE_ID_AVER_FM_MR800) }, { HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA, USB_DEVICE_ID_AXENTIA_FM_RADIO) }, { 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_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) },
linux-stable-mirror@lists.linaro.org
-
Sasha Levin