commit fc85704c3dae5ac1cb3c94045727241cd72871ff
Author: Greg Kroah-Hartman
Date: Tue Jun 10 07:17:11 2025 -0400
Linux 6.15.2
Link: https://lore.kernel.org/r/20250607100719.711372213@linuxfoundation.org
Tested-by: Christian Heusel
Tested-by: Ronald Warsow
Tested-by: Salvatore Bonaccorso
Tested-by: Takeshi Ogasawara
Tested-by: Luna Jernberg
Tested-by: Ron Economos
Tested-by: Linux Kernel Functional Testing
Tested-by: Peter Schneider
Tested-by: Mark Brown
Tested-by: Jon Hunter
Signed-off-by: Greg Kroah-Hartman
commit c1c52720bb0fab4fe312de79080b90443289da58
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 b0814b391f44c25b86fd7c6cb0247b4ce7d98fc4
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 80671c454a2974a80f73eb14f021dbcde021a16e
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 5a25a9fe6ae72e6c88f926463dab95cd764fb771
Author: Krzysztof Kozlowski
Date: Mon Apr 28 09:52:44 2025 +0200
dt-bindings: remoteproc: qcom,sm8150-pas: Add missing SC8180X compatible
commit b278981b5ac109e6f6986b20a5cb19654aba8f68 upstream.
Commit 4b4ab93ddc5f ("dt-bindings: remoteproc: Consolidate SC8180X and
SM8150 PAS files") moved SC8180X bindings from separate file into this
one, but it forgot to add actual compatibles in top-level properties
section making the entire binding un-selectable (no-op) for SC8180X PAS.
Fixes: 4b4ab93ddc5f ("dt-bindings: remoteproc: Consolidate SC8180X and SM8150 PAS files")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski
Acked-by: Rob Herring (Arm)
Link: https://lore.kernel.org/r/20250428075243.44256-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson
Signed-off-by: Greg Kroah-Hartman
commit 5628b99316bcb5920a8b8e4df4b90b9d8fa171b4
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 cdb4feab2f39e75a66239e3a112beced279612a8
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 72a726fb5f25fbb31d6060acfb671c1955831245
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 aea61a1a77613d4184d7ebe7c1d7cb606458b43b
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 88953d793922e555480706e109b970e68aaf7c8c
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 93612604f4b59e96a3f070435f12b8fd3f9274bf
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 abaecb2a4ad021c2f2426e9b2a9c020aef57aca9
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 8b91e4b6b82b57499c939fa249cfae4c3070c0b9
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 f35a1e0b38d2724f338df2d3660927d8c4cd7a4e
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 f43c67847f70d2eef66c6fb7fcfb9e2f897ce637
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 144945bb0d6f44652ae47b749f7108e5ee71328a
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 fa4b47965c331eb6938d70285094156f3b198b2e
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 379dd295019c9e11d19f660a857170ee1bd74f63
Author: Kent Overstreet
Date: Mon Jun 2 19:48:27 2025 -0400
bcachefs: Fix subvol to missing root repair
commit 29cc6fb7c068c773049d3bde14b939033893eff4 upstream.
We had a bug where the root inode of a subvolume was erronously deleted:
bch2_evict_inode() called bch2_inode_rm(), meaning the VFS inode's
i_nlink was somehow set to 0 when it shouldn't have - the inode in the
btree indicated it clearly was not unlinked.
This has been addressed with additional safety checks in
bch2_inode_rm() - pulling in the safety checks we already were doing
when deleting unlinked inodes in recovery - but the really disastrous
bug was in check_subvols(), which on finding a dangling subvol (subvol
with a missing root inode) would delete the subvolume.
I assume this bug dates from early check_directory_structure() code,
which originally handled subvolumes and normal paths - the idea being
that still live contents of the subvolume would get reattached
somewhere.
But that's incorrect, and disastrously so; deleting a subvolume triggers
deleting the snapshot ID it points to, deleting the entire contents.
The correct way to repair is to recreate the root inode if it's missing;
then any contents will get reattached under that subvolume's lost+found.
Signed-off-by: Kent Overstreet
Signed-off-by: Greg Kroah-Hartman
commit 00d26f3a47e44bd7662de33b89dd84a3837e2959
Author: Kent Overstreet
Date: Mon Jun 2 17:43:36 2025 -0400
bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm()
commit 09fb85ae565645b982e9030dbb2ff6707f2cdddc upstream.
We had a bug where bch2_evict_inode() incorrectly called bch2_inode_rm()
- the journal clearly showed the inode was not unlinked.
We've got checks that we use in recovery when cleaning up deleted
inodes, lift them to bch2_inode_rm() as well.
Signed-off-by: Kent Overstreet
Signed-off-by: Greg Kroah-Hartman
commit fd1b2ef7216a29ad6a27ed43c7298ed8e4a9a0e7
Author: Kent Overstreet
Date: Mon Jun 2 18:26:44 2025 -0400
bcachefs: delete dead code from may_delete_deleted_inode()
commit bb6689bbeebc6fb51f0f120b486bdcc9a38ffcf6 upstream.
Signed-off-by: Kent Overstreet
Signed-off-by: Greg Kroah-Hartman
commit 66c36452163871360f15dc4042dd00612e42cd66
Author: Kent Overstreet
Date: Sat May 31 11:58:11 2025 -0400
bcachefs: Repair code for directory i_size
commit 36a2fdf7c5c1ccae6ca16cd14067567096cebe17 upstream.
We had a bug due due to an incomplete revert of the patch implementing
directory i_size (summing up the size of the dirents), leading to
completely screwy i_size values that underflow.
Most userspace programs don't seem to care (e.g. du ignores it), but it
turns out this broke sshfs, so needs to be repaired.
Signed-off-by: Kent Overstreet
Signed-off-by: Greg Kroah-Hartman
commit deaead8247f3de0ae5e7c5dcea55343d4320bdc0
Author: Kent Overstreet
Date: Sat May 31 18:32:37 2025 -0400
bcachefs: Kill un-reverted directory i_size code
commit 95fafc0f3407a6446082c11849df585bd3246571 upstream.
Signed-off-by: Kent Overstreet
Signed-off-by: Greg Kroah-Hartman
commit cea549ca705b3c0c657f5ef62e7926ad7e8ca342
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 aa9745977724d561245b11bb7999f6196ef076ea
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 9ebe21ede792cef851847648962c363cac67d17f
Author: NÃcolas F. R. A. Prado
Date: Tue May 20 17:15:58 2025 -0400
pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms
commit 1c9977b263475373b31bbf86af94a5c9ae2be42c upstream.
Commit 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple
addresses") introduced an access to the 'soc' field of struct
mtk_pinctrl in mtk_eint_do_init() and for that an include of
pinctrl-mtk-common-v2.h.
However, pinctrl drivers relying on the v1 common driver include
pinctrl-mtk-common.h instead, which provides another definition of
struct mtk_pinctrl that does not contain an 'soc' field.
Since mtk_eint_do_init() can be called both by v1 and v2 drivers, it
will now try to dereference an invalid pointer when called on v1
platforms. This has been observed on Genio 350 EVK (MT8365), which
crashes very early in boot (the kernel trace can only be seen with
earlycon).
In order to fix this, since 'struct mtk_pinctrl' was only needed to get
a 'struct mtk_eint_pin', make 'struct mtk_eint_pin' a parameter
of mtk_eint_do_init() so that callers need to supply it, removing
mtk_eint_do_init()'s dependency on any particular 'struct mtk_pinctrl'.
Fixes: 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses")
Suggested-by: AngeloGioacchino Del Regno
Signed-off-by: NÃcolas F. R. A. Prado
Link: https://lore.kernel.org/20250520-genio-350-eint-null-ptr-deref-fix-v2-1-6a3ca966a7ba@collabora.com
Signed-off-by: Linus Walleij
[ukleinek: backport to 6.15.y]
Signed-off-by: Uwe Kleine-König
Signed-off-by: Greg Kroah-Hartman
commit 7429b67b2447f43aa8bc4f9aacb04b323ad3de15
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 7a9b2536aaf7a26f76af1cf4f1822e4af54c650f
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 97a322d1c93df607e391983dda50da3a441c7fff
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 f87e3cf4b21bf3dd42831bc30d73e15aaf9117ac
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 921ae6204c04925c5286f2c654699641dd2bdcfe
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 4c487424273629820a1d06771bbb1dd4e420368d
Author: Ahmed Salem
Date: Fri Apr 25 21:31:05 2025 +0200
ACPICA: Apply ACPI_NONSTRING in more places
commit 70662db73d5455ebc8a1da29973fa70237b18cd2 upstream.
ACPICA commit 1035a3d453f7dd49a235a59ee84ebda9d2d2f41b
Add ACPI_NONSTRING for destination char arrays without a terminating NUL
character. This is a follow-up to commit 35ad99236f3a ("ACPICA: Apply
ACPI_NONSTRING") where not all instances received the same treatment, in
preparation for replacing strncpy() calls with memcpy()
Link: https://github.com/acpica/acpica/commit/1035a3d4
Signed-off-by: Ahmed Salem
Signed-off-by: Rafael J. Wysocki
Link: https://patch.msgid.link/3833065.MHq7AAxBmi@rjwysocki.net
Cc: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
commit 692b9698a252dd3477585b7bf33b1af7954c637d
Author: Kees Cook
Date: Fri Apr 25 21:28:34 2025 +0200
ACPICA: Apply ACPI_NONSTRING
commit 2b82118845e04c7adf4ece797150c19809bab29b upstream.
ACPICA commit ed68cb8e082e3bfbba02814af4fd5a61247f491b
Add ACPI_NONSTRING annotations for places found that are using char
arrays without a terminating NUL character. These were found during
Linux kernel builds and after looking for instances of arrays of size
ACPI_NAMESEG_SIZE.
Link: https://github.com/acpica/acpica/commit/ed68cb8e
Signed-off-by: Kees Cook
Signed-off-by: Rafael J. Wysocki
Link: https://patch.msgid.link/2039736.usQuhbGJ8B@rjwysocki.net
Cc: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
commit f1c9331f77e7a826ec2e7b45a52b8cc389348405
Author: Kees Cook
Date: Fri Apr 25 21:27:58 2025 +0200
ACPICA: Introduce ACPI_NONSTRING
commit 6da5e6f3028d46e4fee7849e85eda681939c630b upstream.
ACPICA commit 878823ca20f1987cba0c9d4c1056be0d117ea4fe
In order to distinguish character arrays from C Strings (i.e. strings with
a terminating NUL character), add support for the "nonstring" attribute
provided by GCC. (A better name might be "ACPI_NONCSTRING", but that's
the attribute name, so stick to the existing naming convention.)
GCC 15's -Wunterminated-string-initialization will warn about truncation
of the NUL byte for string initializers unless the destination is marked
with "nonstring". Prepare for applying this attribute to the project.
Link: https://github.com/acpica/acpica/commit/878823ca
Signed-off-by: Rafael J. Wysocki
Link: https://patch.msgid.link/1841930.VLH7GnMWUR@rjwysocki.net
Signed-off-by: Kees Cook
[ rjw: Pick up the tag from Kees ]
Signed-off-by: Rafael J. Wysocki
Cc: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
commit ca83fbe0b52f8643797e64ececbea41ffe5a9b94
Author: Rafael J. Wysocki
Date: Thu May 29 15:40:43 2025 +0200
Revert "x86/smp: Eliminate mwait_play_dead_cpuid_hint()"
commit 70523f335734b0b42f97647556d331edf684c7dc upstream.
Revert commit 96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()")
because it introduced a significant power regression on systems that
start with "nosmt" in the kernel command line.
Namely, on such systems, SMT siblings permanently go offline early,
when cpuidle has not been initialized yet, so after the above commit,
hlt_play_dead() is called for them. Later on, when the processor
attempts to enter a deep package C-state, including PC10 which is
requisite for reaching minimum power in suspend-to-idle, it is not
able to do that because of the SMT siblings staying in C1 (which
they have been put into by HLT).
As a result, the idle power (including power in suspend-to-idle)
rises quite dramatically on those systems with all of the possible
consequences, which (needless to say) may not be expected by their
users.
This issue is hard to debug and potentially dangerous, so it needs to
be addressed as soon as possible in a way that will work for 6.15.y,
hence the revert.
Of course, after this revert, the issue that commit 96040f7273e2
attempted to address will be back and it will need to be fixed again
later.
Fixes: 96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()")
Reported-by: Todd Brandt
Tested-by: Todd Brandt
Cc: 6.15+ # 6.15+
Signed-off-by: Rafael J. Wysocki
Acked-by: Dave Hansen
Link: https://patch.msgid.link/12674167.O9o76ZdvQC@rjwysocki.net
Signed-off-by: Greg Kroah-Hartman
commit 980f5b6c320998fe9714e10d6f858a13bb88622d
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