commit b9d5d463c216763cec719c04536ea9e14512cad4 Author: Greg Kroah-Hartman Date: Tue Jun 10 07:15:58 2025 -0400 Linux 6.14.11 Link: https://lore.kernel.org/r/20250607100717.706871523@linuxfoundation.org Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Peter Schneider Tested-by: Pavel Machek (CIP) Tested-by: Mark Brown Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman commit dc86041f8d31ab7937f779a4253c106c027c4d92 Author: Aurabindo Pillai Date: Wed May 21 16:05:39 2025 -0400 Revert "drm/amd/display: more liberal vmin/vmax update for freesync" commit 1b824eef269db44d068bbc0de74c94a8e8f9ce02 upstream. This reverts commit cfb2d41831ee5647a4ae0ea7c24971a92d5dfa0d since it causes regressions on certain configs. Revert until the issue can be isolated and debugged. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4238 Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 939ef528dea46d866f0124fee66843f831ba6670 Author: Xu Yang Date: Wed Apr 30 17:44:59 2025 +0800 dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property commit 5b3a91b207c00a8d27f75ce8aaa9860844da72c8 upstream. The ticket TKT0676370 shows the description of TX_VBOOST_LVL is wrong in register PHY_CTRL3 bit[31:29]. 011: Corresponds to a launch amplitude of 1.12 V. 010: Corresponds to a launch amplitude of 1.04 V. 000: Corresponds to a launch amplitude of 0.88 V. After updated: 011: Corresponds to a launch amplitude of 0.844 V. 100: Corresponds to a launch amplitude of 1.008 V. 101: Corresponds to a launch amplitude of 1.156 V. This will correct it accordingly. Fixes: b2e75563dc39 ("dt-bindings: phy: imx8mq-usb: add phy tuning properties") Cc: stable@vger.kernel.org Reviewed-by: Jun Li Signed-off-by: Xu Yang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250430094502.2723983-1-xu.yang_2@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit bd4849b1493c330bcbc62799f73368aebaf17bbe Author: Lukasz Czechowski Date: Fri Apr 25 17:18:07 2025 +0200 dt-bindings: usb: cypress,hx3: Add support for all variants commit 1ad4b5a7de16806afc1aeaf012337e62af04e001 upstream. The Cypress HX3 hubs use different default PID value depending on the variant. Update compatibles list. Becasuse all hub variants use the same driver data, allow the dt node to have two compatibles: leftmost which matches the HW exactly, and the second one as fallback. Fixes: 1eca51f58a10 ("dt-bindings: usb: Add binding for Cypress HX3 USB 3.0 family") Cc: stable@vger.kernel.org # 6.6 Cc: stable@vger.kernel.org # Backport of the patch ("dt-bindings: usb: usb-device: relax compatible pattern to a contains") from list: https://lore.kernel.org/linux-usb/20250418-dt-binding-usb-device-compatibles-v2-1-b3029f14e800@cherry.de/ Cc: stable@vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski Reviewed-by: "Rob Herring (Arm)" Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-2-4a76a474a010@thaumatec.com [taken with Greg's blessing] Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit ce2fed22a02249e670f82f2cba8cee50f9cc3d99 Author: David Lechner Date: Thu May 29 11:53:19 2025 -0500 dt-bindings: pwm: adi,axi-pwmgen: Fix clocks commit e683131e64f71e957ca77743cb3d313646157329 upstream. Fix a shortcoming in the bindings that doesn't allow for a separate external clock. The AXI PWMGEN IP block has a compile option ASYNC_CLK_EN that allows the use of an external clock for the PWM output separate from the AXI clock that runs the peripheral. This was missed in the original bindings and so users were writing dts files where the one and only clock specified would be the external clock, if there was one, incorrectly missing the separate AXI clock. The correct bindings are that the AXI clock is always required and the external clock is optional (must be given only when HDL compile option ASYNC_CLK_EN=1). Fixes: 1edf2c2a2841 ("dt-bindings: pwm: Add AXI PWM generator") Cc: stable@vger.kernel.org Signed-off-by: David Lechner Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250529-pwm-axi-pwmgen-add-external-clock-v3-2-5d8809a7da91@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 0771bcbe2f6e5d5f263cf466efe571d2754a46da Author: Sergey Senozhatsky Date: Fri Mar 28 00:03:50 2025 +0900 thunderbolt: Do not double dequeue a configuration request commit 0f73628e9da1ee39daf5f188190cdbaee5e0c98c upstream. Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set. Signed-off-by: Sergey Senozhatsky Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 4a7694f499cae5b83412c5281bf2c961f34f2ed6 Author: Carlos Llamas Date: Sat May 24 22:07:58 2025 +0000 binder: fix yet another UAF in binder_devices commit 9857af0fcff385c75433f2162c30c62eb912ef6d upstream. Commit e77aff5528a18 ("binderfs: fix use-after-free in binder_devices") addressed a use-after-free where devices could be released without first being removed from the binder_devices list. However, there is a similar path in binder_free_proc() that was missed: ================================================================== BUG: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100 Write of size 8 at addr ffff0000c773b900 by task umount/467 CPU: 12 UID: 0 PID: 467 Comm: umount Not tainted 6.15.0-rc7-00138-g57483a362741 #9 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_remove_device+0xd4/0x100 binderfs_evict_inode+0x230/0x2f0 evict+0x25c/0x5dc iput+0x304/0x480 dentry_unlink_inode+0x208/0x46c __dentry_kill+0x154/0x530 [...] Allocated by task 463: __kmalloc_cache_noprof+0x13c/0x324 binderfs_binder_device_create.isra.0+0x138/0xa60 binder_ctl_ioctl+0x1ac/0x230 [...] Freed by task 215: kfree+0x184/0x31c binder_proc_dec_tmpref+0x33c/0x4ac binder_deferred_func+0xc10/0x1108 process_one_work+0x520/0xba4 [...] ================================================================== Call binder_remove_device() within binder_free_proc() to ensure the device is removed from the binder_devices list before being kfreed. Cc: stable@vger.kernel.org Fixes: 12d909cac1e1 ("binderfs: add new binder devices to binder_devices") Reported-by: syzbot+4af454407ec393de51d6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4af454407ec393de51d6 Tested-by: syzbot+4af454407ec393de51d6@syzkaller.appspotmail.com Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20250524220758.915028-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 80ed8ab8efa0d18c03968a2321154f10e2d1a2e3 Author: Dmitry Antipov Date: Sat May 17 17:09:56 2025 +0000 binder: fix use-after-free in binderfs_evict_inode() commit 8c0a559825281764061a127632e5ad273f0466ad upstream. Running 'stress-ng --binderfs 16 --timeout 300' under KASAN-enabled kernel, I've noticed the following: BUG: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0 Write of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699 CPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: dump_stack_lvl+0x1c2/0x2a0 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 print_report+0x155/0x840 ? __virt_addr_valid+0x18c/0x540 ? __virt_addr_valid+0x469/0x540 ? __phys_addr+0xba/0x170 ? binderfs_evict_inode+0x1de/0x2d0 kasan_report+0x147/0x180 ? binderfs_evict_inode+0x1de/0x2d0 binderfs_evict_inode+0x1de/0x2d0 ? __pfx_binderfs_evict_inode+0x10/0x10 evict+0x524/0x9f0 ? __pfx_lock_release+0x10/0x10 ? __pfx_evict+0x10/0x10 ? do_raw_spin_unlock+0x4d/0x210 ? _raw_spin_unlock+0x28/0x50 ? iput+0x697/0x9b0 __dentry_kill+0x209/0x660 ? shrink_kill+0x8d/0x2c0 shrink_kill+0xa9/0x2c0 shrink_dentry_list+0x2e0/0x5e0 shrink_dcache_parent+0xa2/0x2c0 ? __pfx_shrink_dcache_parent+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 do_one_tree+0x23/0xe0 shrink_dcache_for_umount+0xa0/0x170 generic_shutdown_super+0x67/0x390 kill_litter_super+0x76/0xb0 binderfs_kill_super+0x44/0x90 deactivate_locked_super+0xb9/0x130 cleanup_mnt+0x422/0x4c0 ? lockdep_hardirqs_on+0x9d/0x150 task_work_run+0x1d2/0x260 ? __pfx_task_work_run+0x10/0x10 resume_user_mode_work+0x52/0x60 syscall_exit_to_user_mode+0x9a/0x120 do_syscall_64+0x103/0x210 ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0xcac57b Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 RSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850 RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff R10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718 R13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830 Allocated by task 1705: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x8f/0xa0 __kmalloc_cache_noprof+0x213/0x3e0 binderfs_binder_device_create+0x183/0xa80 binder_ctl_ioctl+0x138/0x190 __x64_sys_ioctl+0x120/0x1b0 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1705: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x46/0x50 __kasan_slab_free+0x62/0x70 kfree+0x194/0x440 evict+0x524/0x9f0 do_unlinkat+0x390/0x5b0 __x64_sys_unlink+0x47/0x50 do_syscall_64+0xf6/0x210 entry_SYSCALL_64_after_hwframe+0x77/0x7f This 'stress-ng' workload causes the concurrent deletions from 'binder_devices' and so requires full-featured synchronization to prevent list corruption. I've found this issue independently but pretty sure that syzbot did the same, so Reported-by: and Closes: should be applicable here as well. Cc: stable@vger.kernel.org Reported-by: syzbot+353d7b75658a95aa955a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=353d7b75658a95aa955a Fixes: e77aff5528a18 ("binderfs: fix use-after-free in binder_devices") Signed-off-by: Dmitry Antipov Acked-by: Carlos Llamas Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20250517170957.1317876-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit f6e5933ca1f91cb9f67051af348d23276d0a640d Author: Dave Penkler Date: Wed May 21 14:16:56 2025 +0200 usb: usbtmc: Fix timeout value in get_stb commit 342e4955a1f1ce28c70a589999b76365082dbf10 upstream. wait_event_interruptible_timeout requires a timeout argument in units of jiffies. It was being called in usbtmc_get_stb with the usb timeout value which is in units of milliseconds. Pass the timeout argument converted to jiffies. Fixes: 048c6d88a021 ("usb: usbtmc: Add ioctls to set/get usb timeout") Cc: stable@vger.kernel.org Signed-off-by: Dave Penkler Link: https://lore.kernel.org/r/20250521121656.18174-4-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman commit ed804d4adab072c1a69bf97b96418b49371d657e Author: Arnd Bergmann Date: Fri May 9 13:24:06 2025 +0100 nvmem: rmem: select CONFIG_CRC32 commit 7a93add1d31f14e0b7e937163904dee1e864a9a8 upstream. The newly added crc checking leads to a link failure if CRC32 itself is disabled: x86_64-linux-ld: vmlinux.o: in function `rmem_eyeq5_checksum': rmem.c:(.text+0x52341b): undefined reference to `crc32_le_arch' Fixes: 7e606c311f70 ("nvmem: rmem: add CRC validation for Mobileye EyeQ5 NVMEM") Cc: stable Signed-off-by: Arnd Bergmann Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20250509122407.11763-2-srini@kernel.org Signed-off-by: Greg Kroah-Hartman commit a14c0d2eb3f0b1836fdec22908b87ecffd2ac844 Author: Dustin Lundquist Date: Tue May 6 11:18:45 2025 -0700 serial: jsm: fix NPE during jsm_uart_port_init commit e3975aa899c0a3bbc10d035e699b142cd1373a71 upstream. No device was set which caused serial_base_ctrl_add to crash. BUG: kernel NULL pointer dereference, address: 0000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serial_base_ctrl_add+0x96/0x120 Call Trace: serial_core_register_port+0x1a0/0x580 ? __setup_irq+0x39c/0x660 ? __kmalloc_cache_noprof+0x111/0x310 jsm_uart_port_init+0xe8/0x180 [jsm] jsm_probe_one+0x1f4/0x410 [jsm] local_pci_probe+0x42/0x90 pci_device_probe+0x22f/0x270 really_probe+0xdb/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8c/0xe0 bus_add_driver+0x112/0x1f0 driver_register+0x72/0xd0 jsm_init_module+0x36/0xff0 [jsm] ? __pfx_jsm_init_module+0x10/0x10 [jsm] do_one_initcall+0x58/0x310 do_init_module+0x60/0x230 Tested with Digi Neo PCIe 8 port card. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Cc: stable Signed-off-by: Dustin Lundquist Link: https://lore.kernel.org/r/3f31d4f75863614655c4673027a208be78d022ec.camel@null-ptr.net Signed-off-by: Greg Kroah-Hartman commit fc60cde814bfba1d4002c88f02d845be5dc5d75a Author: Bartosz Golaszewski Date: Tue May 27 09:47:37 2025 +0200 Bluetooth: hci_qca: move the SoC type check to the right place commit 0fb410c914eb03c7e9d821e26d03bac0a239e5db upstream. Commit 3d05fc82237a ("Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional()") accidentally changed the prevous behavior where power control would be disabled without the BT_EN GPIO only on QCA_WCN6750 and QCA_WCN6855 while also getting the error check wrong. We should treat every IS_ERR() return value from devm_gpiod_get_optional() as a reason to bail-out while we should only set power_ctrl_enabled to false on the two models mentioned above. While at it: use dev_err_probe() to save a LOC. Cc: stable@vger.kernel.org Fixes: 3d05fc82237a ("Bluetooth: qca: set power_ctrl_enabled on NULL returned by gpiod_get_optional()") Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Tested-by: Hsin-chen Chuang Reviewed-by: Hsin-chen Chuang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 838ff899d64030b43866cc0238a6b70f22292a82 Author: Qasim Ijaz Date: Tue Apr 22 14:47:17 2025 +0100 usb: typec: ucsi: fix Clang -Wsign-conversion warning commit f4239ace2dd8606f6824757f192965a95746da05 upstream. debugfs.c emits the following warnings when compiling with the -Wsign-conversion flag with clang 15: drivers/usb/typec/ucsi/debugfs.c:58:27: warning: implicit conversion changes signedness: 'int' to 'u32' (aka 'unsigned int') [-Wsign-conversion] ucsi->debugfs->status = ret; ~ ^~~ drivers/usb/typec/ucsi/debugfs.c:71:25: warning: implicit conversion changes signedness: 'u32' (aka 'unsigned int') to 'int' [-Wsign-conversion] return ucsi->debugfs->status; ~~~~~~ ~~~~~~~~~~~~~~~^~~~~~ During ucsi_cmd() we see: if (ret < 0) { ucsi->debugfs->status = ret; return ret; } But "status" is u32 meaning unsigned wrap-around occurs when assigning a value which is < 0 to it, this obscures the real status. To fix this make the "status" of type int since ret is also of type int. Fixes: df0383ffad64 ("usb: typec: ucsi: Add debugfs for ucsi commands") Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250422134717.66218-1-qasdev00@gmail.com Signed-off-by: Greg Kroah-Hartman commit 4a047f2abc44fff24b353327487a5d6b284c4aa0 Author: Charles Yeh Date: Wed May 21 21:23:54 2025 +0800 USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB commit d3a889482bd5abf2bbdc1ec3d2d49575aa160c9c upstream. Add new bcd (0x905) to support PL2303GT-2AB (TYPE_HXN). Add new bcd (0x1005) to support PL2303GC-Q20 (TYPE_HXN). Signed-off-by: Charles Yeh Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 75f297e5a22da0d65f1caa41f019c4aba3f53e7c Author: Hongyu Xie Date: Mon May 19 10:33:28 2025 +0800 usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device commit a541acceedf4f639f928f41fbb676b75946dc295 upstream. SanDisk 3.2 Gen2 storage device(0781:55e8) doesn't work well with UAS. Log says, [ 6.507865][ 3] [ T159] usb 2-1.4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 6.540314][ 3] [ T159] usb 2-1.4: New USB device found, idVendor=0781, idProduct=55e8, bcdDevice= 0.01 [ 6.576304][ 3] [ T159] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 6.584727][ 3] [ T159] usb 2-1.4: Product: SanDisk 3.2 Gen2 [ 6.590459][ 3] [ T159] usb 2-1.4: Manufacturer: SanDisk [ 6.595845][ 3] [ T159] usb 2-1.4: SerialNumber: 03021707022525140940 [ 7.230852][ 0] [ T265] usbcore: registered new interface driver usb-storage [ 7.251247][ 0] [ T265] scsi host3: uas [ 7.255280][ 0] [ T265] usbcore: registered new interface driver uas [ 7.270498][ 1] [ T192] scsi 3:0:0:0: Direct-Access SanDisk Extreme Pro DDE1 0110 PQ: 0 ANSI: 6 [ 7.299588][ 3] [ T192] scsi 3:0:0:1: Enclosure SanDisk SES Device 0110 PQ: 0 ANSI: 6 [ 7.321681][ 3] [ T192] sd 3:0:0:0: Attached scsi generic sg1 type 0 [ 7.328185][ 3] [ T192] scsi 3:0:0:1: Attached scsi generic sg2 type 13 [ 7.328804][ 0] [ T191] sd 3:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) [ 7.343486][ 0] [ T191] sd 3:0:0:0: [sda] 4096-byte physical blocks [ 7.364611][ 0] [ T191] sd 3:0:0:0: [sda] Write Protect is off [ 7.370524][ 0] [ T191] sd 3:0:0:0: [sda] Mode Sense: 3d 00 10 00 [ 7.390655][ 0] [ T191] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 7.401363][ 0] [ T191] sd 3:0:0:0: [sda] Optimal transfer size 1048576 bytes [ 7.436010][ 0] [ T191] sda: sda1 [ 7.450850][ 0] [ T191] sd 3:0:0:0: [sda] Attached SCSI disk [ 7.470218][ 4] [ T262] scsi 3:0:0:1: Failed to get diagnostic page 0x1 [ 7.474869][ 0] [ C0] sd 3:0:0:0: [sda] tag#0 data cmplt err -75 uas-tag 2 inflight: CMD [ 7.476911][ 4] [ T262] scsi 3:0:0:1: Failed to bind enclosure -19 [ 7.485330][ 0] [ C0] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00 [ 7.491593][ 4] [ T262] ses 3:0:0:1: Attached Enclosure device [ 38.066980][ 4] [ T192] sd 3:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN [ 38.076012][ 4] [ T192] sd 3:0:0:0: [sda] tag#4 CDB: Read(10) 28 00 00 00 01 08 00 00 f8 00 [ 38.086485][ 4] [ T192] sd 3:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 38.095515][ 4] [ T192] sd 3:0:0:0: [sda] tag#3 CDB: Read(10) 28 00 00 00 00 10 00 00 08 00 [ 38.104122][ 4] [ T192] sd 3:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN [ 38.113152][ 4] [ T192] sd 3:0:0:0: [sda] tag#2 CDB: Read(10) 28 00 00 00 00 88 00 00 78 00 [ 38.121761][ 4] [ T192] sd 3:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN [ 38.130791][ 4] [ T192] sd 3:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 00 00 00 48 00 00 30 00 [ 38.139401][ 4] [ T192] sd 3:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD [ 38.148170][ 4] [ T192] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00 [ 38.178980][ 2] [ T304] scsi host3: uas_eh_device_reset_handler start [ 38.901540][ 2] [ T304] usb 2-1.4: reset SuperSpeed Gen 1 USB device number 4 using xhci_hcd [ 38.936791][ 2] [ T304] scsi host3: uas_eh_device_reset_handler success Device decriptor is below, Bus 002 Device 006: ID 0781:55e8 SanDisk Corp. SanDisk 3.2 Gen2 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0781 SanDisk Corp. idProduct 0x55e8 bcdDevice 0.01 iManufacturer 1 SanDisk iProduct 2 SanDisk 3.2 Gen2 iSerial 3 03021707022525140940 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0079 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 896mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x002a bNumDeviceCaps 3 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x0000f41e BESL Link Power Management (LPM) Supported BESL value 1024 us Deep BESL value 61440 us SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds SuperSpeedPlus USB Device Capability: bLength 20 bDescriptorType 16 bDevCapabilityType 10 bmAttributes 0x00000001 Sublink Speed Attribute count 1 Sublink Speed ID count 0 wFunctionalitySupport 0x1100 bmSublinkSpeedAttr[0] 0x000a4030 Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus bmSublinkSpeedAttr[1] 0x000a40b0 Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus Device Status: 0x0000 (Bus Powered) So ignore UAS driver for this device. Signed-off-by: Hongyu Xie Cc: stable Link: https://lore.kernel.org/r/20250519023328.1498856-1-xiehongyu1@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 0b49d9a910ba93cbeae7ec07cc8d31ead2573fc2 Author: Jiayi Li Date: Thu May 8 13:59:47 2025 +0800 usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE commit 19f795591947596b5b9efa86fd4b9058e45786e9 upstream. This device exhibits I/O errors during file transfers due to unstable link power management (LPM) behavior. The kernel logs show repeated warm resets and eventual disconnection when LPM is enabled: [ 3467.810740] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0020 [ 3467.810740] usb usb2-port5: do warm reset [ 3467.866444] usb usb2-port5: not warm reset yet, waiting 50ms [ 3467.907407] sd 0:0:0:0: [sda] tag#12 sense submit err -19 [ 3467.994423] usb usb2-port5: status 02c0, change 0001, 10.0 Gb/s [ 3467.994453] usb 2-5: USB disconnect, device number 4 The error -19 (ENODEV) occurs when the device disappears during write operations. Adding USB_QUIRK_NO_LPM disables link power management for this specific device, resolving the stability issues. Signed-off-by: Jiayi Li Cc: stable Link: https://lore.kernel.org/r/20250508055947.764538-1-lijiayi@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit a5336ada21b113a17cd95176741aaed3aa690d82 Author: Mike Marshall Date: Wed Jun 4 11:23:02 2025 -0400 orangefs: adjust counting code to recover from 665575cf A late commit to 6.14-rc7 (665575cf) broke orangefs. This is a several line adjustment to some counters needed to keep orangefs from deadlocking when writing page cache data out to the filesystem. Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit 57082e0300d56e7aad1a874788aedd556028c90a Author: Alexandre Mergnat Date: Mon Apr 28 12:06:48 2025 +0200 rtc: Fix offset calculation for .start_secs < 0 commit fe9f5f96cfe8b82d0f24cbfa93718925560f4f8d upstream. The comparison rtc->start_secs > rtc->range_max has a signed left-hand side and an unsigned right-hand side. So the comparison might become true for negative start_secs which is interpreted as a (possibly very large) positive value. As a negative value can never be bigger than an unsigned value the correct representation of the (mathematical) comparison rtc->start_secs > rtc->range_max in C is: rtc->start_secs >= 0 && rtc->start_secs > rtc->range_max Use that to fix the offset calculation currently used in the rtc-mt6397 driver. Fixes: 989515647e783 ("rtc: Add one offset seconds to expand RTC range") Signed-off-by: Alexandre Mergnat Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-2-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit 1fd85fd8b7baf1ff9336fb4fd26e94a3ae2e1bf1 Author: Alexandre Mergnat Date: Mon Apr 28 12:06:47 2025 +0200 rtc: Make rtc_time64_to_tm() support dates before 1970 commit 7df4cfef8b351fec3156160bedfc7d6d29de4cce upstream. Conversion of dates before 1970 is still relevant today because these dates are reused on some hardwares to store dates bigger than the maximal date that is representable in the device's native format. This prominently and very soon affects the hardware covered by the rtc-mt6397 driver that can only natively store dates in the interval 1900-01-01 up to 2027-12-31. So to store the date 2028-01-01 00:00:00 to such a device, rtc_time64_to_tm() must do the right thing for time=-2208988800. Signed-off-by: Alexandre Mergnat Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250428-enable-rtc-v4-1-2b2f7e3f9349@baylibre.com Signed-off-by: Alexandre Belloni Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman commit f8a02b6e4f1e723149e1b52c01ea89a79f567487 Author: Sakari Ailus Date: Wed Apr 9 11:47:38 2025 +0300 Documentation: ACPI: Use all-string data node references commit 6db0261f3776bde01ae916ad8e1cb2ded3ba1a2b upstream. Document that references to data nodes shall use string-only references instead of a device reference and a succession of the first package entries of hierarchical data node references. Fixes: 9880702d123f ("ACPI: property: Support using strings in reference properties") Cc: 6.8+ # 6.8+ Signed-off-by: Sakari Ailus Link: https://patch.msgid.link/20250409084738.3657079-1-sakari.ailus@linux.intel.com [ rjw: Clarifying edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 047c59cafd599bf726bccbdd514affc8b6d4cae8 Author: Gautham R. Shenoy Date: Thu May 29 14:21:43 2025 +0530 acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() commit cb6a85f38f456b086c366e346ebb67ffa70c7243 upstream. commit 083466754596 ("cpufreq: ACPI: Fix max-frequency computation") modified get_max_boost_ratio() to return the nominal_freq advertised in the _CPC object. This was for the purposes of computing the maximum frequency. The frequencies advertised in _CPC objects are in MHz. However, cpufreq expects the frequency to be in KHz. Since the nominal_freq returned by get_max_boost_ratio() was not in KHz but instead in MHz,the cpuinfo_max_frequency that was computed using this nominal_freq was incorrect and an invalid value which resulted in cpufreq reporting the P0 frequency as the cpuinfo_max_freq. Fix this by converting the nominal_freq to KHz before returning the same from get_max_boost_ratio(). Reported-by: Manu Bretelle Closes: https://lore.kernel.org/lkml/aDaB63tDvbdcV0cg@HQ-GR2X1W2P57/ Fixes: 083466754596 ("cpufreq: ACPI: Fix max-frequency computation") Signed-off-by: Gautham R. Shenoy Cc: 6.14+ # 6.14+ Link: https://patch.msgid.link/20250529085143.709-1-gautham.shenoy@amd.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 2b291ad35e05eb13951e8fdd5894d87dff3ae5e8 Author: Pritam Manohar Sutar Date: Tue May 6 13:31:54 2025 +0530 clk: samsung: correct clock summary for hsi1 block commit 81214185e7e1fc6dfc8661a574c457accaf9a5a4 upstream. clk_summary shows wrong value for "mout_hsi1_usbdrd_user". It shows 400Mhz instead of 40Mhz as below. dout_shared2_div4 1 1 0 400000000 0 0 50000 Y ... mout_hsi1_usbdrd_user 0 0 0 400000000 0 0 50000 Y ... dout_clkcmu_hsi1_usbdrd 0 0 0 40000000 0 0 50000 Y ... Correct the clk_tree by adding correct clock parent for "mout_hsi1_usbdrd_user". Post this change, clk_summary shows correct value. dout_shared2_div4 1 1 0 400000000 0 0 50000 Y ... mout_clkcmu_hsi1_usbdrd 0 0 0 400000000 0 0 50000 Y ... dout_clkcmu_hsi1_usbdrd 0 0 0 40000000 0 0 50000 Y ... mout_hsi1_usbdrd_user 0 0 0 40000000 0 0 50000 Y ... Fixes: 485e13fe2fb6 ("clk: samsung: add top clock support for ExynosAuto v920 SoC") Cc: Signed-off-by: Pritam Manohar Sutar Reviewed-by: Alim Akhtar Link: https://lore.kernel.org/r/20250506080154.3995512-1-pritam.sutar@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit c8d01b8d843216beee6dec07c54dc20fb60d6c6a Author: Gabor Juhos Date: Wed May 14 21:18:33 2025 +0200 pinctrl: armada-37xx: set GPIO output value before setting direction commit e6ebd4942981f8ad37189bbb36a3c8495e21ef4c upstream. Changing the direction before updating the output value in the OUTPUT_VAL register may result in a glitch on the output line if the previous value in the OUTPUT_VAL register is different from the one we want to set. In order to avoid that, update the output value before changing the direction. Cc: stable@vger.kernel.org Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior") Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-2-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 5c512eb41b1d96aa47bf28f5af6ff6b5b521ee1f Author: Gabor Juhos Date: Wed May 14 21:18:32 2025 +0200 pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 commit 947c93eb29c2a581c0b0b6d5f21af3c2b7ff6d25 upstream. The controller has two consecutive OUTPUT_VAL registers and both holds output value for 32 GPIOs. Due to a missing adjustment, the current code always uses the first register while setting the output value whereas it should use the second one for GPIOs > 31. Add the missing armada_37xx_update_reg() call to adjust the register according to the 'offset' parameter of the function to fix the issue. Cc: stable@vger.kernel.org Fixes: 6702abb3bf23 ("pinctrl: armada-37xx: Fix direction_output() callback behavior") Signed-off-by: Imre Kaloz Reviewed-by: Andrew Lunn Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/20250514-pinctrl-a37xx-fixes-v2-1-07e9ac1ab737@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit aa3679d9f34f2e153003b00eb424d9ce629cafc0 Author: Pan Taixi Date: Mon May 26 09:37:31 2025 +0800 tracing: Fix compilation warning on arm32 commit 2fbdb6d8e03b70668c0876e635506540ae92ab05 upstream. On arm32, size_t is defined to be unsigned int, while PAGE_SIZE is unsigned long. This hence triggers a compilation warning as min() asserts the type of two operands to be equal. Casting PAGE_SIZE to size_t solves this issue and works on other target architectures as well. Compilation warning details: kernel/trace/trace.c: In function 'tracing_splice_read_pipe': ./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types lacks a cast (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) ^ ./include/linux/minmax.h:26:4: note: in expansion of macro '__typecheck' (__typecheck(x, y) && __no_side_effects(x, y)) ^~~~~~~~~~~ ... kernel/trace/trace.c:6771:8: note: in expansion of macro 'min' min((size_t)trace_seq_used(&iter->seq), ^~~ Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250526013731.1198030-1-pantaixi@huaweicloud.com Fixes: f5178c41bb43 ("tracing: Fix oob write in trace_seq_to_buffer()") Reviewed-by: Jeongjun Park Signed-off-by: Pan Taixi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman