user/sven/linux.git/drivers, branch v6.6.111

staging: axis-fifo: flush RX FIFO on read errors

2025-10-12T10:56:22Z

commit 82a051e2553b9e297cba82a975d9c538b882c79e upstream. Flush stale data from the RX FIFO in case of errors, to avoid reading old data when new packets arrive. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") removed full FIFO resets from the read error paths, which fixed potential TX data losses, but introduced this RX issue. Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") Cc: stable@vger.kernel.org Signed-off-by: Ovidiu Panait Link: https://lore.kernel.org/r/20250912101322.1282507-2-ovidiu.panait.oss@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: axis-fifo: fix TX handling on copy_from_user() failure

2025-10-12T10:56:22Z

commit 6d07bee10e4bdd043ec7152cbbb9deb27033c9e2 upstream. If copy_from_user() fails, write() currently returns -EFAULT, but any partially written data leaves the TX FIFO in an inconsistent state. Subsequent write() calls then fail with "transmit length mismatch" errors. Once partial data is written to the hardware FIFO, it cannot be removed without a TX reset. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") removed a full FIFO reset for this case, which fixed a potential RX data loss, but introduced this TX issue. Fix this by introducing a bounce buffer: copy the full packet from userspace first, and write to the hardware FIFO only if the copy was successful. Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") Cc: stable@vger.kernel.org Signed-off-by: Ovidiu Panait Link: https://lore.kernel.org/r/20250912101322.1282507-1-ovidiu.panait.oss@gmail.com Signed-off-by: Greg Kroah-Hartman

staging: axis-fifo: fix maximum TX packet length check

2025-10-12T10:56:22Z

commit 52ff2b840bc723f3be1f096f8017c78e0515858c upstream. Since commit 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation"), write() operations with packets larger than 'tx_fifo_depth - 4' words are no longer rejected with -EINVAL. Fortunately, the packets are not actually getting transmitted to hardware, otherwise they would be raising a 'Transmit Packet Overrun Error' interrupt, which requires a reset of the TX circuit to recover from. Instead, the request times out inside wait_event_interruptible_timeout() and always returns -EAGAIN, since the wake up condition can never be true for these packets. But still, they unnecessarily block other tasks from writing to the FIFO and the EAGAIN return code signals userspace to retry the write() call, even though it will always fail and time out. According to the AXI4-Stream FIFO reference manual (PG080), the maximum valid packet length is 'tx_fifo_depth - 4' words, so attempting to send larger packets is invalid and should not be happening in the first place: > The maximum packet that can be transmitted is limited by the size of > the FIFO, which is (C_TX_FIFO_DEPTH–4)*(data interface width/8) bytes. Therefore, bring back the old behavior and outright reject packets larger than 'tx_fifo_depth - 4' with -EINVAL. Add a comment to explain why the check is necessary. The dev_err() message was removed to avoid cluttering the dmesg log if an invalid packet is received from userspace. Fixes: 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation") Cc: stable@vger.kernel.org Signed-off-by: Ovidiu Panait Link: https://lore.kernel.org/r/20250817171350.872105-1-ovidiu.panait.oss@gmail.com Signed-off-by: Greg Kroah-Hartman

serial: stm32: allow selecting console when the driver is module

2025-10-12T10:56:22Z

commit cc4d900d0d6d8dd5c41832a93ff3cfa629a78f9a upstream. Console can be enabled on the UART compile as module. Change dependency to allow console mode when the driver is built as module. Fixes: 48a6092fb41fa ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable@vger.kernel.org Signed-off-by: Raphael Gallais-Pou Link: https://lore.kernel.org/r/20250822141923.61133-1-raphael.gallais-pou@foss.st.com Signed-off-by: Greg Kroah-Hartman

hid: fix I2C read buffer overflow in raw_event() for mcp2221

2025-10-12T10:56:22Z

commit b56cc41a3ae7323aa3c6165f93c32e020538b6d2 upstream. As reported by syzbot, mcp2221_raw_event lacked validation of incoming I2C read data sizes, risking buffer overflows in mcp->rxbuf during multi-part transfers. As highlighted in the DS20005565B spec, p44, we have: "The number of read-back data bytes to follow in this packet: from 0 to a maximum of 60 bytes of read-back bytes." This patch enforces we don't exceed this limit. Reported-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346 Tested-by: syzbot+52c1a7d3e5b361ccd346@syzkaller.appspotmail.com Signed-off-by: Arnaud Lecomte Link: https://patch.msgid.link/20250726220931.7126-1-contact@arnaud-lcm.com Signed-off-by: Benjamin Tissoires Signed-off-by: Romain Sioen Signed-off-by: Greg Kroah-Hartman

platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious 8042 quirks list

2025-10-12T10:56:21Z

[ Upstream commit 12a3dd4d2cd9232d4e4df3b9a5b3d745db559941 ] Prevents instant wakeup ~1s after suspend Signed-off-by: Christoffer Sandberg Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20250916164700.32896-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

can: rcar_canfd: Fix controller mode setting

2025-10-12T10:56:21Z

[ Upstream commit 5cff263606a10102a0ea19ff579eaa18fd5577ad ] Driver configures register to choose controller mode before setting all channels to reset mode leading to failure. The patch corrects operation of mode setting. Signed-off-by: Duy Nguyen Signed-off-by: Tranh Ha Link: https://patch.msgid.link/TYWPR01MB87434739F83E27EDCD23DF44B416A@TYWPR01MB8743.jpnprd01.prod.outlook.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled

2025-10-12T10:56:21Z

[ Upstream commit 6b696808472197b77b888f50bc789a3bae077743 ] This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from sleep before interface was brought up"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks. Signed-off-by: Chen Yufeng Link: https://patch.msgid.link/20250911150820.250-1-chenyufeng@iie.ac.cn Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042 list

2025-10-12T10:56:21Z

[ Upstream commit 8822e8be86d40410ddd2ac8ff44f3050c9ecf9c6 ] The firmware of Mechrevo Yilong15Pro emits a spurious keyboard interrupt on events including closing the lid. When a user closes the lid on an already suspended system this causes the system to wake up. Add Mechrevo Yilong15Pro Series (GM5HG7A) to the list of quirk spurious_8042 to work around this issue. Link: https://lore.kernel.org/linux-pm/6ww4uu6Gl4F5n6VY5dl1ufASfKzs4DhMxAN8BuqUpCoqU3PQukVSVSBCl_lKIzkQ-S8kt1acPd58eyolhkWN32lMLFj4ViI0Tdu2jwhnYZ8=@proton.me/ Signed-off-by: April Grimoire Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/IvSc_IN5Pa0wRXElTk_fEl-cTpMZxg6TCQk_7aRUkTd9vJUp_ZeC0NdXZ0z6Tn7B-XiqqqQvCH65lq6FqhuECBMEYWcHQmWm1Jo7Br8kpeg=@proton.me Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

dm-integrity: limit MAX_TAG_SIZE to 255

2025-10-12T10:56:21Z

[ Upstream commit 77b8e6fbf9848d651f5cb7508f18ad0971f3ffdb ] MAX_TAG_SIZE was 0x1a8 and it may be truncated in the "bi->metadata_size = ic->tag_size" assignment. We need to limit it to 255. Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin