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 debugfs->status = ret;
return ret;
}
But "status" is u32 meaning unsigned wrap-around occurs when assigning a value which is
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 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