commit 7475d784169c7df48b0c55525fb862e06674d63c Author: Greg Kroah-Hartman Date: Thu Nov 13 15:34:41 2025 -0500 Linux 6.12.58 Link: https://lore.kernel.org/r/20251111004526.816196597@linuxfoundation.org Link: https://lore.kernel.org/r/20251111012348.571643096@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Brett A C Sheffield Tested-by: Slade Watkins Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: Brett Mastbergen Tested-by: Dileep Malepu Tested-by: Florian Fainelli Tested-by: Harshit Mogalapalli commit b12a603d2213c07fd1bb0127416da957e530b2d2 Author: Alex Hung Date: Wed Oct 22 16:19:34 2025 -0600 drm/amd/display: Fix black screen with HDMI outputs commit fdc93beeadc2439e5e85d056a8fe681dcced09da upstream. [Why & How] This fixes the black screen issue on certain APUs with HDMI, accompanied by the following messages: amdgpu 0000:c4:00.0: amdgpu: [drm] Failed to setup vendor info frame on connector DP-1: -22 amdgpu 0000:c4:00.0: [drm] Cannot find any crtc or sizes [drm] Cannot find any crtc or sizes Fixes: 489f0f600ce2 ("drm/amd/display: Fix DVI-D/HDMI adapters") Suggested-by: Timur Kristóf Reviewed-by: Harry Wentland Signed-off-by: Alex Hung Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 678c901443a6d2e909e3b51331a20f9d8f84ce82) Signed-off-by: Greg Kroah-Hartman commit f4fccd55e81d37390b124da8532dd9610b992889 Author: Srinivasan Shanmugam Date: Sun Aug 31 15:29:56 2025 +0530 drm/amdgpu: Fix function header names in amdgpu_connectors.c commit 38ab33dbea594700c8d6cc81eec0a54e95d3eb2f upstream. Align the function headers for `amdgpu_max_hdmi_pixel_clock` and `amdgpu_connector_dvi_mode_valid` with the function implementations so they match the expected kdoc style. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1199: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns the maximum supported HDMI (TMDS) pixel clock in KHz. drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:1212: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Validates the given display mode on DVI and HDMI connectors. Fixes: 585b2f685c56 ("drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)") Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 451cd07a8f9d457b0d5409c0c80b93887c21522d Author: Sathishkumar S Date: Mon Jul 28 18:27:06 2025 +0530 drm/amdgpu: Fix unintended error log in VCN5_0_0 commit 46b0e6b9d749cfa891e6969d6565be1131c53aa2 upstream. The error log is supposed to be gaurded under if failure condition. Fixes: faab5ea08367 ("drm/amdgpu: Check vcn sram load return value") Signed-off-by: Sathishkumar S Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3f916a93fc59895a5b18a604cf06ffb9ad96c3c7 Author: Punit Agrawal Date: Fri Oct 24 13:31:25 2025 +0100 ACPI: SPCR: Check for table version when using precise baudrate commit 543d35004007a06ef247acf2fc55efa8388aa741 upstream. Commit 4d330fe54145 ("ACPI: SPCR: Support Precise Baud Rate field") added support to use the precise baud rate available since SPCR 1.09 (revision 4) but failed to check the version of the table provided by the firmware. Accessing an older version of SPCR table causes accesses beyond the end of the table and can lead to garbage data to be used for the baud rate. Check the version of the firmware provided SPCR to ensure that the precise baudrate is vaild before using it. Fixes: 4d330fe54145 ("ACPI: SPCR: Support Precise Baud Rate field") Signed-off-by: Punit Agrawal Link: https://patch.msgid.link/20251024123125.1081612-1-punit.agrawal@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit a2dae25eb803ec9de2c1831d9409e6fca22809d4 Author: Krzysztof Kozlowski Date: Fri May 9 09:17:04 2025 +0200 extcon: adc-jack: Cleanup wakeup source only if it was enabled commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream. Driver in the probe enables wakeup source conditionally, so the cleanup path should do the same - do not release the wakeup source memory if it was not allocated. Link: https://lore.kernel.org/lkml/20250509071703.39442-2-krzysztof.kozlowski@linaro.org/ Reported-by: Christophe JAILLET Closes: https://lore.kernel.org/r/22aaebb7-553b-4571-8a43-58a523241082@wanadoo.fr/ Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman commit 86e7baf0ce1653f29342928069c64b451aa6f8cf Author: Melissa Wen Date: Thu Sep 11 14:21:19 2025 -0300 drm/amd/display: update color on atomic commit time commit 2f9c63883730a0bfecb086e6e59246933f936ca1 upstream. Use `atomic_commit_setup` to change the DC stream state. It's a preparation to remove from `atomic_check` changes in CRTC color components of DC stream state and prevent DC to commit TEST_ONLY changes. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/4444 Reviewed-by: Harry Wentland Signed-off-by: Melissa Wen Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1a9dcdabc81179ae73cdad553db7db88a4dbfd86 Author: Adrian Hunter Date: Fri Oct 24 11:59:16 2025 +0300 scsi: ufs: core: Add a quirk to suppress link_startup_again commit d34caa89a132cd69efc48361d4772251546fdb88 upstream. ufshcd_link_startup() has a facility (link_startup_again) to issue DME_LINKSTARTUP a 2nd time even though the 1st time was successful. Some older hardware benefits from that, however the behaviour is non-standard, and has been found to cause link startup to be unreliable for some Intel Alder Lake based host controllers. Add UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress link_startup_again, in preparation for setting the quirk for affected controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-3-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2d80fad2356ee5d02b5d80f12a6691c54445f052 Author: Adrian Hunter Date: Fri Oct 24 11:59:17 2025 +0300 scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel ADL commit d968e99488c4b08259a324a89e4ed17bf36561a4 upstream. Link startup becomes unreliable for Intel Alder Lake based host controllers when a 2nd DME_LINKSTARTUP is issued unnecessarily. Employ UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE to suppress that from happening. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-4-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 57a6a406f381c198897846ee7d3ddc319ad18c1a Author: Adrian Hunter Date: Fri Oct 24 11:59:15 2025 +0300 scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers commit bb44826c3bdbf1fa3957008a04908f45e5666463 upstream. Intel platforms with UFS, can support Suspend-to-Idle (S0ix) and Suspend-to-RAM (S3). For S0ix the link state should be HIBERNATE. For S3, state is lost, so the link state must be OFF. Driver policy, expressed by spm_lvl, can be 3 (link HIBERNATE, device SLEEP) for S0ix but must be changed to 5 (link OFF, device POWEROFF) for S3. Fix support for S0ix/S3 by switching spm_lvl as needed. During suspend ->prepare(), if the suspend target state is not Suspend-to-Idle, ensure the spm_lvl is at least 5 to ensure that resume will be possible from deep sleep states. During suspend ->complete(), restore the spm_lvl to its original value that is suitable for S0ix. This fix is first needed in Intel Alder Lake based controllers. Fixes: 7dc9fb47bc9a ("scsi: ufs: ufs-pci: Add support for Intel ADL") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251024085918.31825-2-adrian.hunter@intel.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c664eb11660399753ad076c46a05399c3d2b719c Author: Nathan Chancellor Date: Mon Nov 3 12:11:24 2025 -0700 lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream. Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o for GCC unconditionally because clang-min-version will always evaluate to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying the workaround for GCC, which is only needed for clang-17 and older. Cc: stable@vger.kernel.org Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") Signed-off-by: Nathan Chancellor Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20251103-curve25519-hacl64-fix-kasan-workaround-v2-1-ab581cbd8035@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 82fe78065450d2d07f36a22e2b6b44955cf5ca5b Author: Bui Quang Minh Date: Thu Oct 30 21:44:38 2025 +0700 virtio-net: fix received length check in big packets commit 0c716703965ffc5ef4311b65cb5d84a703784717 upstream. Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change. Fixes: 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets") Cc: stable@vger.kernel.org Signed-off-by: Bui Quang Minh Reviewed-by: Xuan Zhuo Tested-by: Lei Yang Link: https://patch.msgid.link/20251030144438.7582-1-minhquangbui99@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d990c7f180aa7c6ffd2c1b3c77160e50672039ce Author: Rong Zhang Date: Tue Oct 14 00:47:35 2025 +0800 drm/amd/display: Fix NULL deref in debugfs odm_combine_segments commit 6dd97ceb645c08aca9fc871a3006e47fe699f0ac upstream. When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx->stream_res.tg before dereferencing. Fixes: 07926ba8a44f ("drm/amd/display: Add debugfs interface for ODM combine info") Signed-off-by: Rong Zhang Reviewed-by: Mario Limoncello Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit f19bbecd34e3c15eed7e5e593db2ac0fc7a0e6d8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6519650838614b9054347f29d42b4717d389c944 Author: Alex Deucher Date: Fri Oct 24 13:08:11 2025 -0400 drm/amdgpu/smu: Handle S0ix for vangogh commit 7c5609b72bfe57d8c601d9561e0d2551b605c017 upstream. Fix the flows for S0ix. There is no need to stop rlc or reintialize PMFW in S0ix. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4659 Reviewed-by: Mario Limonciello Reported-by: Antheas Kapenekakis Tested-by: Antheas Kapenekakis Signed-off-by: Alex Deucher (cherry picked from commit fd39b5a5830d8f2553e0c09d4d50bdff28b10080) Cc: # c81f5cebe849: drm/amdgpu: Drop PMFW RLC notifier from amdgpu_device_suspend() Cc: Signed-off-by: Greg Kroah-Hartman commit 065bd62412271a2d734810dd50336cae88c54427 Author: Henrique Carvalho Date: Mon Nov 3 19:52:55 2025 -0300 smb: client: fix potential UAF in smb2_close_cached_fid() commit 734e99623c5b65bf2c03e35978a0b980ebc3c2f8 upstream. find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap. Fixes: ebe98f1447bb ("cifs: enable caching of directories for which a lease is held") Cc: stable@vger.kernel.org Reported-by: Jay Shin Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3d82cb8465718d0b3df4ad93fd01db34b48ffb3a Author: Joshua Rogers Date: Fri Nov 7 00:09:37 2025 +0800 smb: client: validate change notify buffer before copy commit 4012abe8a78fbb8869634130024266eaef7081fe upstream. SMB2_change_notify called smb2_validate_iov() but ignored the return code, then kmemdup()ed using server provided OutputBufferOffset/Length. Check the return of smb2_validate_iov() and bail out on error. Discovered with help from the ZeroPath security tooling. Signed-off-by: Joshua Rogers Reviewed-by: Paulo Alcantara (Red Hat) Cc: stable@vger.kernel.org Fixes: e3e9463414f61 ("smb3: improve SMB3 change notification support") Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a557649f0038e2aa39758053b5bb7322e42d872a Author: Mario Limonciello (AMD) Date: Thu Nov 6 12:28:54 2025 -0600 x86/microcode/AMD: Add more known models to entry sign checking commit d23550efc6800841b4d1639784afaebdea946ae0 upstream. Two Zen5 systems are missing from need_sha_check(). Add them. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://patch.msgid.link/20251106182904.4143757-1-superm1@kernel.org Signed-off-by: Greg Kroah-Hartman commit 97f01babb4593929e622324c87b29bc24d5bfbc9 Author: Yuta Hayama Date: Wed Oct 15 12:07:05 2025 +0900 rtc: rx8025: fix incorrect register reference commit 162f24cbb0f6ec596e7e9f3e91610d79dc805229 upstream. This code is intended to operate on the CTRL1 register, but ctrl[1] is actually CTRL2. Correctly, ctrl[0] is CTRL1. Signed-off-by: Yuta Hayama Fixes: 71af91565052 ("rtc: rx8025: fix 12/24 hour mode detection on RX-8035") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/eae5f479-5d28-4a37-859d-d54794e7628c@lineo.co.jp Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 9ac1f44723f26881b9fe7e69c7bc25397b879155 Author: Helge Deller Date: Mon Nov 3 22:38:26 2025 +0100 parisc: Avoid crash due to unaligned access in unwinder commit fd9f30d1038ee1624baa17a6ff11effe5f7617cb upstream. Guenter Roeck reported this kernel crash on his emulated B160L machine: Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0 While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock. Fix it by checking the alignment before accessing the memory. Reported-by: Guenter Roeck Signed-off-by: Helge Deller Tested-by: Guenter Roeck Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Greg Kroah-Hartman commit de7f2c67ceb1941b05b04ac35458a03e93cc57b1 Author: Jason Gunthorpe Date: Wed Oct 8 15:17:18 2025 -0300 iommufd: Don't overflow during division for dirty tracking commit cb30dfa75d55eced379a42fd67bd5fb7ec38555e upstream. If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows. Link: https://patch.msgid.link/r/0-v1-663679b57226+172-iommufd_dirty_div0_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support") Reviewed-by: Joao Martins Reviewed-by: Nicolin Chen Reviewed-by: Kevin Tian Reported-by: syzbot+093a8a8b859472e6c257@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=093a8a8b859472e6c257 Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 4b7d4aa5399b5a64caee639275615c63c008540d Author: Ilia Gavrilov Date: Mon Oct 20 15:12:55 2025 +0000 Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() commit 8d59fba49362c65332395789fd82771f1028d87e upstream. In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: db08722fc7d4 ("Bluetooth: hci_core: Fix missing instances using HCI_MAX_AD_LENGTH") Cc: stable@vger.kernel.org Signed-off-by: Ilia Gavrilov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 0d63031ee4a57be0252cb9a4e09ae921c75cece9 Author: Pierre-Eric Pelloux-Prayer Date: Tue Nov 4 10:53:57 2025 +0100 drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb commit 487df8b698345dd5a91346335f05170ed5f29d4e upstream. The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). Cc: stable@vger.kernel.org # v6.2+ Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini") Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13908 Reported-by: Mikhail Gavrilov Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Pierre-Eric Pelloux-Prayer [phasta: commit message nits] Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251104095358.15092-1-pierre-eric.pelloux-prayer@amd.com Signed-off-by: Greg Kroah-Hartman commit aa4be25f41f343b23d3ef6cb344740e03a72d7cf Author: Wayne Lin Date: Wed Nov 5 10:36:31 2025 +0800 drm/amd/display: Enable mst when it's detected but yet to be initialized commit 3c6a743c6961cc2cab453b343bb157d6bbbf8120 upstream. [Why] drm_dp_mst_topology_queue_probe() is used under the assumption that mst is already initialized. If we connect system with SST first then switch to the mst branch during suspend, we will fail probing topology by calling the wrong API since the mst manager is yet to be initialized. [How] At dm_resume(), once it's detected as mst branc connected, check if the mst is initialized already. If not, call dm_helpers_dp_mst_start_top_mgr() instead to initialize mst V2: Adjust the commit msg a bit Fixes: bc068194f548 ("drm/amd/display: Don't write DP_MSTM_CTRL after LT") Cc: Fangzhi Zuo Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Tom Chung Signed-off-by: Wayne Lin Signed-off-by: Alex Deucher (cherry picked from commit 62320fb8d91a0bddc44a228203cfa9bfbb5395bd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dc387c6def4dd39ac072673c797b58869151104f Author: Zilin Guan Date: Thu Nov 6 12:01:32 2025 +0000 tracing: Fix memory leaks in create_field_var() [ Upstream commit 80f0d631dcc76ee1b7755bfca1d8417d91d71414 ] The function create_field_var() allocates memory for 'val' through create_hist_field() inside parse_atom(), and for 'var' through create_var(), which in turn allocates var->type and var->var.name internally. Simply calling kfree() to release these structures will result in memory leaks. Use destroy_hist_field() to properly free 'val', and explicitly release the memory of var->type and var->var.name before freeing 'var' itself. Link: https://patch.msgid.link/20251106120132.3639920-1-zilin@seu.edu.cn Fixes: 02205a6752f22 ("tracing: Add support for 'field variables'") Signed-off-by: Zilin Guan Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 29d4429a993f10c5a9f55c265283c3fd4d0832f5 Author: Nikolay Aleksandrov Date: Wed Nov 5 13:19:19 2025 +0200 net: bridge: fix MST static key usage [ Upstream commit ee87c63f9b2a418f698d79c2991347e31a7d2c27 ] As Ido pointed out, the static key usage in MST is buggy and should use inc/dec instead of enable/disable because we can have multiple bridges with MST enabled which means a single bridge can disable MST for all. Use static_branch_inc/dec to avoid that. When destroying a bridge decrement the key if MST was enabled. Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: Ido Schimmel Closes: https://lore.kernel.org/netdev/20251104120313.1306566-1-razor@blackwall.org/T/#m6888d87658f94ed1725433940f4f4ebb00b5a68b Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20251105111919.1499702-3-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bf3843183bc3158e5821b46f330c438ae9bd6ddb Author: Nikolay Aleksandrov Date: Wed Nov 5 13:19:18 2025 +0200 net: bridge: fix use-after-free due to MST port state bypass [ Upstream commit 8dca36978aa80bab9d4da130c211db75c9e00048 ] syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: syzbot+dd280197f0f7ab3917be@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69088ffa.050a0220.29fc44.003d.GAE@google.com/ Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20251105111919.1499702-2-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c8ab03aa5bd9fd8bfe5d9552d8605826759fdd4d Author: Horatiu Vultur Date: Wed Nov 5 08:49:55 2025 +0100 lan966x: Fix sleeping in atomic context [ Upstream commit 0216721ce71252f60d89af49c8dff613358058d3 ] The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock. Fixes: 12c2d0a5b8e2 ("net: lan966x: add ethtool configuration and statistics") Signed-off-by: Horatiu Vultur Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20251105074955.1766792-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1884402c63349b67a1c19dbb9a34fc425f229ac2 Author: Tristram Ha Date: Tue Nov 4 19:37:41 2025 -0800 net: dsa: microchip: Fix reserved multicast address table programming [ Upstream commit 96baf482ca1f69f0da9d10a5bd8422c87ea9039e ] KSZ9477/KSZ9897 and LAN937X families of switches use a reserved multicast address table for some specific forwarding with some multicast addresses, like the one used in STP. The hardware assumes the host port is the last port in KSZ9897 family and port 5 in LAN937X family. Most of the time this assumption is correct but not in other cases like KSZ9477. Originally the function just setups the first entry, but the others still need update, especially for one common multicast address that is used by PTP operation. LAN937x also uses different register bits when accessing the reserved table. Fixes: 457c182af597 ("net: dsa: microchip: generic access to ksz9477 static and reserved table") Signed-off-by: Tristram Ha Tested-by: Łukasz Majewski Link: https://patch.msgid.link/20251105033741.6455-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6639a9c2fa6e5be172d72a74702753268d52a5be Author: Haotian Zhang Date: Wed Nov 5 11:47:16 2025 +0800 net: wan: framer: pef2256: Switch to devm_mfd_add_devices() [ Upstream commit 4d6ec3a7932ca5b168426f7b5b40abab2b41d2da ] The driver calls mfd_add_devices() but fails to call mfd_remove_devices() in error paths after successful MFD device registration and in the remove function. This leads to resource leaks where MFD child devices are not properly unregistered. Replace mfd_add_devices with devm_mfd_add_devices to automatically manage the device resources. Fixes: c96e976d9a05 ("net: wan: framer: Add support for the Lantiq PEF2256 framer") Suggested-by: Herve Codina Signed-off-by: Haotian Zhang Acked-by: Herve Codina Link: https://patch.msgid.link/20251105034716.662-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbc60375ff59b707a3a929e2a643b16a4f29760b Author: Dragos Tatulea Date: Tue Nov 4 08:48:34 2025 +0200 net/mlx5e: SHAMPO, Fix skb size check for 64K pages [ Upstream commit bacd8d80181ebe34b599a39aa26bf73a44c91e55 ] mlx5e_hw_gro_skb_has_enough_space() uses a formula to check if there is enough space in the skb frags to store more data. This formula is incorrect for 64K page sizes and it triggers early GRO session termination because the first fragment will blow up beyond GRO_LEGACY_MAX_SIZE. This patch adds a special case for page sizes >= GRO_LEGACY_MAX_SIZE (64K) which uses the skb->len instead. Within this context, the check is safe from fragment overflow because the hardware will continuously fill the data up to the reservation size of 64K and the driver will coalesce all data from the same page to the same fragment. This means that the data will span one fragment or at most two for such a large page size. It is expected that the if statement will be optimized out as the check is done with constants. Fixes: 92552d3abd32 ("net/mlx5e: HW_GRO cqe handler implementation") Signed-off-by: Dragos Tatulea Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/1762238915-1027590-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f04217a2925731f85db1bcfd806aff251a941563 Author: Meghana Malladi Date: Tue Nov 4 16:14:15 2025 +0530 net: ti: icssg-prueth: Fix fdb hash size configuration [ Upstream commit ae4789affd1e181ae46e72e2b5fbe2d6d7b6616a ] The ICSSG driver does the initial FDB configuration which includes setting the control registers. Other run time management like learning is managed by the PRU's. The default FDB hash size used by the firmware is 512 slots, which is currently missing in the current driver. Update the driver FDB config to include FDB hash size as well. Please refer trm [1] 6.4.14.12.17 section on how the FDB config register gets configured. From the table 6-1404, there is a reset field for FDB_HAS_SIZE which is 4, meaning 1024 slots. Currently the driver is not updating this reset value from 4(1024 slots) to 3(512 slots). This patch fixes this by updating the reset value to 512 slots. [1]: https://www.ti.com/lit/pdf/spruim2 Fixes: abd5576b9c57f ("net: ti: icssg-prueth: Add support for ICSSG switch firmware") Signed-off-by: Meghana Malladi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251104104415.3110537-1-m-malladi@ti.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6fc3fdc5ab190fbc05f6bda900597f74fda826a0 Author: Gal Pressman Date: Tue Nov 4 16:15:36 2025 +0200 net/mlx5e: Fix return value in case of module EEPROM read error [ Upstream commit d1c94bc5b90c21b65469d30d4a6bc8ed715c1bfe ] mlx5e_get_module_eeprom_by_page() has weird error handling. First, it is treating -EINVAL as a special case, but it is unclear why. Second, it tries to fail "gracefully" by returning the number of bytes read even in case of an error. This results in wrongly returning success (0 return value) if the error occurs before any bytes were read. Simplify the error handling by returning an error when such occurs. This also aligns with the error handling we have in mlx5e_get_module_eeprom() for the old API. This fixes the following case where the query fails, but userspace ethtool wrongly treats it as success and dumps an output: # ethtool -m eth2 netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5 netlink warning: mlx5_core: Query module eeprom by page failed, read 0 bytes, err -5 Offset Values ------ ------ 0x0000: 00 00 00 00 05 00 04 00 00 00 00 00 05 00 05 00 0x0010: 00 00 00 00 05 00 06 00 50 00 00 00 67 65 20 66 0x0020: 61 69 6c 65 64 2c 20 72 65 61 64 20 30 20 62 79 0x0030: 74 65 73 2c 20 65 72 72 20 2d 35 00 14 00 03 00 0x0040: 08 00 01 00 03 00 00 00 08 00 02 00 1a 00 00 00 0x0050: 14 00 04 00 08 00 01 00 04 00 00 00 08 00 02 00 0x0060: 0e 00 00 00 14 00 05 00 08 00 01 00 05 00 00 00 0x0070: 08 00 02 00 1a 00 00 00 14 00 06 00 08 00 01 00 Fixes: e109d2b204da ("net/mlx5: Implement get_module_eeprom_by_page()") Signed-off-by: Gal Pressman Reviewed-by: Alex Lazar Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://patch.msgid.link/1762265736-1028868-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e8fa86b0bd9687479dd2a7a8576ce7036dc1cab7 Author: Martin Willi Date: Mon Nov 3 09:24:36 2025 +0100 wifi: mac80211_hwsim: Limit destroy_on_close radio removal to netgroup [ Upstream commit c74619e7602e88a0239cd4999571dd31081e9adf ] hwsim radios marked destroy_on_close are removed when the Netlink socket that created them is closed. As the portid is not unique across network namespaces, closing a socket in one namespace may remove radios in another if it has the destroy_on_close flag set. Instead of matching the network namespace, match the netgroup of the radio to limit radio removal to those that have been created by the closing Netlink socket. The netgroup of a radio identifies the network namespace it was created in, and matching on it removes a destroy_on_close radio even if it has been moved to another namespace. Fixes: 100cb9ff40e0 ("mac80211_hwsim: Allow managing radios from non-initial namespaces") Signed-off-by: Martin Willi Link: https://patch.msgid.link/20251103082436.30483-1-martin@strongswan.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c43fe48a30ce2dcd8b7a567cf794b2ee1b28c82b Author: Hongguang Gao Date: Fri Nov 15 07:14:30 2024 -0800 bnxt_en: Add a 'force' parameter to bnxt_free_ctx_mem() [ Upstream commit 46010d43ab7b18fbc8a3a0bf4d65c775f8d2adbd ] If 'force' is false, it will keep the memory pages and all data structures for the context memory type if the memory is valid. This patch always passes true for the 'force' parameter so there is no change in behavior. Later patches will adjust the 'force' parameter for the FW log context memory types so that the logs will not be reset after FW reset. Signed-off-by: Hongguang Gao Signed-off-by: Michael Chan Link: https://patch.msgid.link/20241115151438.550106-5-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5204943a4c6e ("bnxt_en: Fix warning in bnxt_dl_reload_down()") Signed-off-by: Sasha Levin commit 48c3e656362f10ace6af0fa915090d3679a34441 Author: Hongguang Gao Date: Fri Nov 15 07:14:29 2024 -0800 bnxt_en: Refactor bnxt_free_ctx_mem() [ Upstream commit 968d2cc07c2fc9a508a53bd2de61200f50206fbc ] Add a new function bnxt_free_one_ctx_mem() to free one context memory type. bnxt_free_ctx_mem() now calls the new function in the loop to free each context memory type. There is no change in behavior. Later patches will further make use of the new function. Signed-off-by: Hongguang Gao Signed-off-by: Michael Chan Link: https://patch.msgid.link/20241115151438.550106-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5204943a4c6e ("bnxt_en: Fix warning in bnxt_dl_reload_down()") Signed-off-by: Sasha Levin commit 2b8503ddeb3bea5a0cf86035b6c11883147839ec Author: Shruti Parab Date: Fri Nov 15 07:14:28 2024 -0800 bnxt_en: Add mem_valid bit to struct bnxt_ctx_mem_type [ Upstream commit 0b350b4927e69d66629099dbb32cad8d2d56a26d ] Add a new bit to struct bnxt_ctx_mem_type to indicate that host memory has been successfully allocated for this context memory type. In the next patches, we'll be adding some additional context memory types for FW debugging/logging. If memory cannot be allocated for any of these new types, we will not abort and the cleared mem_valid bit will indicate to skip configuring the memory type. Reviewed-by: Hongguang Gao Signed-off-by: Shruti Parab Signed-of-by: Michael Chan Link: https://patch.msgid.link/20241115151438.550106-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Stable-dep-of: 5204943a4c6e ("bnxt_en: Fix warning in bnxt_dl_reload_down()") Signed-off-by: Sasha Levin commit 2c8ca35f5a2026d15abc0b770e50ce75fbb0f7f9 Author: Kalesh AP Date: Mon Nov 3 16:56:56 2025 -0800 bnxt_en: Fix a possible memory leak in bnxt_ptp_init [ Upstream commit deb8eb39164382f1f67ef8e8af9176baf5e10f2d ] In bnxt_ptp_init(), when ptp_clock_register() fails, the driver is not freeing the memory allocated for ptp_info->pin_config. Fix it to unconditionally free ptp_info->pin_config in bnxt_ptp_free(). Fixes: caf3eedbcd8d ("bnxt_en: 1PPS support for 5750X family chips") Reviewed-by: Pavan Chebbi Reviewed-by: Somnath Kotur Signed-off-by: Kalesh AP Signed-off-by: Michael Chan Link: https://patch.msgid.link/20251104005700.542174-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae811175cea35b03ac6d7c910f43a82a43b9c3b3 Author: Qendrim Maxhuni Date: Wed Oct 29 08:57:44 2025 +0100 net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup [ Upstream commit e120f46768d98151ece8756ebd688b0e43dc8b29 ] Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0 Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support") Signed-off-by: Qendrim Maxhuni Link: https://patch.msgid.link/20251029075744.105113-1-qendrim.maxhuni@garderos.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8ed6059c2c4b633f6a4734e1aa9fdb769b210e6a Author: Mohammad Heib Date: Fri Oct 31 17:52:03 2025 +0200 net: ionic: map SKB after pseudo-header checksum prep [ Upstream commit de0337d641bfa5b6d6b489e479792f1039274e84 ] The TSO path called ionic_tx_map_skb() before preparing the TCP pseudo checksum (ionic_tx_tcp_[inner_]pseudo_csum()), which may perform skb_cow_head() and might modifies bytes in the linear header area. Mapping first and then mutating the header risks: - Using a stale DMA address if skb_cow_head() relocates the head, and/or - Device reading stale header bytes on weakly-ordered systems (CPU writes after mapping are not guaranteed visible without an explicit dma_sync_single_for_device()). Reorder the TX path to perform all header mutations (including skb_cow_head()) *before* DMA mapping. Mapping is now done only after the skb layout and header contents are final. This removes the need for any post-mapping dma_sync and prevents on-wire corruption observed under VLAN+TSO load after repeated runs. This change is purely an ordering fix; no functional behavior change otherwise. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Mohammad Heib Reviewed-by: Brett Creeley Link: https://patch.msgid.link/20251031155203.203031-2-mheib@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75d8062e9056aead115587ea490f04d8a8368bba Author: Mohammad Heib Date: Fri Oct 31 17:52:02 2025 +0200 net: ionic: add dma_wmb() before ringing TX doorbell [ Upstream commit d261f5b09c28850dc63ca1d3018596f829f402d5 ] The TX path currently writes descriptors and then immediately writes to the MMIO doorbell register to notify the NIC. On weakly ordered architectures, descriptor writes may still be pending in CPU or DMA write buffers when the doorbell is issued, leading to the device fetching stale or incomplete descriptors. Add a dma_wmb() in ionic_txq_post() to ensure all descriptor writes are visible to the device before the doorbell MMIO write. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Mohammad Heib Link: https://patch.msgid.link/20251031155203.203031-1-mheib@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a10496048cc57ae05d950c00bee97704dcbd5259 Author: Stefan Wiehler Date: Tue Oct 28 17:12:28 2025 +0100 sctp: Hold sock lock while iterating over address list [ Upstream commit f1fc201148c7e684c10a72b6a3375597f28d1ef6 ] Move address list traversal in inet_assoc_attr_size() under the sock lock to avoid holding the RCU read lock. Suggested-by: Xin Long Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-4-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2fe08fcaacb7eb019fa9c81db39b2214de216677 Author: Stefan Wiehler Date: Tue Oct 28 17:12:27 2025 +0100 sctp: Prevent TOCTOU out-of-bounds write [ Upstream commit 95aef86ab231f047bb8085c70666059b58f53c09 ] For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use). Suggested-by: Kuniyuki Iwashima Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Reviewed-by: Kuniyuki Iwashima Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-3-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97a2bb90a6b64b9693a5e88a69007d0ffbd6accf Author: Stefan Wiehler Date: Tue Oct 28 17:12:26 2025 +0100 sctp: Hold RCU read lock while iterating over address list [ Upstream commit 38f50242bf0f237cdc262308d624d333286ec3c5 ] With CONFIG_PROVE_RCU_LIST=y and by executing $ netcat -l --sctp & $ netcat --sctp localhost & $ ss --sctp one can trigger the following Lockdep-RCU splat(s): WARNING: suspicious RCU usage 6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted ----------------------------- net/sctp/diag.c:76 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by ss/215: #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0 #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200 stack backtrace: CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x90 lockdep_rcu_suspicious.cold+0x4e/0xa3 inet_sctp_diag_fill.isra.0+0x4b1/0x5d0 sctp_sock_dump+0x131/0x200 sctp_transport_traverse_process+0x170/0x1b0 ? __pfx_sctp_sock_filter+0x10/0x10 ? __pfx_sctp_sock_dump+0x10/0x10 sctp_diag_dump+0x103/0x140 __inet_diag_dump+0x70/0xb0 netlink_dump+0x148/0x490 __netlink_dump_start+0x1f3/0x2b0 inet_diag_handler_cmd+0xcd/0x100 ? __pfx_inet_diag_dump_start+0x10/0x10 ? __pfx_inet_diag_dump+0x10/0x10 ? __pfx_inet_diag_dump_done+0x10/0x10 sock_diag_rcv_msg+0x18e/0x320 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x4d/0x100 netlink_unicast+0x1d7/0x2b0 netlink_sendmsg+0x203/0x450 ____sys_sendmsg+0x30c/0x340 ___sys_sendmsg+0x94/0xf0 __sys_sendmsg+0x83/0xf0 do_syscall_64+0xbb/0x390 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Signed-off-by: Stefan Wiehler Reviewed-by: Kuniyuki Iwashima Acked-by: Xin Long Link: https://patch.msgid.link/20251028161506.3294376-2-stefan.wiehler@nokia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a366a1544e51126f06a28015bcc36c1f1bb3a8aa Author: Jonas Gorski Date: Sun Nov 2 11:07:57 2025 +0100 net: dsa: b53: stop reading ARL entries if search is done [ Upstream commit 0be04b5fa62a82a9929ca261f6c9f64a3d0a28da ] The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it finished traversing the ARL table. This means that there will be no valid result, so we should not attempt to read and process any further entries. We only ever check the validity of the entries for 4 ARL bin chips, and only after having passed the first entry to the b53_fdb_copy(). This means that we always pass an invalid entry at the end to the b53_fdb_copy(). b53_fdb_copy() does check the validity though before passing on the entry, so it never gets passed on. On < 4 ARL bin chips, we will even continue reading invalid entries until we reach the result limit. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251102100758.28352-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7236a4840b4bed8d4c2dd882fd75de5f00a3af9b Author: Jonas Gorski Date: Sun Nov 2 11:07:56 2025 +0100 net: dsa: b53: fix enabling ip multicast [ Upstream commit c264294624e956a967a9e2e5fa41e3273340b089 ] In the New Control register bit 1 is either reserved, or has a different function: Out of Range Error Discard When enabled, the ingress port discards any frames if the Length field is between 1500 and 1536 (excluding 1500 and 1536) and with good CRC. The actual bit for enabling IP multicast is bit 0, which was only explicitly enabled for BCM5325 so far. For older switch chips, this bit defaults to 0, so we want to enable it as well, while newer switch chips default to 1, and their documentation says "It is illegal to set this bit to zero." So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit also for other switch chips. While at it, rename it to (B53_)IP_MC as that is how it is called in Broadcom code. Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251102100758.28352-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 734a04aa66477a9764d39d57cd8c9eb675ccfc82 Author: Jonas Gorski Date: Sat Nov 1 14:28:07 2025 +0100 net: dsa: b53: fix bcm63xx RGMII port link adjustment [ Upstream commit 3e4ebdc1606adf77744cf8ed7a433d279fdc57ba ] BCM63XX's switch does not support MDIO scanning of external phys, so its MACs needs to be manually configured for autonegotiated link speeds. So b53_force_port_config() and b53_force_link() accordingly also when mode is MLO_AN_PHY for those ports. Fixes lower speeds than 1000/full on rgmii ports 4 - 7. This aligns the behaviour with the old bcm63xx_enetsw driver for those ports. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251101132807.50419-3-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a8d24ef5272fc9396c85fd22cbd34aeeefedd2e Author: Jonas Gorski Date: Sat Nov 1 14:28:06 2025 +0100 net: dsa: b53: fix resetting speed and pause on forced link [ Upstream commit b6a8a5477fe9bd6be2b594a88f82f8bba41e6d54 ] There is no guarantee that the port state override registers have their default values, as not all switches support being reset via register or have a reset GPIO. So when forcing port config, we need to make sure to clear all fields, which we currently do not do for the speed and flow control configuration. This can cause flow control stay enabled, or in the case of speed becoming an illegal value, e.g. configured for 1G (0x2), then setting 100M (0x1), results in 0x3 which is invalid. For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on supported chips, as the bit can have different meanings on other chips, e.g. for BCM5389 this controls scanning PHYs for link/speed configuration. Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters") Signed-off-by: Jonas Gorski Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251101132807.50419-2-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 70180a6031056096c93ed2f47c41803268bdd91c Author: Bartosz Golaszewski Date: Mon Nov 3 15:11:32 2025 +0100 gpiolib: fix invalid pointer access in debugfs [ Upstream commit 2f6115ad8864cf3f48598f26c74c7c8e5c391919 ] If the memory allocation in gpiolib_seq_start() fails, the s->private field remains uninitialized and is later dereferenced without checking in gpiolib_seq_stop(). Initialize s->private to NULL before calling kzalloc() and check it before dereferencing it. Fixes: e348544f7994 ("gpio: protect the list of GPIO devices with SRCU") Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20251103141132.53471-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5a0aca55e84d931ea0bda8e3ea4bc036784b7eeb Author: Bartosz Golaszewski Date: Mon Nov 3 10:35:24 2025 +0100 gpio: swnode: don't use the swnode's name as the key for GPIO lookup [ Upstream commit e5d527be7e6984882306b49c067f1fec18920735 ] Looking up a GPIO controller by label that is the name of the software node is wonky at best - the GPIO controller driver is free to set a different label than the name of its firmware node. We're already being passed a firmware node handle attached to the GPIO device to swnode_get_gpio_device() so use it instead for a more precise lookup. Acked-by: Linus Walleij Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes") Link: https://lore.kernel.org/r/20251103-reset-gpios-swnodes-v4-4-6461800b6775@linaro.org Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit a4a701a81600624d57e58318f17aa800143f4d09 Author: Hangbin Liu Date: Thu Oct 30 07:35:39 2025 +0000 net: vlan: sync VLAN features with lower device [ Upstream commit c211f5d7cbd5cb34489d526648bb9c8ecc907dee ] After registering a VLAN device and setting its feature flags, we need to synchronize the VLAN features with the lower device. For example, the VLAN device does not have the NETIF_F_LRO flag, it should be synchronized with the lower device based on the NETIF_F_UPPER_DISABLES definition. As the dev->vlan_features has changed, we need to call netdev_update_features(). The caller must run after netdev_upper_dev_link() links the lower devices, so this patch adds the netdev_update_features() call in register_vlan_dev(). Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack") Signed-off-by: Hangbin Liu Link: https://patch.msgid.link/20251030073539.133779-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c62376b938e69d9d057d4d2f4fa9d61e6bcfa43a Author: Wang Liang Date: Thu Oct 30 12:03:40 2025 +0800 selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing ethtool-common.sh [ Upstream commit d01f8136d46b925798abcf86b35a4021e4cfb8bb ] The script "ethtool-common.sh" is not installed in INSTALL_PATH, and triggers some errors when I try to run the test 'drivers/net/netdevsim/ethtool-coalesce.sh': TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # ./ethtool-coalesce.sh: line 4: ethtool-common.sh: No such file or directory # ./ethtool-coalesce.sh: line 25: make_netdev: command not found # ethtool: bad command line argument(s) # ./ethtool-coalesce.sh: line 124: check: command not found # ./ethtool-coalesce.sh: line 126: [: -eq: unary operator expected # FAILED /0 checks not ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh # exit=1 Install this file to avoid this error. After this patch: TAP version 13 1..1 # timeout set to 600 # selftests: drivers/net/netdevsim: ethtool-coalesce.sh # PASSED all 22 checks ok 1 selftests: drivers/net/netdevsim: ethtool-coalesce.sh Fixes: fbb8531e58bd ("selftests: extract common functions in ethtool-common.sh") Signed-off-by: Wang Liang Link: https://patch.msgid.link/20251030040340.3258110-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 91e2fe103be15ee1339066f0731c71ec54f445e5 Author: Anubhav Singh Date: Thu Oct 30 06:04:36 2025 +0000 selftests/net: use destination options instead of hop-by-hop [ Upstream commit f8e8486702abb05b8c734093aab1606af0eac068 ] The GRO self-test, gro.c, currently constructs IPv6 packets containing a Hop-by-Hop Options header (IPPROTO_HOPOPTS) to ensure the GRO path correctly handles IPv6 extension headers. However, network elements may be configured to drop packets with the Hop-by-Hop Options header (HBH). This causes the self-test to fail in environments where such network elements are present. To improve the robustness and reliability of this test in diverse network environments, switch from using IPPROTO_HOPOPTS to IPPROTO_DSTOPTS (Destination Options). The Destination Options header is less likely to be dropped by intermediate routers and still serves the core purpose of the test: validating GRO's handling of an IPv6 extension header. This change ensures the test can execute successfully without being incorrectly failed by network policies outside the kernel's control. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn Signed-off-by: Anubhav Singh Link: https://patch.msgid.link/20251030060436.1556664-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3293a08538ffbbf1bbb11d43c1d2f7e49df9304d Author: Anubhav Singh Date: Thu Oct 30 06:28:18 2025 +0000 selftests/net: fix out-of-order delivery of FIN in gro:tcp test [ Upstream commit 02d064de05b1fcca769391fa82d205bed8bb9bf0 ] Due to the gro_sender sending data packets and FIN packets in very quick succession, these are received almost simultaneously by the gro_receiver. FIN packets are sometimes processed before the data packets leading to intermittent (~1/100) test failures. This change adds a delay of 100ms before sending FIN packets in gro:tcp test to avoid the out-of-order delivery. The same mitigation already exists for the gro:ip test. Fixes: 7d1575014a63 ("selftests/net: GRO coalesce test") Reviewed-by: Willem de Bruijn Signed-off-by: Anubhav Singh Link: https://patch.msgid.link/20251030062818.1562228-1-anubhavsinggh@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 02c492301a6039c74a3415ba433ead31da2eb32d Author: Jonas Gorski Date: Mon Oct 27 20:46:21 2025 +0100 net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xx [ Upstream commit 3d18a84eddde169d6dbf3c72cc5358b988c347d0 ] The internal switch on BCM63XX SoCs will unconditionally add 802.1Q VLAN tags on egress to CPU when 802.1Q mode is enabled. We do this unconditionally since commit ed409f3bbaa5 ("net: dsa: b53: Configure VLANs while not filtering"). This is fine for VLAN aware bridges, but for standalone ports and vlan unaware bridges this means all packets are tagged with the default VID, which is 0. While the kernel will treat that like untagged, this can break userspace applications processing raw packets, expecting untagged traffic, like STP daemons. This also breaks several bridge tests, where the tcpdump output then does not match the expected output anymore. Since 0 isn't a valid VID, just strip out the VLAN tag if we encounter it, unless the priority field is set, since that would be a valid tag again. Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags") Signed-off-by: Jonas Gorski Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20251027194621.133301-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc4bb4ed4387d45e266ce92f6322e06c758d7490 Author: Álvaro Fernández Rojas Date: Sat Jun 14 09:59:47 2025 +0200 net: dsa: tag_brcm: legacy: reorganize functions [ Upstream commit a4daaf063f8269a5881154c5b77c5ef6639d65d3 ] Move brcm_leg_tag_rcv() definition to top. This function is going to be shared between two different tags. Reviewed-by: Florian Fainelli Signed-off-by: Álvaro Fernández Rojas Link: https://patch.msgid.link/20250614080000.1884236-2-noltari@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 3d18a84eddde ("net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for bcm63xx") Signed-off-by: Sasha Levin commit 0545cc1a4a02066a5807c58361894bb5d2561fa8 Author: Abdun Nihaal Date: Tue Oct 28 23:26:30 2025 +0530 Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2() [ Upstream commit 1c21cf89a66413eb04b2d22c955b7a50edc14dfa ] The memory allocated for ptr using kvmalloc() is not freed on the last error path. Fix that by freeing it on that error path. Fixes: 9a24ce5e29b1 ("Bluetooth: btrtl: Firmware format v2 support") Signed-off-by: Abdun Nihaal Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cf2c2acec1cf456c3d11c11a7589e886a0f963a9 Author: Raphael Pinsonneault-Thibeault Date: Fri Oct 24 12:29:10 2025 -0400 Bluetooth: hci_event: validate skb length for unknown CC opcode [ Upstream commit 5c5f1f64681cc889d9b13e4a61285e9e029d6ab5 ] In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data. Reported-by: syzbot+a9a4bedfca6aa9d7fa24@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a9a4bedfca6aa9d7fa24 Tested-by: syzbot+a9a4bedfca6aa9d7fa24@syzkaller.appspotmail.com Fixes: afcb3369f46ed ("Bluetooth: hci_event: Fix vendor (unknown) opcode status handling") Signed-off-by: Raphael Pinsonneault-Thibeault Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c849e6941fec2742a7c7e1634f25e530e39acea7 Author: Josephine Pfeiffer Date: Mon Oct 27 11:40:43 2025 -0600 riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro [ Upstream commit a74f038fa50e0d33b740f44f862fe856f16de6a8 ] The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of seq_puts(). This is both a performance issue and conceptually wrong, as the macro name suggests plain string output (puts) but the implementation uses formatted output (printf). The macro is used in ptdump.c:301 to output a newline character. Using seq_printf() adds unnecessary overhead for format string parsing when outputting this constant string. This bug was introduced in commit 59c4da8640cc ("riscv: Add support to dump the kernel page tables") in 2020, which copied the implementation pattern from other architectures that had the same bug. Fixes: 59c4da8640cc ("riscv: Add support to dump the kernel page tables") Signed-off-by: Josephine Pfeiffer Link: https://lore.kernel.org/r/20251018170451.3355496-1-hi@josie.lol Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 27379fcc15a10d3e3780fe79ba3fc7ed1ccd78e2 Author: Chunyan Zhang Date: Mon Oct 27 11:40:43 2025 -0600 riscv: stacktrace: Disable KASAN checks for non-current tasks [ Upstream commit 060ea84a484e852b52b938f234bf9b5503a6c910 ] Unwinding the stack of a task other than current, KASAN would report "BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly") Co-developed-by: Jiakai Xu Signed-off-by: Jiakai Xu Signed-off-by: Chunyan Zhang Link: https://lore.kernel.org/r/20251022072608.743484-1-zhangchunyan@iscas.ac.cn [pjw@kernel.org: clean up checkpatch issues] Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit f0b3ecdbb5bbee8ca6b2892aba3988c8a3ce858e Author: Jiawen Wu Date: Tue Nov 4 14:23:21 2025 +0800 net: libwx: fix device bus LAN ID commit a04ea57aae375bdda1cb57034d8bcbb351e1f973 upstream. The device bus LAN ID was obtained from PCI_FUNC(), but when a PF port is passthrough to a virtual machine, the function number may not match the actual port index on the device. This could cause the driver to perform operations such as LAN reset on the wrong port. Fix this by reading the LAN ID from port status register. Fixes: a34b3e6ed8fb ("net: txgbe: Store PCI info") Cc: stable@vger.kernel.org Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/B60A670C1F52CB8E+20251104062321.40059-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b42dbef4f208326271434d5ab71c4129a3ddd1a9 Author: Steven Rostedt Date: Thu Oct 16 13:28:48 2025 -0400 ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up commit aa997d2d2a0b2e76f4df0f1f12829f02acb4fb6b upstream. The function ring_buffer_map_get_reader() is a bit more strict than the other get reader functions, and except for certain situations the rb_get_reader_page() should not return NULL. If it does, it triggers a warning. This warning was triggering but after looking at why, it was because another acceptable situation was happening and it wasn't checked for. If the reader catches up to the writer and there's still data to be read on the reader page, then the rb_get_reader_page() will return NULL as there's no new page to get. In this situation, the reader page should not be updated and no warning should trigger. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Vincent Donnefort Reported-by: syzbot+92a3745cea5ec6360309@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/690babec.050a0220.baf87.0064.GAE@google.com/ Link: https://lore.kernel.org/20251016132848.1b11bb37@gandalf.local.home Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 77d4afd6c78b549bdc267f662399c82d70f0b7a1 Author: Baochen Qiang Date: Mon Oct 27 09:49:12 2025 +0800 Revert "wifi: ath10k: avoid unnecessary wait for service ready message" commit 2469bb6a6af944755a7d7daf66be90f3b8decbf9 upstream. This reverts commit 51a73f1b2e56b0324b4a3bb8cebc4221b5be4c7a. Although this commit benefits QCA6174, it breaks QCA988x and QCA9984 [1][2]. Since it is not likely to root cause/fix this issue in a short time, revert it to get those chips back. Compile tested only. Fixes: 51a73f1b2e56 ("wifi: ath10k: avoid unnecessary wait for service ready message") Link: https://lore.kernel.org/ath10k/6d41bc00602c33ffbf68781f563ff2e6c6915a3e.camel@gmail.com # [1] Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220671 # [2] Signed-off-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251027-ath10k-revert-polling-first-change-v1-1-89aaf3bcbfa1@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 0eaa0a3dfe218c4cf1a0782ccbbc9e3931718f17 Author: Ariel D'Alessandro Date: Fri Oct 24 17:27:56 2025 -0300 drm/mediatek: Disable AFBC support on Mediatek DRM driver commit 9882a40640036d5bbc590426a78981526d4f2345 upstream. Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa. Fixes: c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") Cc: stable@vger.kernel.org Signed-off-by: Ariel D'Alessandro Reviewed-by: Daniel Stone Reviewed-by: CK Hu Reviewed-by: Macpaul Lin Link: https://patchwork.kernel.org/project/dri-devel/patch/20251024202756.811425-1-ariel.dalessandro@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit a6a493b985bfffac097a4e1be09f98b27729dca8 Author: Marek Szyprowski Date: Thu Oct 23 16:26:34 2025 +0200 media: videobuf2: forbid remove_bufs when legacy fileio is active commit 27afd6e066cfd80ddbe22a4a11b99174ac89cced upstream. vb2_ioctl_remove_bufs() call manipulates queue internal buffer list, potentially overwriting some pointers used by the legacy fileio access mode. Forbid that ioctl when fileio is active to protect internal queue state between subsequent read/write calls. CC: stable@vger.kernel.org Fixes: a3293a85381e ("media: v4l2: Add REMOVE_BUFS ioctl") Reported-by: Shuangpeng Bai Closes: https://lore.kernel.org/linux-media/5317B590-AAB4-4F17-8EA1-621965886D49@psu.edu/ Signed-off-by: Marek Szyprowski Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d3ecc18281d3deadc510637921ccc282501b206d Author: Ricardo Ribalda Date: Tue Oct 21 10:36:17 2025 +0000 media: uvcvideo: Use heuristic to find stream entity commit 758dbc756aad429da11c569c0d067f7fd032bcf7 upstream. Some devices, like the Grandstream GUV3100 webcam, have an invalid UVC descriptor where multiple entities share the same ID, this is invalid and makes it impossible to make a proper entity tree without heuristics. We have recently introduced a change in the way that we handle invalid entities that has caused a regression on broken devices. Implement a new heuristic to handle these devices properly. Reported-by: Angel4005 Closes: https://lore.kernel.org/linux-media/CAOzBiVuS7ygUjjhCbyWg-KiNx+HFTYnqH5+GJhd6cYsNLT=DaA@mail.gmail.com/ Fixes: 0e2ee70291e6 ("media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID") Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Reviewed-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit e2b3859067bf012d53c49b3f885fef40624a2c83 Author: Qu Wenruo Date: Thu Oct 23 19:44:04 2025 +1030 btrfs: ensure no dirty metadata is written back for an fs with errors commit 2618849f31e7cf51fadd4a5242458501a6d5b315 upstream. [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs. CC: stable@vger.kernel.org # 6.6+ Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 228573280db98e649e8315ea2432840246e6493f Author: Kailang Yang Date: Tue Aug 19 14:03:44 2025 +0800 ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again [ Upstream commit f4b3cef55f5f96fdb4e7f9ca90b7d6213689faeb ] There was a similar bug in the past (Bug 217440), which was fixed for this laptop. The same issue is occurring again as of kernel v.6.12.2. The symptoms are very similar - initially audio works but after a warm reboot, the audio completely disappears until the computer is powered off (there is no audio output at all). The issue is also related by caused by a different change now. By bisecting different kernel versions, I found that reverting cc3d0b5dd989 in patch_realtek.c[*] restores the sound and it works fine after the reboot. [*] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?h=v6.12.2&id=4ed7f16070a8475c088ff423b2eb11ba15eb89b6 [ patch description reformatted by tiwai ] Fixes: cc3d0b5dd989 ("ALSA: hda/realtek: Update ALC256 depop procedure") Link: https://bugzilla.kernel.org/show_bug.cgi?id=220109 Signed-off-by: Kailang Yang Link: https://lore.kernel.org/5317ca723c82447a938414fcca85cbf5@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9d4583a57fcc7153a23746a3941d16ebca93d125 Author: Linus Torvalds Date: Tue Nov 4 15:25:20 2025 +0900 x86: uaccess: don't use runtime-const rewriting in modules [ Upstream commit 284922f4c563aa3a8558a00f2a05722133237fe8 ] The runtime-const infrastructure was never designed to handle the modular case, because the constant fixup is only done at boot time for core kernel code. But by the time I used it for the x86-64 user space limit handling in commit 86e6b1547b3d ("x86: fix user address masking non-canonical speculation issue"), I had completely repressed that fact. And it all happens to work because the only code that currently actually gets inlined by modules is for the access_ok() limit check, where the default constant value works even when not fixed up. Because at least I had intentionally made it be something that is in the non-canonical address space region. But it's technically very wrong, and it does mean that at least in theory, the use of 'access_ok()' + '__get_user()' can trigger the same speculation issue with non-canonical addresses that the original commit was all about. The pattern is unusual enough that this probably doesn't matter in practice, but very wrong is still very wrong. Also, let's fix it before the nice optimized scoped user accessor helpers that Thomas Gleixner is working on cause this pseudo-constant to then be more widely used. This all came up due to an unrelated discussion with Mateusz Guzik about using the runtime const infrastructure for names_cachep accesses too. There the modular case was much more obviously broken, and Mateusz noted it in his 'v2' of the patch series. That then made me notice how broken 'access_ok()' had been in modules all along. Mea culpa, mea maxima culpa. Fix it by simply not using the runtime-const code in modules, and just using the USER_PTR_MAX variable value instead. This is not performance-critical like the core user accessor functions (get_user() and friends) are. Also make sure this doesn't get forgotten the next time somebody wants to do runtime constant optimizations by having the x86 runtime-const.h header file error out if included by modules. Fixes: 86e6b1547b3d ("x86: fix user address masking non-canonical speculation issue") Acked-by: Borislav Petkov Acked-by: Sean Christopherson Cc: Thomas Gleixner Triggered-by: Mateusz Guzik Link: https://lore.kernel.org/all/20251030105242.801528-1-mjguzik@gmail.com/ Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 822166b6b764c4b49fb1bfaf1b439aae286bfc08 Author: Kirill A. Shutemov Date: Tue Mar 4 17:33:42 2025 +0200 x86/runtime-const: Add the RUNTIME_CONST_PTR assembly macro [ Upstream commit bd72baff229920da1d57c14364c11ecdbaf5b458 ] Add an assembly macro to refer runtime cost. It hides linker magic and makes assembly more readable. Signed-off-by: Kirill A. Shutemov Signed-off-by: Ingo Molnar Cc: Brian Gerst Cc: H. Peter Anvin Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250304153342.2016569-1-kirill.shutemov@linux.intel.com Stable-dep-of: 284922f4c563 ("x86: uaccess: don't use runtime-const rewriting in modules") Signed-off-by: Sasha Levin commit 141a3e658b6bc4d30069afa6de656b0e1980a100 Author: Linus Torvalds Date: Tue Dec 10 10:25:04 2024 -0800 x86: use cmov for user address masking [ Upstream commit 91309a70829d94c735c8bb1cc383e78c96127a16 ] This was a suggestion by David Laight, and while I was slightly worried that some micro-architecture would predict cmov like a conditional branch, there is little reason to actually believe any core would be that broken. Intel documents that their existing cores treat CMOVcc as a data dependency that will constrain speculation in their "Speculative Execution Side Channel Mitigations" whitepaper: "Other instructions such as CMOVcc, AND, ADC, SBB and SETcc can also be used to prevent bounds check bypass by constraining speculative execution on current family 6 processors (Intel® Core™, Intel® Atom™, Intel® Xeon® and Intel® Xeon Phi™ processors)" and while that leaves the future uarch issues open, that's certainly true of our traditional SBB usage too. Any core that predicts CMOV will be unusable for various crypto algorithms that need data-independent timing stability, so let's just treat CMOV as the safe choice that simplifies the address masking by avoiding an extra instruction and doesn't need a temporary register. Suggested-by: David Laight Link: https://www.intel.com/content/dam/develop/external/us/en/documents/336996-speculative-execution-side-channel-mitigations.pdf Signed-off-by: Linus Torvalds Stable-dep-of: 284922f4c563 ("x86: uaccess: don't use runtime-const rewriting in modules") Signed-off-by: Sasha Levin commit 07640d34a781bb2e39020a39137073c03c4aa932 Author: Kotresh HR Date: Thu Sep 11 15:02:35 2025 +0530 ceph: fix multifs mds auth caps issue [ Upstream commit 22c73d52a6d05c5a2053385c0d6cd9984732799d ] The mds auth caps check should also validate the fsname along with the associated caps. Not doing so would result in applying the mds auth caps of one fs on to the other fs in a multifs ceph cluster. The bug causes multiple issues w.r.t user authentication, following is one such example. Steps to Reproduce (on vstart cluster): 1. Create two file systems in a cluster, say 'fsname1' and 'fsname2' 2. Authorize read only permission to the user 'client.usr' on fs 'fsname1' $ceph fs authorize fsname1 client.usr / r 3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2' $ceph fs authorize fsname2 client.usr / rw 4. Update the keyring $ceph auth get client.usr >> ./keyring With above permssions for the user 'client.usr', following is the expectation. a. The 'client.usr' should be able to only read the contents and not allowed to create or delete files on file system 'fsname1'. b. The 'client.usr' should be able to read/write on file system 'fsname2'. But, with this bug, the 'client.usr' is allowed to read/write on file system 'fsname1'. See below. 5. Mount the file system 'fsname1' with the user 'client.usr' $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/ 6. Try creating a file on file system 'fsname1' with user 'client.usr'. This should fail but passes with this bug. $touch /kmnt_fsname1_usr/file1 7. Mount the file system 'fsname1' with the user 'client.admin' and create a file. $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin $echo "data" > /kmnt_fsname1_admin/admin_file1 8. Try removing an existing file on file system 'fsname1' with the user 'client.usr'. This shoudn't succeed but succeeds with the bug. $rm -f /kmnt_fsname1_usr/admin_file1 For more information, please take a look at the corresponding mds/fuse patch and tests added by looking into the tracker mentioned below. v2: Fix a possible null dereference in doutc v3: Don't store fsname from mdsmap, validate against ceph_mount_options's fsname and use it v4: Code refactor, better warning message and fix possible compiler warning [ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ] Link: https://tracker.ceph.com/issues/72167 Signed-off-by: Kotresh HR Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 61f1263954269154654711192489d6f949483be0 Author: Viacheslav Dubeyko Date: Tue Jul 8 12:20:57 2025 -0700 ceph: refactor wake_up_bit() pattern of calling [ Upstream commit 53db6f25ee47cb1265141d31562604e56146919a ] The wake_up_bit() is called in ceph_async_unlink_cb(), wake_async_create_waiters(), and ceph_finish_async_create(). It makes sense to switch on clear_bit() function, because it makes the code much cleaner and easier to understand. More important rework is the adding of smp_mb__after_atomic() memory barrier after the bit modification and before wake_up_bit() call. It can prevent potential race condition of accessing the modified bit in other threads. Luckily, clear_and_wake_up_bit() already implements the required functionality pattern: static inline void clear_and_wake_up_bit(int bit, unsigned long *word) { clear_bit_unlock(bit, word); /* See wake_up_bit() for which memory barrier you need to use. */ smp_mb__after_atomic(); wake_up_bit(word, bit); } Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 08beed92552f3caf29edfb1c160c930038783419 Author: Viacheslav Dubeyko Date: Fri Jun 13 11:31:08 2025 -0700 ceph: fix potential race condition in ceph_ioctl_lazyio() [ Upstream commit 5824ccba9a39a3ad914fc9b2972a2c1119abaac9 ] The Coverity Scan service has detected potential race condition in ceph_ioctl_lazyio() [1]. The CID 1591046 contains explanation: "Check of thread-shared field evades lock acquisition (LOCK_EVASION). Thread1 sets fmode to a new value. Now the two threads have an inconsistent view of fmode and updates to fields correlated with fmode may be lost. The data guarded by this critical section may be read while in an inconsistent state or modified by multiple racing threads. In ceph_ioctl_lazyio: Checking the value of a thread-shared field outside of a locked region to determine if a locked operation involving that thread shared field has completed. (CWE-543)". The patch places fi->fmode field access under ci->i_ceph_lock protection. Also, it introduces the is_file_already_lazy variable that is set under the lock and it is checked later out of scope of critical section. [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1591046 Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 80e2b741af98a00cf2c0d627c09d18934553aa75 Author: Viacheslav Dubeyko Date: Fri Jun 6 12:04:32 2025 -0700 ceph: add checking of wait_for_completion_killable() return value [ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ] The Coverity Scan service has detected the calling of wait_for_completion_killable() without checking the return value in ceph_lock_wait_for_completion() [1]. The CID 1636232 defect contains explanation: "If the function returns an error value, the error value may be mistaken for a normal value. In ceph_lock_wait_for_completion(): Value returned from a function is not checked for errors before being used. (CWE-252)". The patch adds the checking of wait_for_completion_killable() return value and return the error code from ceph_lock_wait_for_completion(). [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232 Signed-off-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit e2105ba1c262dcaa9573f11844b6e1e1ca762c3f Author: Philip Yang Date: Mon Sep 15 15:57:32 2025 -0400 drm/amdkfd: Fix mmap write lock not release [ Upstream commit 7574f30337e19045f03126b4c51f525b84e5049e ] If mmap write lock is taken while draining retry fault, mmap write lock is not released because svm_range_restore_pages calls mmap_read_unlock then returns. This causes deadlock and system hangs later because mmap read or write lock cannot be taken. Downgrade mmap write lock to read lock if draining retry fault fix this bug. Signed-off-by: Philip Yang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cda427c933b475e6cb6b23c86af8944a659ff194 Author: Valerio Setti Date: Tue Oct 7 00:12:19 2025 +0200 ASoC: meson: aiu-encoder-i2s: fix bit clock polarity [ Upstream commit 4c4ed5e073a923fb3323022e1131cb51ad8df7a0 ] According to I2S specs audio data is sampled on the rising edge of the clock and it can change on the falling one. When operating in normal mode this SoC behaves the opposite so a clock polarity inversion is required in this case. This was tested on an OdroidC2 (Amlogic S905 SoC) board. Signed-off-by: Valerio Setti Reviewed-by: Jerome Brunet Tested-by: Jerome Brunet Link: https://patch.msgid.link/20251007-fix-i2s-polarity-v1-1-86704d9cda10@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 12cdc3738172825f7a26ffe82cf1437cfdf87735 Author: Geert Uytterhoeven Date: Mon Oct 6 14:33:42 2025 +0200 kbuild: uapi: Strip comments before size type check [ Upstream commit 66128f4287b04aef4d4db9bf5035985ab51487d5 ] On m68k, check_sizetypes in headers_check reports: ./usr/include/asm/bootinfo-amiga.h:17: found __[us]{8,16,32,64} type without #include This header file does not use any of the Linux-specific integer types, but merely refers to them from comments, so this is a false positive. As of commit c3a9d74ee413bdb3 ("kbuild: uapi: upgrade check_sizetypes() warning to error"), this check was promoted to an error, breaking m68k all{mod,yes}config builds. Fix this by stripping simple comments before looking for Linux-specific integer types. Signed-off-by: Geert Uytterhoeven Reviewed-by: Thomas Weißschuh Link: https://patch.msgid.link/949f096337e28d50510e970ae3ba3ec9c1342ec0.1759753998.git.geert@linux-m68k.org [nathan: Adjust comment and remove unnecessary escaping from slashes in regex] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 328ddff9ab058f689c28c740a0dad7b4fb7b94ae Author: Sammy Hsu Date: Thu Oct 2 10:48:41 2025 +0800 net: wwan: t7xx: add support for HP DRMR-H01 [ Upstream commit 370e98728bda92b1bdffb448d1acdcbe19dadb4c ] add support for HP DRMR-H01 (0x03f0, 0x09c8) Signed-off-by: Sammy Hsu Link: https://patch.msgid.link/20251002024841.5979-1-sammy.hsu@wnc.com.tw Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a31a7abdb1045bd0a0da6bcb281544aeaece94f Author: Bruno Thomsen Date: Tue Sep 2 20:22:35 2025 +0200 rtc: pcf2127: fix watchdog interrupt mask on pcf2131 [ Upstream commit 87064da2db7be537a7da20a25c18ba912c4db9e1 ] When using interrupt pin (INT A) as watchdog output all other interrupt sources need to be disabled to avoid additional resets. Resulting INT_A_MASK1 value is 55 (0x37). Signed-off-by: Bruno Thomsen Link: https://lore.kernel.org/r/20250902182235.6825-1-bruno.thomsen@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 15ba9acafb0517f8359ca30002c189a68ddbb939 Author: Albin Babu Varghese Date: Fri Oct 3 03:32:09 2025 -0400 fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds [ Upstream commit 3637d34b35b287ab830e66048841ace404382b67 ] Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes. Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190 Suggested-by: Helge Deller Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com Signed-off-by: Albin Babu Varghese Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 9285548962479fa6e164dd8c4e3595593a82eed4 Author: Sascha Hauer Date: Wed Oct 1 13:40:55 2025 +0200 tools: lib: thermal: use pkg-config to locate libnl3 [ Upstream commit b31f7f725cd932e2c2b41f3e4b66273653953687 ] To make libthermal more cross compile friendly use pkg-config to locate libnl3. Only if that fails fall back to hardcoded /usr/include/libnl3. Signed-off-by: Sascha Hauer Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f36678ddde84c61bbdd4766cf8af0ce68395dc07 Author: Emil Dahl Juhl Date: Wed Oct 1 13:40:56 2025 +0200 tools: lib: thermal: don't preserve owner in install [ Upstream commit 1375152bb02ab2a8435e87ea27034482dbc95f57 ] Instead of preserving mode, timestamp, and owner, for the object files during installation, just preserve the mode and timestamp. When installing as root, the installed files should be owned by root. When installing as user, --preserve=ownership doesn't work anyway. This makes --preserve=ownership rather pointless. Signed-off-by: Emil Dahl Juhl Signed-off-by: Sascha Hauer Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit df5af85e158204a2b2b448d201acf4af59894755 Author: Ian Rogers Date: Fri Sep 5 15:47:06 2025 -0700 tools bitmap: Add missing asm-generic/bitsperlong.h include [ Upstream commit f38ce0209ab4553906b44bd1159e35c740a84161 ] small_const_nbits is defined in asm-generic/bitsperlong.h which bitmap.h uses but doesn't include causing build failures in some build systems. Add the missing #include. Note the bitmap.h in tools has diverged from that of the kernel, so no changes are made there. Signed-off-by: Ian Rogers Acked-by: Yury Norov Cc: Adrian Hunter Cc: Alexander Shishkin Cc: André Almeida Cc: Daniel Borkmann Cc: Darren Hart Cc: David S. Miller Cc: Davidlohr Bueso Cc: Ido Schimmel Cc: Ingo Molnar Cc: Jakub Kicinski Cc: Jamal Hadi Salim Cc: Jason Xing Cc: Jiri Olsa Cc: Jonas Gottlieb Cc: Kan Liang Cc: Mark Rutland Cc: Maurice Lambert Cc: Namhyung Kim Cc: Paolo Abeni Cc: Peter Zijlstra Cc: Petr Machata Cc: Rasmus Villemoes Cc: Thomas Gleixner Cc: Yuyang Huang Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8effcd6db7a29c71b72e192f5da13c72e61e8323 Author: Tiezhu Yang Date: Thu Oct 2 22:39:35 2025 +0800 LoongArch: Handle new atomic instructions for probes [ Upstream commit db740f5689e61f2e75b73e5c8e7c985a3b4bc045 ] The atomic instructions sc.q, llacq.{w/d}, screl.{w/d} were newly added in the LoongArch Reference Manual v1.10, it is necessary to handle them in insns_not_supported() to avoid putting a breakpoint in the middle of a ll/sc atomic sequence, otherwise it will loop forever for kprobes and uprobes. Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 76e6561d7b1b44d6990da8c290ba96ab9343a8bd Author: Sakari Ailus Date: Wed Oct 1 13:26:36 2025 +0300 ACPI: property: Return present device nodes only on fwnode interface [ Upstream commit d9f866b2bb3eec38b3734f1fed325ec7c55ccdfa ] fwnode_graph_get_next_subnode() may return fwnode backed by ACPI device nodes and there has been no check these devices are present in the system, unlike there has been on fwnode OF backend. In order to provide consistent behaviour towards callers, add a check for device presence by introducing a new function acpi_get_next_present_subnode(), used as the get_next_child_node() fwnode operation that also checks device node presence. Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20251001102636.1272722-2-sakari.ailus@linux.intel.com [ rjw: Kerneldoc comment and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit de7488fd00dca3e0c30b4a5126ff820d82f2a1ff Author: Hoyoung Seo Date: Tue Sep 30 15:14:28 2025 +0900 scsi: ufs: core: Include UTP error in INT_FATAL_ERRORS [ Upstream commit 558ae4579810fa0fef011944230c65a6f3087f85 ] When a UTP error occurs in isolation, UFS is not currently recoverable. This is because the UTP error is not considered fatal in the error handling code, leading to either an I/O timeout or an OCS error. Add the UTP error flag to INT_FATAL_ERRORS so the controller will be reset in this situation. sd 0:0:0:0: [sda] tag#38 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s sd 0:0:0:0: [sda] tag#38 CDB: opcode=0x28 28 00 00 51 24 e2 00 00 08 00 I/O error, dev sda, sector 42542864 op 0x0:(READ) flags 0x80700 phys_seg 8 prio class 2 OCS error from controller = 9 for tag 39 pa_err[1] = 0x80000010 at 2667224756 us pa_err: total cnt=2 dl_err[0] = 0x80000002 at 2667148060 us dl_err[1] = 0x80002000 at 2667282844 us No record of nl_err No record of tl_err No record of dme_err No record of auto_hibern8_err fatal_err[0] = 0x804 at 2667282836 us --------------------------------------------------- REGISTER --------------------------------------------------- NAME OFFSET VALUE STD HCI SFR 0xfffffff0 0x0 AHIT 0x18 0x814 INTERRUPT STATUS 0x20 0x1000 INTERRUPT ENABLE 0x24 0x70ef5 [mkp: commit desc] Signed-off-by: Hoyoung Seo Reviewed-by: Bart Van Assche Message-Id: <20250930061428.617955-1-hy50.seo@samsung.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 425be0fd8c220bb57c5c4e660faa0ac8b93af84c Author: Randall P. Embry Date: Fri Sep 26 18:27:31 2025 +0900 9p: sysfs_init: don't hardcode error to ENOMEM [ Upstream commit 528f218b31aac4bbfc58914d43766a22ab545d48 ] v9fs_sysfs_init() always returned -ENOMEM on failure; return the actual sysfs_create_group() error instead. Signed-off-by: Randall P. Embry Message-ID: <20250926-v9fs_misc-v1-3-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 0e0d3046270e0e20505357dff7025f6e17619148 Author: Aaron Kling Date: Thu Aug 28 21:48:13 2025 -0500 cpufreq: tegra186: Initialize all cores to max frequencies [ Upstream commit ba6018929165fc914c665f071f8e8cdbac844a49 ] During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores are still at reset values and not reflecting the actual frequency. This causes get calls to fail. Set all cores to their respective max frequency during probe to initialize the registers to working values. Suggested-by: Mikko Perttunen Signed-off-by: Aaron Kling Reviewed-by: Mikko Perttunen Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 659233c179e0e684d68de5a48e4ddd624449422e Author: Randall P. Embry Date: Fri Sep 26 18:27:30 2025 +0900 9p: fix /sys/fs/9p/caches overwriting itself [ Upstream commit 86db0c32f16c5538ddb740f54669ace8f3a1f3d7 ] caches_show() overwrote its buffer on each iteration, so only the last cache tag was visible in sysfs output. Properly append with snprintf(buf + count, …). Signed-off-by: Randall P. Embry Message-ID: <20250926-v9fs_misc-v1-2-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 1c1fcba64ee5dabed4b189060a0ba046f50a105d Author: Jerome Brunet Date: Wed Jul 2 18:48:33 2025 +0200 NTB: epf: Allow arbitrary BAR mapping [ Upstream commit 5ad865862a0fd349163243e1834ed98ba9b81905 ] The NTB epf host driver assumes the BAR number associated with a memory window is just incremented from the BAR number associated with MW1. This seems to have been enough so far but this is not really how the endpoint side work and the two could easily become mis-aligned. ntb_epf_mw_to_bar() even assumes that the BAR number is the memory window index + 2, which means the function only returns a proper result if BAR_2 is associated with MW1. Instead, fully describe and allow arbitrary NTB BAR mapping. Signed-off-by: Jerome Brunet Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit a1f310511c92238fe1fbb5d028816543786527aa Author: Shubhrajyoti Datta Date: Fri Sep 5 14:40:02 2025 +0530 clk: clocking-wizard: Fix output clock register offset for Versal platforms [ Upstream commit 7c2e86f7b5af93d0e78c16e4359318fe7797671d ] The output clock register offset used in clk_wzrd_register_output_clocks was incorrectly referencing 0x3C instead of 0x38, which caused misconfiguration of output dividers on Versal platforms. Correcting the off-by-one error ensures proper configuration of output clocks. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6bd92bdc43664a19b075d3c17f7e34f0d48220ab Author: Jacky Bai Date: Mon Jul 28 15:04:46 2025 +0800 clk: scmi: Add duty cycle ops only when duty cycle is supported [ Upstream commit 18db1ff2dea0f97dedaeadd18b0cb0a0d76154df ] For some of the SCMI based platforms, the oem extended config may be supported, but not for duty cycle purpose. Skip the duty cycle ops if err return when trying to get duty cycle info. Signed-off-by: Jacky Bai Reviewed-by: Sudeep Holla Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 51771264b874f14e366f9c4601717f714804fa99 Author: Matthias Schiffer Date: Mon Aug 25 16:08:11 2025 +0200 clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled [ Upstream commit 1e0d75258bd09323cb452655549e03975992b29e ] As described in AM335x Errata Advisory 1.0.42, WKUP_DEBUGSS_CLKCTRL can't be disabled - the clock module will just be stuck in transitioning state forever, resulting in the following warning message after the wait loop times out: l3-aon-clkctrl:0000:0: failed to disable Just add the clock to enable_init_clks, so no attempt is made to disable it. Signed-off-by: Matthias Schiffer Signed-off-by: Alexander Stein Acked-by: Kevin Hilman Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2e1461034aef99e905a1fe5589aaf00eaea73eee Author: Oleg Nesterov Date: Tue Aug 19 18:10:13 2025 +0200 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN [ Upstream commit e8fe3f07a357c39d429e02ca34f740692d88967a ] p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 ("pipe_read: don't wake up the writer if the pipe is still full"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT. Reported-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Tested-by: syzbot+d1b5dace43896bc386c3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68a2de8f.050a0220.e29e5.0097.GAE@google.com/ Link: https://lore.kernel.org/all/67dedd2f.050a0220.31a16b.003f.GAE@google.com/ Co-developed-by: K Prateek Nayak Signed-off-by: K Prateek Nayak Signed-off-by: Oleg Nesterov Tested-by: K Prateek Nayak Message-ID: <20250819161013.GB11345@redhat.com> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit b2cf49f469caf09965e0466e97c2e5742df0312b Author: Nicolas Ferre Date: Wed Aug 27 17:08:10 2025 +0200 clk: at91: clk-sam9x60-pll: force write to PLL_UPDT register [ Upstream commit af98caeaa7b6ad11eb7b7c8bfaddc769df2889f3 ] This register is important for sequencing the commands to PLLs, so actually write the update bits with regmap_write_bits() instead of relying on a read/modify/write regmap command that could skip the actual hardware write if the value is identical to the one read. It's changed when modification is needed to the PLL, when read-only operation is done, we could keep the call to regmap_update_bits(). Add a comment to the sam9x60_div_pll_set_div() function that uses this PLL_UPDT register so that it's used consistently, according to the product's datasheet. Signed-off-by: Nicolas Ferre Tested-by: Ryan Wanner # on sama7d65 and sam9x75 Link: https://lore.kernel.org/r/20250827150811.82496-1-nicolas.ferre@microchip.com [claudiu.beznea: fix "Alignment should match open parenthesis" checkpatch.pl check] Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit 0fbbc9973997ba075fa72fe17db094c8a6f4c259 Author: Ryan Wanner Date: Mon Sep 8 13:07:17 2025 -0700 clk: at91: clk-master: Add check for divide by 3 [ Upstream commit e0237f5635727d64635ec6665e1de9f4cacce35c ] A potential divider for the master clock is div/3. The register configuration for div/3 is MASTER_PRES_MAX. The current bit shifting method does not work for this case. Checking for MASTER_PRES_MAX will ensure the correct decimal value is stored in the system. Signed-off-by: Ryan Wanner Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 7af4f219766d58d21208e63cfafda873eb376cb6 Author: Balamanikandan Gunasundar Date: Tue Sep 9 16:08:17 2025 +0530 clk: at91: sam9x7: Add peripheral clock id for pmecc [ Upstream commit 94a1274100e397a27361ae53ace37be6da42a079 ] Add pmecc instance id in peripheral clock description. Signed-off-by: Balamanikandan Gunasundar Link: https://lore.kernel.org/r/20250909103817.49334-1-balamanikandan.gunasundar@microchip.com [claudiu.beznea@tuxon.dev: use tabs instead of spaces] Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Signed-off-by: Sasha Levin commit 15e6440f2ab18c343793701eb0f65e0397ac71ab Author: Nicolas Ferre Date: Wed Aug 27 16:54:27 2025 +0200 ARM: at91: pm: save and restore ACR during PLL disable/enable [ Upstream commit 0c01fe49651d387776abed6a28541e80c8a93319 ] Add a new word in assembly to store ACR value during the calls to at91_plla_disable/at91_plla_enable macros and use it. Signed-off-by: Nicolas Ferre [cristian.birsan@microchip.com: remove ACR_DEFAULT_PLLA loading] Signed-off-by: Cristian Birsan Link: https://lore.kernel.org/r/20250827145427.46819-4-nicolas.ferre@microchip.com Reviewed-by: Alexandre Belloni Signed-off-by: Claudiu Beznea Signed-off-by: Sasha Levin commit bc566475277625ec37072ce143fff4a5044b0080 Author: Josua Mayer Date: Mon Aug 25 19:54:09 2025 +0200 rtc: pcf2127: clear minute/second interrupt [ Upstream commit a6f1a4f05970664004a9370459c6799c1b2f2dcf ] PCF2127 can generate interrupt every full second or minute configured from control and status register 1, bits MI (1) and SI (0). On interrupt control register 2 bit MSF (7) is set and must be cleared to continue normal operation. While the driver never enables this interrupt on its own, users or firmware may do so - e.g. as an easy way to test the interrupt. Add preprocessor definition for MSF bit and include it in the irq bitmask to ensure minute and second interrupts are cleared when fired. This fixes an issue where the rtc enters a test mode and becomes unresponsive after a second interrupt has fired and is not cleared in time. In this state register writes to control registers have no effect and the interrupt line is kept asserted [1]: [1] userspace commands to put rtc into unresponsive state: $ i2cget -f -y 2 0x51 0x00 0x04 $ i2cset -f -y 2 0x51 0x00 0x05 # set bit 0 SI $ i2cget -f -y 2 0x51 0x00 0x84 # bit 8 EXT_TEST set $ i2cset -f -y 2 0x51 0x00 0x05 # try overwrite control register $ i2cget -f -y 2 0x51 0x00 0x84 # no change Signed-off-by: Josua Mayer Reviewed-by: Bruno Thomsen Link: https://lore.kernel.org/r/20250825-rtc-irq-v1-1-0133319406a7@solid-run.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 8de83291004477972d2c2dbb9b584672528ac5f0 Author: Chen-Yu Tsai Date: Wed Sep 10 01:09:47 2025 +0800 clk: sunxi-ng: sun6i-rtc: Add A523 specifics [ Upstream commit 7aa8781f379c32c31bd78f1408a31765b2297c43 ] The A523's RTC block is backward compatible with the R329's, but it also has a calibration function for its internal oscillator, which would allow it to provide a clock rate closer to the desired 32.768 KHz. This is useful on the Radxa Cubie A5E, which does not have an external 32.768 KHz crystal. Add new compatible-specific data for it. Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250909170947.2221611-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit d8c4a6d84bfdc8e01239fa4a5aa2fd3ee7c9127a Author: Tiwei Bie Date: Wed Aug 27 08:56:59 2025 +0800 um: Fix help message for ssl-non-raw [ Upstream commit 725e9d81868fcedaeef775948e699955b01631ae ] Add the missing option name in the help message. Additionally, switch to __uml_help(), because this is a global option rather than a per-channel option. Signed-off-by: Tiwei Bie Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4e7a3e00c1a776fd4bf85d158cf47c16fd82e361 Author: Yikang Yue Date: Sat May 3 20:44:34 2025 -0500 fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink [ Upstream commit 32058c38d3b79a28963a59ac0353644dc24775cd ] The function call new_inode() is a primitive for allocating an inode in memory, rather than planning disk space for it. Therefore, -ENOMEM should be returned as the error code rather than -ENOSPC. To be specific, new_inode()'s call path looks like this: new_inode new_inode_pseudo alloc_inode ops->alloc_inode (hpfs_alloc_inode) alloc_inode_sb kmem_cache_alloc_lru Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM), not a lack of disk space. However, the current implementation of hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails. This patch fix this by set err to -ENOMEM before the goto statement. BTW, we also noticed that other nested calls within these four functions, like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure. But similarly, only -ENOSPC is returned. Addressing these will involve code modifications in other functions, and we plan to submit dedicated patches for these issues in the future. For this patch, we focus on new_inode(). Signed-off-by: Yikang Yue Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 9a7a5d50ee2e035325de9c720e4842d6759d2374 Author: Marko Mäkelä Date: Sat Aug 2 12:55:46 2025 +0300 clk: qcom: gcc-ipq6018: rework nss_port5 clock to multiple conf [ Upstream commit 2f7b168323c22faafb1fbf94ef93b7ce5efc15c6 ] Rework nss_port5 to use the new multiple configuration implementation and correctly fix the clocks for this port under some corner case. In OpenWrt, this patch avoids intermittent dmesg errors of the form nss_port5_rx_clk_src: rcg didn't update its configuration. This is a mechanical, straightforward port of commit e88f03230dc07aa3293b6aeb078bd27370bb2594 ("clk: qcom: gcc-ipq8074: rework nss_port5/6 clock to multiple conf") to gcc-ipq6018, with two conflicts resolved: different frequency of the P_XO clock source, and only 5 Ethernet ports. This was originally developed by JiaY-shi . Link: https://lore.kernel.org/all/20231220221724.3822-4-ansuelsmth@gmail.com/ Signed-off-by: Marko Mäkelä Tested-by: Marko Mäkelä Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250802095546.295448-1-marko.makela@iki.fi Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6125acdf9aceb8be86c5dea473e9b800c60a5d86 Author: austinchang Date: Wed Oct 29 09:35:27 2025 +0000 btrfs: mark dirty extent range for out of bound prealloc extents [ Upstream commit 3b1a4a59a2086badab391687a6a0b86e03048393 ] In btrfs_fallocate(), when the allocated range overlaps with a prealloc extent and the extent starts after i_size, the range doesn't get marked dirty in file_extent_tree. This results in persisting an incorrect disk_i_size for the inode when not using the no-holes feature. This is reproducible since commit 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree"), then became hidden since commit 3d7db6e8bd22 ("btrfs: don't allocate file extent tree for non regular files") and then visible again after commit 8679d2687c35 ("btrfs: initialize inode::file_extent_tree after i_mode has been set"), which fixes the previous commit. The following reproducer triggers the problem: $ cat test.sh MNT=/mnt/test DEV=/dev/vdb mkdir -p $MNT mkfs.btrfs -f -O ^no-holes $DEV mount $DEV $MNT touch $MNT/file1 fallocate -n -o 1M -l 2M $MNT/file1 umount $MNT mount $DEV $MNT len=$((1 * 1024 * 1024)) fallocate -o 1M -l $len $MNT/file1 du --bytes $MNT/file1 umount $MNT mount $DEV $MNT du --bytes $MNT/file1 umount $MNT Running the reproducer gives the following result: $ ./test.sh (...) 2097152 /mnt/test/file1 1048576 /mnt/test/file1 The difference is exactly 1048576 as we assigned. Fix by adding a call to btrfs_inode_set_file_extent_range() in btrfs_fallocate_update_isize(). Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree") Signed-off-by: austinchang Reviewed-by: Filipe Manana Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3412d0e973e8f8381747d69033eda809a57a2581 Author: Shardul Bankar Date: Sun Oct 26 01:30:21 2025 +0530 btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation [ Upstream commit f260c6aff0b8af236084012d14f9f1bf792ea883 ] When btrfs_add_qgroup_relation() is called with invalid qgroup levels (src >= dst), the function returns -EINVAL directly without freeing the preallocated qgroup_list structure passed by the caller. This causes a memory leak because the caller unconditionally sets the pointer to NULL after the call, preventing any cleanup. The issue occurs because the level validation check happens before the mutex is acquired and before any error handling path that would free the prealloc pointer. On this early return, the cleanup code at the 'out' label (which includes kfree(prealloc)) is never reached. In btrfs_ioctl_qgroup_assign(), the code pattern is: prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL); ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc); prealloc = NULL; // Always set to NULL regardless of return value ... kfree(prealloc); // This becomes kfree(NULL), does nothing When the level check fails, 'prealloc' is never freed by either the callee or the caller, resulting in a 64-byte memory leak per failed operation. This can be triggered repeatedly by an unprivileged user with access to a writable btrfs mount, potentially exhausting kernel memory. Fix this by freeing prealloc before the early return, ensuring prealloc is always freed on all error paths. Fixes: 4addc1ffd67a ("btrfs: qgroup: preallocate memory before adding a relation") Reviewed-by: Qu Wenruo Signed-off-by: Shardul Bankar Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit fa5867c49652865b5d42bdb26028d36b0204c25e Author: Junxian Huang Date: Thu Oct 16 19:40:50 2025 +0800 RDMA/hns: Fix wrong WQE data when QP wraps around [ Upstream commit fe9622011f955e35ba84d3af7b2f2fed31cf8ca1 ] When QP wraps around, WQE data from the previous use at the same position still remains as driver does not clear it. The WQE field layout differs across different opcodes, causing that the fields that are not explicitly assigned for the current opcode retain stale values, and are issued to HW by mistake. Such fields are as follows: * MSG_START_SGE_IDX field in ATOMIC WQE * BLOCK_SIZE and ZBVA fields in FRMR WQE * DirectWQE fields when DirectWQE not used For ATOMIC WQE, always set the latest sge index in MSG_START_SGE_IDX as required by HW. For FRMR WQE and DirectWQE, clear only those unassigned fields instead of the entire WQE to avoid performance penalty. Fixes: 68a997c5d28c ("RDMA/hns: Add FRMR support for hip08") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20251016114051.1963197-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 65ddffb2c718ce394025ea1b706249ea051a0781 Author: wenglianfa Date: Thu Oct 16 19:40:49 2025 +0800 RDMA/hns: Fix the modification of max_send_sge [ Upstream commit f5a7cbea5411668d429eb4ffe96c4063fe8dac9e ] The actual sge number may exceed the value specified in init_attr->cap when HW needs extra sge to enable inline feature. Since these extra sges are not expected by ULP, return the user-specified value to ULP instead of the expanded sge number. Fixes: 0c5e259b06a8 ("RDMA/hns: Fix incorrect sge nums calculation") Signed-off-by: wenglianfa Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20251016114051.1963197-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 2f8953e1b1398da8ba3ae32641856f1983304dc8 Author: Chengchang Tang Date: Thu Oct 16 19:40:48 2025 +0800 RDMA/hns: Fix recv CQ and QP cache affinity [ Upstream commit c4b67b514af8c2d73c64b36e0cd99e9b26b9ac82 ] Currently driver enforces affinity between QP cache and send CQ cache, which helps improve the performance of sending, but doesn't set affinity with recv CQ cache, resulting in suboptimal performance of receiving. Use one CQ bank per context to ensure the affinity among QP, send CQ and recv CQ. For kernel ULP, CQ bank is fixed to 0. Fixes: 9e03dbea2b06 ("RDMA/hns: Fix CQ and QP cache affinity") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20251016114051.1963197-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6562b4233795bc4b50581107d3d3a09cef92dd72 Author: Jacob Moroni Date: Tue Sep 23 14:24:39 2025 +0000 RDMA/irdma: Set irdma_cq cq_num field during CQ create [ Upstream commit 5575b7646b94c0afb0f4c0d86e00e13cf3397a62 ] The driver maintains a CQ table that is used to ensure that a CQ is still valid when processing CQ related AEs. When a CQ is destroyed, the table entry is cleared, using irdma_cq.cq_num as the index. This field was never being set, so it was just always clearing out entry 0. Additionally, the cq_num field size was increased to accommodate HW supporting more than 64K CQs. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20250923142439.943930-1-jmoroni@google.com Acked-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ec3efa0d8397037fe0dbce9b308bd2fc22f8fcc5 Author: Jacob Moroni Date: Tue Sep 23 14:21:28 2025 +0000 RDMA/irdma: Remove unused struct irdma_cq fields [ Upstream commit 880245fd029a8f8ee8fd557c2681d077c1b1a959 ] These fields were set but not used anywhere, so remove them. Link: https://patch.msgid.link/r/20250923142128.943240-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Stable-dep-of: 5575b7646b94 ("RDMA/irdma: Set irdma_cq cq_num field during CQ create") Signed-off-by: Sasha Levin commit a99cfe5cf60a6894547badc3d640ce211f536bbb Author: Jacob Moroni Date: Tue Sep 23 19:08:50 2025 +0000 RDMA/irdma: Fix SD index calculation [ Upstream commit 8d158f47f1f33d8747e80c3afbea5aa337e59d41 ] In some cases, it is possible for pble_rsrc->next_fpm_addr to be larger than u32, so remove the u32 cast to avoid unintentional truncation. This fixes the following error that can be observed when registering massive memory regions: [ 447.227494] (NULL ib_device): cqp opcode = 0x1f maj_err_code = 0xffff min_err_code = 0x800c [ 447.227505] (NULL ib_device): [Update PE SDs Cmd Error][op_code=21] status=-5 waiting=1 completion_err=1 maj=0xffff min=0x800c Fixes: e8c4dbc2fcac ("RDMA/irdma: Add PBLE resource manager") Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20250923190850.1022773-1-jmoroni@google.com Acked-by: Tatyana Nikolova Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b7c21dec60f9d98d984a69adbb924eb5d23e4ee7 Author: Saket Dumbre Date: Fri Sep 12 22:01:04 2025 +0200 ACPICA: Update dsmethod.c to get rid of unused variable warning [ Upstream commit 761dc71c6020d6aa68666e96373342d49a7e9d0a ] All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about the unused variable i after the removal of its usage by PR #1031 addressing Issue #1027 Link: https://github.com/acpica/acpica/commit/6d235320 Signed-off-by: Saket Dumbre Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6e223d5dc81d2e7553c5303b4c642700618648c2 Author: Mario Limonciello Date: Wed Aug 27 12:17:19 2025 -0500 drm/amd/display: Add fallback path for YCBCR422 [ Upstream commit db291ed1732e02e79dca431838713bbf602bda1c ] [Why] DP validation may fail with multiple displays and higher color depths. The sink may support others though. [How] When DP bandwidth validation fails, progressively fallback through: - YUV422 8bpc (bandwidth efficient) - YUV422 6bpc (reduced color depth) - YUV420 (last resort) This resolves cases where displays would show no image due to insufficient DP link bandwidth for the requested RGB mode. Suggested-by: Mauri Carvalho Reviewed-by: Wayne Lin Signed-off-by: Mario Limonciello Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c5f456784a8478f43afabd2d73227cd92012a0e5 Author: Thadeu Lima de Souza Cascardo Date: Wed Apr 23 05:45:42 2025 -0300 char: misc: restrict the dynamic range to exclude reserved minors [ Upstream commit 31b636d2c41613e3bd36256a4bd53e9dacfa2677 ] When this was first reported [1], the possibility of having sufficient number of dynamic misc devices was theoretical, in the case of dlm driver. In practice, its userspace never created more than one device. What we know from commit ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448"), is that the miscdevice interface has been used for allocating more than the single-shot devices it was designed for. And it is not only coresight_tmc, but many other drivers are able to create multiple devices. On systems like the ones described in the above commit, it is certain that the dynamic allocation will allocate certain reserved minor numbers, leading to failures when a later driver tries to claim its reserved number. Instead of excluding the historically statically allocated range from dynamic allocation, restrict the latter to minors above 255. That also removes the need for DYNAMIC_MINORS and the convolution in allocating minor numbers, simplifying the code. Since commit ab760791c0cf ("char: misc: Increase the maximum number of dynamic misc devices to 1048448") has been applied, such range is already possible. And given such devices already need to be dynamically created, there should be no systems where this might become a problem. [1] https://lore.kernel.org/all/1257813017-28598-3-git-send-email-cascardo@holoscopio.com/ Signed-off-by: Thadeu Lima de Souza Cascardo Link: https://lore.kernel.org/r/20250423-misc-dynrange-v4-1-133b5ae4ca18@igalia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab03634f6c18d5e3326a9d6daf1f86d866c77475 Author: Michal Pecio Date: Tue Oct 14 01:55:40 2025 +0300 usb: xhci-pci: Fix USB2-only root hub registration [ Upstream commit 8607edcd1748503f4f58e66ca0216170f260c79b ] A recent change to hide USB3 root hubs of USB2-only controllers broke registration of USB2 root hubs - allow_single_roothub is set too late, and by this time xhci_run() has already deferred root hub registration until after the shared HCD is added, which will never happen. This makes such controllers unusable, but testers didn't notice since they were only bothered by warnings about empty USB3 root hubs. The bug causes problems to other people who actually use such HCs and I was able to confirm it on an ordinary HC by patching to ignore USB3 ports. Setting allow_single_roothub during early setup fixes things. Reported-by: Arisa Snowbell Closes: https://lore.kernel.org/linux-usb/CABpa4MA9unucCoKtSdzJyOLjHNVy+Cwgz5AnAxPkKw6vuox1Nw@mail.gmail.com/ Reported-by: Michal Kubecek Closes: https://lore.kernel.org/linux-usb/lnb5bum7dnzkn3fc7gq6hwigslebo7o4ccflcvsc3lvdgnu7el@fvqpobbdoapl/ Fixes: 719de070f764 ("usb: xhci-pci: add support for hosts with zero USB3 ports") Tested-by: Arisa Snowbell Tested-by: Michal Kubecek Suggested-by: Mathias Nyman Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit edd824eb45e4f7e05ad3ab090dab6dbdb79cd292 Author: Coiby Xu Date: Mon Sep 15 13:55:23 2025 +0800 ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr [ Upstream commit 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd ] Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; } Signed-off-by: Coiby Xu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit ecda324c280497e8b5e272b7056ca5d69a4d22e9 Author: Fiona Ebner Date: Mon Sep 15 17:19:39 2025 +0200 smb: client: transport: avoid reconnects triggered by pending task work [ Upstream commit 00be6f26a2a7c671f1402d74c4d3c30a5844660a ] When io_uring is used in the same task as CIFS, there might be unnecessary reconnects, causing issues in user-space applications like QEMU with a log like: > CIFS: VFS: \\10.10.100.81 Error -512 sending data on socket to server Certain io_uring completions might be added to task_work with notify_method being TWA_SIGNAL and thus TIF_NOTIFY_SIGNAL is set for the task. In __smb_send_rqst(), signals are masked before calling smb_send_kvec(), but the masking does not apply to TIF_NOTIFY_SIGNAL. If sk_stream_wait_memory() is reached via sock_sendmsg() while TIF_NOTIFY_SIGNAL is set, signal_pending(current) will evaluate to true there, and -EINTR will be propagated all the way from sk_stream_wait_memory() to sock_sendmsg() in smb_send_kvec(). Afterwards, __smb_send_rqst() will see that not everything was written and reconnect. Signed-off-by: Fiona Ebner Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c55305efbc1a6c33160675dd9b08445dfb2ac4da Author: Namjae Jeon Date: Thu Sep 25 21:12:05 2025 +0900 ksmbd: use sock_create_kern interface to create kernel socket [ Upstream commit 3677ca67b9791481af16d86e47c3c7d1f2442f95 ] we should use sock_create_kern() if the socket resides in kernel space. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 40c8ee40e48a2c82c762539952ed8fc0571db5bf Author: Vladimir Riabchun Date: Fri Sep 12 13:28:55 2025 +0200 ftrace: Fix softlockup in ftrace_module_enable [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 9127d1e90c90e5960c8bc72a4ce2c209691a7021 Author: Mike Marshall Date: Mon Sep 15 17:40:46 2025 -0400 orangefs: fix xattr related buffer overflow... [ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ] Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr "security.capability" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for "security.capability" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture. Signed-off-by: Mike Marshall Reported-by: Stanislav Fort of Aisle Research Signed-off-by: Sasha Levin commit 10de826c551cb1e2a763c24195be9234fdde617d Author: Dragos Tatulea Date: Fri Sep 26 16:16:05 2025 +0300 page_pool: Clamp pool size to max 16K pages [ Upstream commit a1b501a8c6a87c9265fd03bd004035199e2e8128 ] page_pool_init() returns E2BIG when the page_pool size goes above 32K pages. As some drivers are configuring the page_pool size according to the MTU and ring size, there are cases where this limit is exceeded and the queue creation fails. The page_pool size doesn't have to cover a full queue, especially for larger ring size. So clamp the size instead of returning an error. Do this in the core to avoid having each driver do the clamping. The current limit was deemed to high [1] so it was reduced to 16K to avoid page waste. [1] https://lore.kernel.org/all/1758532715-820422-3-git-send-email-tariqt@nvidia.com/ Signed-off-by: Dragos Tatulea Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20250926131605.2276734-2-dtatulea@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2896476cb4b19bda7fc8d8b51643950918e20240 Author: Qingfang Deng Date: Thu Sep 25 13:10:59 2025 +0800 6pack: drop redundant locking and refcounting [ Upstream commit 38b04ed7072e54086102eae2d05d03ffcdb4b695 ] The TTY layer already serializes line discipline operations with tty->ldisc_sem, so the extra disc_data_lock and refcnt in 6pack are unnecessary. Removing them simplifies the code and also resolves a lockdep warning reported by syzbot. The warning did not indicate a real deadlock, since the write-side lock was only taken in process context with hardirqs disabled. Reported-by: syzbot+5fd749c74105b0e1b302@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68c858b0.050a0220.3c6139.0d1c.GAE@google.com/ Signed-off-by: Qingfang Deng Reviewed-by: Dan Carpenter Link: https://patch.msgid.link/20250925051059.26876-1-dqfext@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6bc58b4c53795ab5fe00648344aa7d9d61175f90 Author: Namjae Jeon Date: Sat Aug 30 14:44:35 2025 +0900 exfat: validate cluster allocation bits of the allocation bitmap [ Upstream commit 79c1587b6cda74deb0c86fc7ba194b92958c793c ] syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use. Reported-by: syzbot+a725ab460fc1def9896f@syzkaller.appspotmail.com Tested-by: syzbot+a725ab460fc1def9896f@syzkaller.appspotmail.com Reviewed-by: Yuezhang Mo Reviewed-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit a76aba65e823f3c8866e3d8662e30e456f267ce3 Author: Chi Zhiling Date: Fri Aug 15 17:32:45 2025 +0800 exfat: limit log print for IO error [ Upstream commit 6dfba108387bf4e71411b3da90b2d5cce48ba054 ] For exFAT filesystems with 4MB read_ahead_size, removing the storage device when the read operation is in progress, which cause the last read syscall spent 150s [1]. The main reason is that exFAT generates excessive log messages [2]. After applying this patch, approximately 300,000 lines of log messages were suppressed, and the delay of the last read() syscall was reduced to about 4 seconds. [1]: write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000120> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000032> write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000119> read(4, 0x7fccf28ae000, 131072) = -1 EIO (Input/output error) <150.186215> [2]: [ 333.696603] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.697378] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) [ 333.698156] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5) Signed-off-by: Chi Zhiling Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit ac79f9b6c63242ffa8eee2df9c9198a5b3628208 Author: Rohan G Thomas Date: Thu Sep 25 22:06:13 2025 +0800 net: stmmac: est: Drop frames causing HLBS error [ Upstream commit 7ce48d497475d7222bd8258c5c055eb7d928793c ] Drop those frames causing Head-of-Line Blocking due to Scheduling (HLBS) error to avoid HLBS interrupt flooding and netdev watchdog timeouts due to blocked packets. Tx queues can be configured to drop those blocked packets by setting Drop Frames causing Scheduling Error (DFBS) bit of EST_CONTROL register. Also, add per queue HLBS drop count. Signed-off-by: Rohan G Thomas Reviewed-by: Matthew Gerlach Reviewed-by: Furong Xu <0x1207@gmail.com> Link: https://patch.msgid.link/20250925-hlbs_2-v3-1-3b39472776c2@altera.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit acf2159ffef407f31ac03fd3eadecc67732c66a7 Author: Roy Vegard Ovesen Date: Sat Sep 27 17:27:30 2025 +0200 ALSA: usb-audio: add mono main switch to Presonus S1824c [ Upstream commit 659169c4eb21f8d9646044a4f4e1bc314f6f9d0c ] The 1824c does not have the A/B switch that the 1810c has, but instead it has a mono main switch that sums the two main output channels to mono. Signed-off-by: Roy Vegard Ovesen Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b420a4c7f915fc1c94ad1f6ca740acc046d94334 Author: Ivan Pravdin Date: Sat Aug 30 16:03:40 2025 -0400 Bluetooth: bcsp: receive data only if registered [ Upstream commit ca94b2b036c22556c3a66f1b80f490882deef7a6 ] Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH. Reported-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da Tested-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com Signed-off-by: Ivan Pravdin Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit da4e3cfba2563ca3a4b3f5814ffa8e9b1f41875b Author: Chris Lu Date: Thu Sep 4 19:46:11 2025 +0800 Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922 [ Upstream commit 70cd38d22d4659ca8133c7124528c90678215dda ] Add VID 13d3 & PID 3633 for MediaTek MT7922 USB Bluetooth chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3633 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ed10dddc7df2daaf2a4d98a972aac5183e738cc0 Author: Luiz Augusto von Dentz Date: Mon Sep 22 13:13:13 2025 -0400 Bluetooth: SCO: Fix UAF on sco_conn_free [ Upstream commit ecb9a843be4d6fd710d7026e359f21015a062572 ] BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x1dd/0x240 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: cen zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2ad85a751fa1b6442c9110db1900828085a6bf34 Author: Arkadiusz Bokowy Date: Wed Aug 27 18:40:16 2025 +0200 Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames [ Upstream commit 7722d6fb54e428a8f657fccf422095a8d7e2d72c ] Some Barrot based USB Bluetooth dongles erroneously send one extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The consequence of that is that the next HCI transfer is misaligned by one byte causing undefined behavior. In most cases the response event for the next command fails with random error code. Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI controller initialization, the initialization fails rendering the USB dongle not usable. > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110 This patch was tested with the 33fa:0012 device. The info from the /sys/kernel/debug/usb/devices is shown below: T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 12 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=33fa ProdID=0012 Rev=88.91 S: Product=UGREEN BT6.0 Adapter C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Now the device is initialized properly: > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91 > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes > [43.750141] Bluetooth: MGMT ver 1.23 Link: https://github.com/bluez/bluez/issues/1326 Signed-off-by: Arkadiusz Bokowy Tested-by: Arkadiusz Bokowy Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0d2fad775194fc99a126799f589b04ec581765f7 Author: Théo Lebrun Date: Tue Sep 23 18:00:27 2025 +0200 net: macb: avoid dealing with endianness in macb_set_hwaddr() [ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ] bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone. Replace by calls to get_unaligned_le32|le16() helpers. This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ... Reviewed-by: Sean Anderson Signed-off-by: Théo Lebrun Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c691d6a238e1f6076ae68920d8ac9220f5b3d76b Author: Carolina Jubran Date: Wed Sep 24 12:40:34 2025 +0000 net/mlx5e: Don't query FEC statistics when FEC is disabled [ Upstream commit 6b81b8a0b1978284e007566d7a1607b47f92209f ] Update mlx5e_stats_fec_get() to check the active FEC mode and skip statistics collection when FEC is disabled. Signed-off-by: Carolina Jubran Reviewed-by: Dragos Tatulea Reviewed-by: Yael Chemla Signed-off-by: Vadim Fedorenko Reviewed-by: Aleksandr Loktionov Link: https://patch.msgid.link/20250924124037.1508846-3-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 47ed17f2cbea2d385cdd0e3352a274315dd8a7a6 Author: Timothy Pearson Date: Tue Sep 23 12:04:33 2025 -0500 vfio/pci: Fix INTx handling on legacy non-PCI 2.3 devices [ Upstream commit 8b9f128947dd72e0fcf256088a673abac9b720bf ] PCI devices prior to PCI 2.3 both use level interrupts and do not support interrupt masking, leading to a failure when passed through to a KVM guest on at least the ppc64 platform. This failure manifests as receiving and acknowledging a single interrupt in the guest, while the device continues to assert the level interrupt indicating a need for further servicing. When lazy IRQ masking is used on DisINTx- (non-PCI 2.3) hardware, the following sequence occurs: * Level IRQ assertion on device * IRQ marked disabled in kernel * Host interrupt handler exits without clearing the interrupt on the device * Eventfd is delivered to userspace * Guest processes IRQ and clears device interrupt * Device de-asserts INTx, then re-asserts INTx while the interrupt is masked * Newly asserted interrupt acknowledged by kernel VMM without being handled * Software mask removed by VFIO driver * Device INTx still asserted, host controller does not see new edge after EOI The behavior is now platform-dependent. Some platforms (amd64) will continue to spew IRQs for as long as the INTX line remains asserted, therefore the IRQ will be handled by the host as soon as the mask is dropped. Others (ppc64) will only send the one request, and if it is not handled no further interrupts will be sent. The former behavior theoretically leaves the system vulnerable to interrupt storm, and the latter will result in the device stalling after receiving exactly one interrupt in the guest. Work around this by disabling lazy IRQ masking for DisINTx- INTx devices. Signed-off-by: Timothy Pearson Link: https://lore.kernel.org/r/333803015.1744464.1758647073336.JavaMail.zimbra@raptorengineeringinc.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 0dae3d96ca0114835ec1c1589d67ba38a01d6700 Author: Sunil V L Date: Mon Aug 18 09:39:12 2025 +0530 ACPI: scan: Update honor list for RPMI System MSI [ Upstream commit 4215d1cf59e4b272755f4277a05cd5967935a704 ] The RPMI System MSI interrupt controller (just like PLIC and APLIC) needs to probed prior to devices like GED which use interrupts provided by it. Also, it has dependency on the SBI MPXY mailbox device. Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor list so that those dependencies are handled. Reviewed-by: Atish Patra Reviewed-by: Andy Shevchenko Acked-by: Rafael J. Wysocki Signed-off-by: Sunil V L Signed-off-by: Anup Patel Acked-by: Jassi Brar Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit fbf767ea54d867cd93f7324e2ae8ce8ec292e4d3 Author: Primoz Fiser Date: Thu Sep 25 10:59:29 2025 +0200 ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007 [ Upstream commit 733a763dd8b3ac2858dd238a91bb3a2fdff4739e ] The problem of having class-D initialization sequence in probe using regmap_register_patch() is that it will do hardware register writes immediately after being called as it bypasses regcache. Afterwards, in aic3x_init() we also perform codec soft reset, rendering class-D init sequence pointless. This issue is even more apparent when using reset GPIO line, since in that case class-D amplifier initialization fails with "Failed to init class D: -5" message as codec is already held in reset state after requesting the reset GPIO and hence hardware I/O fails with -EIO errno. Thus move class-D amplifier initialization sequence from probe function to aic3x_set_power() just before the usual regcache sync. Use bypassed regmap_multi_reg_write_bypassed() function to make sure, class-D init sequence is performed in proper order as described in the datasheet. Signed-off-by: Primoz Fiser Link: https://patch.msgid.link/20250925085929.2581749-1-primoz.fiser@norik.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4d7fc991d2769cfe0687e26dd80de2e5f4c4992a Author: Olivier Moysan Date: Tue Sep 16 14:31:18 2025 +0200 ASoC: stm32: sai: manage context in set_sysclk callback [ Upstream commit 27fa1a8b2803dfd88c39f03b0969c55f667cdc43 ] The mclk direction now needs to be specified in endpoint node with "system-clock-direction-out" property. However some calls to the set_sysclk callback, related to CPU DAI clock, result in unbalanced calls to clock API. The set_sysclk callback in STM32 SAI driver is intended only for mclk management. So it is relevant to ensure that calls to set_sysclk are related to mclk only. Since the master clock is handled only at runtime, skip the calls to set_sysclk in the initialization phase. Signed-off-by: Olivier Moysan Link: https://patch.msgid.link/20250916123118.84175-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc9e789053abe463f8cf74eee5fc2f157c11a79f Author: Yifan Zhang Date: Tue Sep 16 21:21:15 2025 +0800 amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw [ Upstream commit 99d7181bca34e96fbf61bdb6844918bdd4df2814 ] There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1 Signed-off-by: Yifan Zhang Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1c553d19ff28340c53d48c6c0dc0a88f88e04e28 Author: Julian Sun Date: Wed Aug 27 20:18:12 2025 +0800 ext4: increase IO priority of fastcommit [ Upstream commit 46e75c56dfeafb6756773b71cabe187a6886859a ] The following code paths may result in high latency or even task hangs: 1. fastcommit io is throttled by wbt. 2. jbd2_fc_wait_bufs() might wait for a long time while JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then jbd2_journal_commit_transaction() waits for the JBD2_FAST_COMMIT_ONGOING bit for a long time while holding the write lock of j_state_lock. 3. start_this_handle() waits for read lock of j_state_lock which results in high latency or task hang. Given the fact that ext4_fc_commit() already modifies the current process' IO priority to match that of the jbd2 thread, it should be reasonable to match jbd2's IO submission flags as well. Suggested-by: Ritesh Harjani (IBM) Signed-off-by: Julian Sun Reviewed-by: Zhang Yi Reviewed-by: Jan Kara Message-ID: <20250827121812.1477634-1-sunjunchao@bytedance.com> Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 238f7a7356c33a9797a6297c6fdfd87f113b2325 Author: chuguangqing Date: Wed Aug 6 10:28:49 2025 +0800 fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock [ Upstream commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a ] The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag. Signed-off-by: chuguangqing Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit d1dfe21a332d38a6a09658ec29a55940afb5fe36 Author: Moti Haimovski Date: Sun Sep 8 15:01:26 2024 +0300 accel/habanalabs: support mapping cb with vmalloc-backed coherent memory [ Upstream commit 513024d5a0e34fd34247043f1876b6138ca52847 ] When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace. Signed-off-by: Moti Haimovski Reviewed-by: Koby Elbaz Signed-off-by: Koby Elbaz Signed-off-by: Sasha Levin commit 71b40ff8d30312d8d23c015a3e2132b9e121c12c Author: Konstantin Sinyuk Date: Tue Oct 1 15:52:27 2024 +0300 accel/habanalabs/gaudi2: read preboot status after recovering from dirty state [ Upstream commit a0d866bab184161ba155b352650083bf6695e50e ] Dirty state can occur when the host VM undergoes a reset while the device does not. In such a case, the driver must reset the device before it can be used again. As part of this reset, the device capabilities are zeroed. Therefore, the driver must read the Preboot status again to learn the Preboot state, capabilities, and security configuration. Signed-off-by: Konstantin Sinyuk Reviewed-by: Koby Elbaz Signed-off-by: Koby Elbaz Signed-off-by: Sasha Levin commit c53ac86de8e85d4582f3fea338735a5c3a942aff Author: Tomer Tayar Date: Sun May 26 16:32:32 2024 +0300 accel/habanalabs: return ENOMEM if less than requested pages were pinned [ Upstream commit 9f5067531c9b79318c4e48a933cb2694f53f3de2 ] EFAULT is currently returned if less than requested user pages are pinned. This value means a "bad address" which might be confusing to the user, as the address of the given user memory is not necessarily "bad". Modify the return value to ENOMEM, as "out of memory" is more suitable in this case. Signed-off-by: Tomer Tayar Reviewed-by: Koby Elbaz Signed-off-by: Koby Elbaz Signed-off-by: Sasha Levin commit 21aecbbff750297ab9980d6918aaace66a6ee713 Author: Ranjan Kumar Date: Mon Sep 22 15:21:12 2025 +0530 scsi: mpt3sas: Add support for 22.5 Gbps SAS link rate [ Upstream commit 4be7599d6b27bade41bfccca42901b917c01c30c ] Add handling for MPI26_SAS_NEG_LINK_RATE_22_5 in _transport_convert_phy_link_rate(). This maps the new 22.5 Gbps negotiated rate to SAS_LINK_RATE_22_5_GBPS, to get correct PHY link speeds. Signed-off-by: Ranjan Kumar Message-Id: <20250922095113.281484-4-ranjan.kumar@broadcom.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a71cf0a1100c08d4fb10cabed1bf8f454ee44ab6 Author: Vered Yavniely Date: Tue Jun 18 19:58:30 2024 +0300 accel/habanalabs/gaudi2: fix BMON disable configuration [ Upstream commit b4fd8e56c9a3b614370fde2d45aec1032eb67ddd ] Change the BMON_CR register value back to its original state before enabling, so that BMON does not continue to collect information after being disabled. Signed-off-by: Vered Yavniely Reviewed-by: Koby Elbaz Signed-off-by: Koby Elbaz Signed-off-by: Sasha Levin commit ac7872404a26f070c68c2e29c37f28a24518548d Author: Alok Tiwari Date: Mon Sep 15 11:37:57 2025 -0700 scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill() [ Upstream commit 072fdd4b0be9b9051bdf75f36d0227aa705074ba ] The fc_ct_ms_fill() helper currently formats the OS name and version into entry->value using "%s v%s". Since init_utsname()->sysname and ->release are unbounded strings, snprintf() may attempt to write more than FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN bytes, triggering a -Wformat-truncation warning with W=1. In file included from drivers/scsi/libfc/fc_elsct.c:18: drivers/scsi/libfc/fc_encode.h: In function ‘fc_ct_ms_fill.constprop’: drivers/scsi/libfc/fc_encode.h:359:30: error: ‘%s’ directive output may be truncated writing up to 64 bytes into a region of size between 62 and 126 [-Werror=format-truncation=] 359 | "%s v%s", | ^~ 360 | init_utsname()->sysname, 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/libfc/fc_encode.h:357:17: note: ‘snprintf’ output between 3 and 131 bytes into a destination of size 128 357 | snprintf((char *)&entry->value, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 358 | FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 359 | "%s v%s", | ~~~~~~~~~ 360 | init_utsname()->sysname, | ~~~~~~~~~~~~~~~~~~~~~~~~ 361 | init_utsname()->release); | ~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by using "%.62s v%.62s", which ensures sysname and release are truncated to fit within the 128-byte field defined by FC_FDMI_HBA_ATTR_OSNAMEVERSION_LEN. [mkp: clarified commit description] Signed-off-by: Alok Tiwari Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 50952c6c3c30c44d064f474ae8671f822427de6a Author: Petr Machata Date: Mon Sep 22 16:14:48 2025 +0200 net: bridge: Install FDB for bridge MAC on VLAN 0 [ Upstream commit cd9a9562b2559973aa1b68c3af63021a2c5fd022 ] Currently, after the bridge is created, the FDB does not hold an FDB entry for the bridge MAC on VLAN 0: # ip link add name br up type bridge # ip -br link show dev br br UNKNOWN 92:19:8c:4e:01:ed # bridge fdb show | grep 92:19:8c:4e:01:ed 92:19:8c:4e:01:ed dev br vlan 1 master br permanent Later when the bridge MAC is changed, or in fact when the address is given during netdevice creation, the entry appears: # ip link add name br up address 00:11:22:33:44:55 type bridge # bridge fdb show | grep 00:11:22:33:44:55 00:11:22:33:44:55 dev br vlan 1 master br permanent 00:11:22:33:44:55 dev br master br permanent However when the bridge address is set by the user to the current bridge address before the first port is enslaved, none of the address handlers gets invoked, because the address is not actually changed. The address is however marked as NET_ADDR_SET. Then when a port is enslaved, the address is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not added, and it has not been added previously either: # ip link add name br up type bridge # ip -br link show dev br br UNKNOWN 7e:f0:a8:1a:be:c2 # ip link set dev br addr 7e:f0:a8:1a:be:c2 # ip link add name v up type veth # ip link set dev v master br # ip -br link show dev br br UNKNOWN 7e:f0:a8:1a:be:c2 # bridge fdb | grep 7e:f0:a8:1a:be:c2 7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent Then when the bridge MAC is used as DMAC, and br_handle_frame_finish() looks up an FDB entry with VLAN=0, it doesn't find any, and floods the traffic instead of passing it up. Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always on netdevice creation. This also makes the behavior consistent with how ports are treated: ports always have an FDB entry for each member VLAN as well as VLAN 0. Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/415202b2d1b9b0899479a502bbe2ba188678f192.1758550408.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40be5b9080114f18b0cea386db415b68a7273c1a Author: Al Viro Date: Tue Sep 16 17:22:45 2025 +0100 nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ] Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0fc9604a42ee800f2a63fa9a247fa40fff7ae087 Author: Anthony Iliopoulos Date: Wed Aug 13 11:00:47 2025 +0200 NFSv4.1: fix mount hang after CREATE_SESSION failure [ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ] When client initialization goes through server trunking discovery, it schedules the state manager and then sleeps waiting for nfs_client initialization completion. The state manager can fail during state recovery, and specifically in lease establishment as nfs41_init_clientid() will bail out in case of errors returned from nfs4_proc_create_session(), without ever marking the client ready. The session creation can fail for a variety of reasons e.g. during backchannel parameter negotiation, with status -EINVAL. The error status will propagate all the way to the nfs4_state_manager but the client status will not be marked, and thus the mount process will remain blocked waiting. Fix it by adding -EINVAL error handling to nfs4_state_manager(). Signed-off-by: Anthony Iliopoulos Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 4904f473c4553418e39987b6f97386af51abeb09 Author: Olga Kornievskaia Date: Mon Aug 11 14:18:48 2025 -0400 NFSv4: handle ERR_GRACE on delegation recalls [ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ] RFC7530 states that clients should be prepared for the return of NFS4ERR_GRACE errors for non-reclaim lock and I/O requests. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 204ac63a8fecf759014ff85f514f0a48bbd61365 Author: Melissa Wen Date: Thu Sep 11 14:21:20 2025 -0300 drm/amd/display: change dc stream color settings only in atomic commit [ Upstream commit 51cb93aa0c4a9bb126b76f6e9fd640d88de25cee ] Don't update DC stream color components during atomic check. The driver will continue validating the new CRTC color state but will not change DC stream color components. The DC stream color state will only be programmed at commit time in the `atomic_setup_commit` stage. It fixes gamma LUT loss reported by KDE users when changing brightness quickly or changing Display settings (such as overscan) with nightlight on and HDR. As KWin can do a test commit with color settings different from those that should be applied in a non-test-only commit, if the driver changes DC stream color state in atomic check, this state can be eventually HW programmed in commit tail, instead of the respective state set by the non-blocking commit. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4444 Reported-by: Xaver Hugl Signed-off-by: Melissa Wen Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c424fce27e5cd14e6aec152d64f92015420e775a Author: Sridevi Arvindekar Date: Wed Sep 10 11:04:07 2025 -0400 drm/amd/display: Fix for test crash due to power gating [ Upstream commit 0bf6b216d4783cb51f9af05a49d3cce4fc22dc24 ] [Why/How] Call power gating routine only if it is defined. Reviewed-by: Alvin Lee Signed-off-by: Sridevi Arvindekar Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b9cb68d1aa2b34ec069abdff084e47f1a8ad0fa Author: Lo-an Chen Date: Mon Aug 25 18:16:24 2025 +0800 drm/amd/display: Init dispclk from bootup clock for DCN314 [ Upstream commit f082daf08f2ff313bdf9cf929a28f6d888117986 ] [Why] Driver does not pick up and save vbios's clocks during init clocks, the dispclk in clk_mgr will keep 0 until the first update clocks. In some cases, OS changes the timing in the second set mode (lower the pixel clock), causing the driver to lower the dispclk in prepare bandwidth, which is illegal and causes grey screen. [How] 1. Dump and save the vbios's clocks, and init the dispclk in dcn314_init_clocks. 2. Fix the condition in dcn314_update_clocks, regarding a 0kHz value. Reviewed-by: Charlene Liu Signed-off-by: Lo-an Chen Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5949255c589b8efe9b7bb1ac216744a78e1eb7c7 Author: Karthi Kandasamy Date: Wed Sep 3 14:16:27 2025 +0200 drm/amd/display: Add AVI infoframe copy in copy_stream_update_to_stream [ Upstream commit c8bedab2d9a1a0daa49ac20f9928a943f7205582 ] [WHY] Ensure AVI infoframe updates from stream updates are applied to the active stream so OS overrides are not lost. [HOW] Copy avi_infopacket to stream when valid flag is set. Follow existing infopacket copy pattern and perform a basic validity check before assignment. Reviewed-by: Aric Cyr Signed-off-by: Karthi Kandasamy Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 634e0468c31eca11462f2a23d5570ef3e78363d3 Author: Bastien Curutchet Date: Thu Sep 18 10:33:52 2025 +0200 net: dsa: microchip: Set SPI as bus interface during reset for KSZ8463 [ Upstream commit a0b977a3d19368b235f2a6c06e800fb25452029b ] At reset, the KSZ8463 uses a strap-based configuration to set SPI as bus interface. SPI is the only bus supported by the driver. If the required pull-ups/pull-downs are missing (by mistake or by design to save power) the pins may float and the configuration can go wrong preventing any communication with the switch. Introduce a ksz8463_configure_straps_spi() function called during the device reset. It relies on the 'straps-rxd-gpios' OF property and the 'reset' pinmux configuration to enforce SPI as bus interface. Reviewed-by: Andrew Lunn Signed-off-by: Bastien Curutchet (Schneider Electric) Link: https://patch.msgid.link/20250918-ksz-strap-pins-v3-3-16662e881728@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07d862c7de3d690a070e6bb08eb38e08395a9680 Author: Nithyanantham Paramasivam Date: Wed Aug 6 16:47:44 2025 +0530 wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256 [ Upstream commit 82993345aef6987a916337ebd2fca3ff4a6250a7 ] Increase DP_REO_CMD_RING_SIZE from 128 to 256 to avoid queuing failures observed during stress test scenarios. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Nithyanantham Paramasivam Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250806111750.3214584-2-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8ce228a03c855171af748d493e234f255a18fc23 Author: Stephan Gerhold Date: Wed Aug 20 18:02:34 2025 +0200 remoteproc: qcom: q6v5: Avoid handling handover twice [ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ] A remoteproc could theoretically signal handover twice. This is unexpected and would break the reference counting for the handover resources (power domains, clocks, regulators, etc), so add a check to prevent that from happening. Reviewed-by: Dmitry Baryshkov Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-2-910b1a3aff71@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a4a6e1c87880ed86e6efc8b3c7e35fb3b3e8328c Author: David Yang Date: Fri Sep 19 13:35:33 2025 +0800 selftests: forwarding: Reorder (ar)ping arguments to obey POSIX getopt [ Upstream commit 50d51cef555ee42fe47dd51b71366a77895e5f0b ] Quoted from musl wiki: GNU getopt permutes argv to pull options to the front, ahead of non-option arguments. musl and the POSIX standard getopt stop processing options at the first non-option argument with no permutation. Thus these scripts stop working on musl since non-option arguments for tools using getopt() (in this case, (ar)ping) do not always come last. Fix it by reordering arguments. Signed-off-by: David Yang Reviewed-by: Petr Machata Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20250919053538.1106753-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9200cc08d44c67c08db34ee0b6f7b345c62997b5 Author: Mario Limonciello Date: Mon Sep 8 22:19:15 2025 -0500 PCI/PM: Skip resuming to D0 if device is disconnected [ Upstream commit 299fad4133677b845ce962f78c9cf75bded63f61 ] When a device is surprise-removed (e.g., due to a dock unplug), the PCI core unconfigures all downstream devices and sets their error state to pci_channel_io_perm_failure. This marks them as disconnected via pci_dev_is_disconnected(). During device removal, the runtime PM framework may attempt to resume the device to D0 via pm_runtime_get_sync(), which calls into pci_power_up(). Since the device is already disconnected, this resume attempt is unnecessary and results in a predictable errors like this, typically when undocking from a TBT3 or USB4 dock with PCIe tunneling: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Avoid powering up disconnected devices by checking their status early in pci_power_up() and returning -EIO. Suggested-by: Lukas Wunner Signed-off-by: Mario Limonciello [bhelgaas: add typical message] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Ilpo Järvinen Acked-by: Rafael J. Wysocki Link: https://patch.msgid.link/20250909031916.4143121-1-superm1@kernel.org Signed-off-by: Sasha Levin commit 93b6099076f714d1bae0fa3d8f3c47dbaf660e20 Author: Weili Qian Date: Sat Sep 13 18:57:53 2025 +0800 crypto: hisilicon/qm - clear all VF configurations in the hardware [ Upstream commit 64b9642fc29a14e1fe67842be9c69c7b90a3bcd6 ] When disabling SR-IOV, clear the configuration of each VF in the hardware. Do not exit the configuration clearing process due to the failure of a single VF. Additionally, Clear the VF configurations before decrementing the PM counter. Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e551fa258ec9a5ece827011bf69d26abe9b418f3 Author: Weili Qian Date: Sat Sep 13 18:57:50 2025 +0800 crypto: hisilicon/qm - invalidate queues in use [ Upstream commit 85acd1b26b8f5b838887dc965dc3aa2c0253f4d1 ] Before the device reset, although the driver has set the queue status to intercept doorbells sent by the task process, the reset thread is isolated from the user-mode task process, so the task process may still send doorbells. Therefore, before the reset, the queue is directly invalidated, and the device directly discards the doorbells sent by the process. Signed-off-by: Weili Qian Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 76ff15eacef6aa5b27a809f27b05acce4415ce20 Author: Alex Mastro Date: Mon Sep 8 08:58:40 2025 -0700 vfio: return -ENOTTY for unsupported device feature [ Upstream commit 16df67f2189a71a8310bcebddb87ed569e8352be ] The two implementers of vfio_device_ops.device_feature, vfio_cdx_ioctl_feature and vfio_pci_core_ioctl_feature, return -ENOTTY in the fallthrough case when the feature is unsupported. For consistency, the base case, vfio_ioctl_device_feature, should do the same when device_feature == NULL, indicating an implementation has no feature extensions. Signed-off-by: Alex Mastro Link: https://lore.kernel.org/r/20250908-vfio-enotty-v1-1-4428e1539e2e@fb.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 59ef42bb3cf67211ae75f165c2c9506c3b3290fd Author: Al Viro Date: Sun Aug 10 04:42:08 2025 +0100 sparc64: fix prototypes of reads[bwl]() [ Upstream commit 7205ef77dfe167df1b83aea28cf00fc02d662990 ] Conventions for readsl() are the same as for readl() - any __iomem pointer is acceptable, both const and volatile ones being OK. Same for readsb() and readsw(). Signed-off-by: Al Viro Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson # Making sparc64 subject prefix Signed-off-by: Sasha Levin commit 4bfc756fef80b33554f0de035ec2cb117cf2c6f9 Author: Koakuma Date: Mon Jun 9 20:53:11 2025 +0700 sparc/module: Add R_SPARC_UA64 relocation handling [ Upstream commit 05457d96175d25c976ab6241c332ae2eb5e07833 ] This is needed so that the kernel can handle R_SPARC_UA64 relocations, which is emitted by LLVM's IAS. Signed-off-by: Koakuma Reviewed-by: Andreas Larsson Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 953eb3796ef06b8ea3bf6bdde14156255bc75866 Author: Chen Wang Date: Fri Sep 12 10:36:01 2025 +0800 PCI: cadence: Check for the existence of cdns_pcie::ops before using it [ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ] cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. Signed-off-by: Chen Wang [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com Signed-off-by: Sasha Levin commit d32bc92bf53eab1988356569f04711681d6d9576 Author: ChunHao Lin Date: Thu Sep 18 10:34:25 2025 +0800 r8169: set EEE speed down ratio to 1 [ Upstream commit bf7154ffb1c65a201906296a9d3eb22e9daa5ffc ] EEE speed down means speed down MAC MCU clock. It is not from spec. It is kind of Realtek specific power saving feature. But enable it may cause some issues, like packet drop or interrupt loss. Different hardware may have different issues. EEE speed down ratio (mac ocp 0xe056[7:4]) is used to set EEE speed down rate. The larger this value is, the more power can save. But it actually save less power then we expected. And, as mentioned above, will impact compatibility. So set it to 1 (mac ocp 0xe056[7:4] = 0) , which means not to speed down, to improve compatibility. Signed-off-by: ChunHao Lin Reviewed-by: Heiner Kallweit Link: https://patch.msgid.link/20250918023425.3463-1-hau@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 496188098d888e43901bbd04ff4b247573d4fd14 Author: Brahmajit Das Date: Tue Sep 2 12:54:22 2025 +0530 net: intel: fm10k: Fix parameter idx set but not used [ Upstream commit 99e9c5ffbbee0f258a1da4eadf602b943f8c8300 ] Variable idx is set in the loop, but is never used resulting in dead code. Building with GCC 16, which enables -Werror=unused-but-set-parameter= by default results in build error. This patch removes the idx parameter, since all the callers of the fm10k_unbind_hw_stats_q as 0 as idx anyways. Suggested-by: Vadim Fedorenko Signed-off-by: Brahmajit Das Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 522734fc807c62d2c4f6cbb6f8009b7437ab3672 Author: Ilan Peer Date: Mon Sep 8 14:13:04 2025 +0300 wifi: mac80211: Track NAN interface start/stop [ Upstream commit 8f79d2f13dd3b0af00a5303d4ff913767dd7684e ] In case that NAN is started, mark the device as non idle, and set LED triggering similar to scan and ROC. Set the device to idle once NAN is stopped. Signed-off-by: Ilan Peer Reviewed-by: Andrei Otcheretianski Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250908140015.2711d62fce22.I9b9f826490e50967a66788d713b0eba985879873@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8db790c2491e8ece65b77bafd28f1bcb6c25ba5c Author: Loic Poulain Date: Tue Sep 2 16:32:25 2025 +0200 wifi: ath10k: Fix connection after GTK rekeying [ Upstream commit 487e8a8c3421df0af3707e54c7e069f1d89cbda7 ] It appears that not all hardware/firmware implementations support group key deletion correctly, which can lead to connection hangs and deauthentication following GTK rekeying (delete and install). To avoid this issue, instead of attempting to delete the key using the special WMI_CIPHER_NONE value, we now replace the key with an invalid (random) value. This behavior has been observed with WCN39xx chipsets. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Reported-by: Alexey Klimov Closes: https://lore.kernel.org/all/DAWJQ2NIKY28.1XOG35E4A682G@linaro.org Signed-off-by: Loic Poulain Reviewed-by: Baochen Qiang Reviewed-by: Vasanthakumar Thiagarajan Tested-by: Alexey Klimov # QRB2210 RB1 Link: https://patch.msgid.link/20250902143225.837487-1-loic.poulain@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 3a5394b3b0b8263016bf5815bb3034d136dfdf86 Author: Seyediman Seyedarab Date: Thu Sep 18 13:01:58 2025 +0800 iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot() [ Upstream commit 75c02a037609f34db17e91be195cedb33b61bae0 ] snprintf() returns the number of bytes that would have been written, not the number actually written. Using this for offset tracking can cause buffer overruns if truncation occurs. Replace snprintf() with scnprintf() to ensure the offset stays within bounds. Since scnprintf() never returns a negative value, and zero is not possible in this context because 'bytes' starts at 0 and 'size - bytes' is DEBUG_BUFFER_SIZE in the first call, which is large enough to hold the string literals used, the return value is always positive. An integer overflow is also completely out of reach here due to the small and fixed buffer size. The error check in latency_show_one() is therefore unnecessary. Remove it and make dmar_latency_snapshot() return void. Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250731225048.131364-1-ImanDevel@gmail.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 0d06aa3007904ecb5411b09d9ba725a09371a2a9 Author: Vivek Pernamitta Date: Fri Sep 12 18:18:09 2025 +0530 bus: mhi: core: Improve mhi_sync_power_up handling for SYS_ERR state [ Upstream commit aa1a0e93ed21a06acb7ca9d4a4a9fce75ea53d0c ] Allow mhi_sync_power_up to handle SYS_ERR during power-up, reboot, or recovery. This is to avoid premature exit when MHI_PM_IN_ERROR_STATE is observed during above mentioned system states. To achieve this, treat SYS_ERR as a valid state and let its handler process the error and queue the next transition to Mission Mode instead of aborting early. Signed-off-by: Vivek Pernamitta [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250912-uevent_vdev_next-20250911-v4-5-fa2f6ccd301b@quicinc.com Signed-off-by: Sasha Levin commit 202d502593f5a19d0ceb290d79cdbe035cd83642 Author: Robert Marko Date: Wed Sep 17 13:00:24 2025 +0200 net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X [ Upstream commit 6287982aa54946449bccff3e6488d3a15e458392 ] LAN969x switchdev support depends on the SparX-5 core,so make it selectable for ARCH_LAN969X. Signed-off-by: Robert Marko Reviewed-by: Daniel Machon Link: https://patch.msgid.link/20250917110106.55219-1-robert.marko@sartura.hr Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 80d3bf09168e3d311ae4a0eb4717169f5727769f Author: Oleksij Rempel Date: Wed Sep 17 11:47:51 2025 +0200 net: phy: clear link parameters on admin link down [ Upstream commit 60f887b1290b43a4f5a3497982a725687b193fa4 ] When a PHY is halted (e.g. `ip link set dev lan2 down`), several fields in struct phy_device may still reflect the last active connection. This leads to ethtool showing stale values even though the link is down. Reset selected fields in _phy_state_machine() when transitioning to PHY_HALTED and the link was previously up: - speed/duplex -> UNKNOWN, but only in autoneg mode (in forced mode these fields carry configuration, not status) - master_slave_state -> UNKNOWN if previously supported - mdix -> INVALID (state only, same meaning as "unknown") - lp_advertising -> always cleared The cleanup is skipped if the PHY is in PHY_ERROR state, so the last values remain available for diagnostics. Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250917094751.2101285-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 75b756543922388f9887ee945e1b7fbdf1928760 Author: Alexey Klimov Date: Thu Sep 11 16:43:40 2025 +0100 ASoC: qcom: sc8280xp: explicitly set S16LE format in sc8280xp_be_hw_params_fixup() [ Upstream commit 9565c9d53c5b440f0dde6fa731a99c1b14d879d2 ] Setting format to s16le is required for compressed playback on compatible soundcards. Signed-off-by: Alexey Klimov Link: https://patch.msgid.link/20250911154340.2798304-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 35f3fb86bb0158a298d6834e7e110dcaf07f490c Author: Guangshuo Li Date: Thu Sep 18 18:57:05 2025 +0800 drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() [ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ] kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Signed-off-by: Guangshuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cbf2f527ae4ca7c7dabce42e85e8deb58588a37e Author: Shaurya Rane Date: Mon Aug 25 01:43:32 2025 +0530 jfs: fix uninitialized waitqueue in transaction manager [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ] The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit(). Reported-by: syzbot+c4f3462d8b2ad7977bea@syzkaller.appspotmail.com Signed-off-by: Shaurya Rane Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 1795277a4e98d82e6451544d43695540cee042ea Author: Tetsuo Handa Date: Fri Sep 12 23:18:44 2025 +0900 jfs: Verify inode mode when loading from disk [ Upstream commit 7a5aa54fba2bd591b22b9b624e6baa9037276986 ] The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 50610139823b552adaf552b84ae70f59780778e7 Author: Vlad Dumitrescu Date: Tue Sep 16 14:11:03 2025 +0300 IB/ipoib: Ignore L3 master device [ Upstream commit 42f993d3439827c4959ea77e60620d7ebfb3a477 ] Currently, all master upper netdevices (e.g., bond, VRF) are treated equally. When a VRF netdevice is used over an IPoIB netdevice, the expected netdev resolution is on the lower IPoIB device which has the IP address assigned to it and not the VRF device. The rdma_cm module (CMA) tries to match incoming requests to a particular netdevice. When successful, it also validates that the return path points to the same device by performing a routing table lookup. Currently, the former would resolve to the VRF netdevice, while the latter to the correct lower IPoIB netdevice, leading to failure in rdma_cm. Improve this by ignoring the VRF master netdevice, if it exists, and instead return the lower IPoIB device. Signed-off-by: Vlad Dumitrescu Reviewed-by: Parav Pandit Signed-off-by: Edward Srouji Link: https://patch.msgid.link/20250916111103.84069-5-edwards@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8ced3cb73ccd20e744deab7b49f2b7468c984eb2 Author: Tatyana Nikolova Date: Wed Aug 27 10:25:45 2025 -0500 RDMA/irdma: Update Kconfig [ Upstream commit 060842fed53f77a73824c9147f51dc6746c1267a ] Update Kconfig to add dependency on idpf module and add IPU E2000 to the list of supported devices. Signed-off-by: Tatyana Nikolova Link: https://patch.msgid.link/20250827152545.2056-17-tatyana.e.nikolova@intel.com Tested-by: Jacob Moroni Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8bb73ab12d939be2a03d94271b575bcfeac33e23 Author: Eric Dumazet Date: Tue Sep 16 16:09:44 2025 +0000 ipv6: np->rxpmtu race annotation [ Upstream commit 9fba1eb39e2f74d2002c5cbcf1d4435d37a4f752 ] Add READ_ONCE() annotations because np->rxpmtu can be changed while udpv6_recvmsg() and rawv6_recvmsg() read it. Since this is a very rarely used feature, and that udpv6_recvmsg() and rawv6_recvmsg() read np->rxopt anyway, change the test order so that np->rxpmtu does not need to be in a hot cache line. Signed-off-by: Eric Dumazet Reviewed-by: Willem de Bruijn Reviewed-by: David Ahern Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250916160951.541279-4-edumazet@google.com Reviewed-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e792e710e1fbd08c36a6bc63b9d3bdfb464c753f Author: Niklas Neronin Date: Thu Sep 18 00:07:22 2025 +0300 usb: xhci-pci: add support for hosts with zero USB3 ports [ Upstream commit 719de070f764e079cdcb4ddeeb5b19b3ddddf9c1 ] Add xhci support for PCI hosts that have zero USB3 ports. Avoid creating a shared Host Controller Driver (HCD) when there is only one root hub. Additionally, all references to 'xhci->shared_hcd' are now checked before use. Only xhci-pci.c requires modification to accommodate this change, as the xhci core already supports configurations with zero USB3 ports. This capability was introduced when xHCI Platform and MediaTek added support for zero USB3 ports. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181 Tested-by: Nick Nielsen Tested-by: grm1 Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 72f1984246e6ac06b5ae75b09a3dd709fd49c0cd Author: Zong-Zhe Yang Date: Mon Sep 15 14:53:43 2025 +0800 wifi: rtw89: renew a completion for each H2C command waiting C2H event [ Upstream commit bc2a5a12fa6259e190c7edb03e63b28ab480101b ] Logically before a waiting side which has already timed out turns the atomic status back to idle, a completing side could still pass atomic condition and call complete. It will make the following H2C commands, waiting C2H events, get a completion unexpectedly early. Hence, renew a completion for each H2C command waiting a C2H event. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250915065343.39023-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 336da4414300b41a51d87461330cd126ac333599 Author: Chih-Kang Chang Date: Mon Sep 15 14:52:06 2025 +0800 wifi: rtw89: obtain RX path from ppdu status IE00 [ Upstream commit e156d2ab36d7e47aec36845705e4ecb1e4e89976 ] The header v2 of ppdu status is optional, If it is not enabled, the RX path must be obtained from IE00 or IE01. Append the IE00 part. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250915065213.38659-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit c0b9951bb2668d67eb4817bb23fc109abc08c075 Author: wangzijie Date: Wed Sep 17 10:36:22 2025 +0800 f2fs: fix infinite loop in __insert_extent_tree() [ Upstream commit 23361bd54966b437e1ed3eb1a704572f4b279e58 ] When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case. Signed-off-by: wangzijie Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2cde2edef9ceb1090bec560107336824a6c49dde Author: Krishna Kurapati Date: Tue Sep 16 17:34:36 2025 +0530 usb: xhci: plat: Facilitate using autosuspend for xhci plat devices [ Upstream commit 41cf11946b9076383a2222bbf1ef57d64d033f66 ] Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs, when in host mode, it is intended that the controller goes to suspend state to save power and wait for interrupts from connected peripheral to wake it up. This is particularly used in cases where a HID or Audio device is connected. In such scenarios, the usb controller can enter auto suspend and resume action after getting interrupts from the connected device. Signed-off-by: Krishna Kurapati Link: https://lore.kernel.org/r/20250916120436.3617598-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8b2b310be1fe95e11c569fefbffca91aa6aa978c Author: Forest Crossman Date: Mon Sep 15 15:55:10 2025 -0400 usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs [ Upstream commit 368ed48a5ef52e384f54d5809f0a0b79ac567479 ] The usbmon binary interface currently truncates captures of large transfers from higher-speed USB devices. Because a single event capture is limited to one-fifth of the total buffer size, the current maximum size of a captured URB is around 240 KiB. This is insufficient when capturing traffic from modern devices that use transfers of several hundred kilobytes or more, as truncated URBs can make it impossible for user-space USB analysis tools like Wireshark to properly defragment and reassemble higher-level protocol packets in the captured data. The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has not been changed since the binary interface was introduced in 2006. To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The original comment for BUFF_MAX based the limit's calculation on a saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2 Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the buffer should be at least 50 MB. The new limit of 64 MiB covers that, plus a little extra for any overhead. With this change, both users and developers should now be able to debug and reverse engineer modern USB devices even when running unmodified distro kernels. Please note that this change does not affect the default buffer size. A larger buffer is only allocated when a user explicitly requests it via the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size should not unduly increase memory usage for users that don't deliberately request a larger buffer. Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com Signed-off-by: Forest Crossman Acked-by: Alan Stern Link: https://lore.kernel.org/r/CAO3ALPxU5RzcoueC454L=WZ1qGMfAcnxm+T+p+9D8O9mcrUbCQ@mail.gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 39f3ac9cc5ccec2d6f3c2cbac8be78e47481927d Author: Al Viro Date: Fri Sep 12 11:20:27 2025 -0400 allow finish_no_open(file, ERR_PTR(-E...)) [ Upstream commit fe91e078b60d1beabf5cef4a37c848457a6d2dfb ] ... allowing any ->lookup() return value to be passed to it. Reviewed-by: NeilBrown Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 4ae7e2d72da64bc3850a369867deda9769b15e2c Author: Justin Tee Date: Mon Sep 15 11:08:04 2025 -0700 scsi: lpfc: Ensure PLOGI_ACC is sent prior to PRLI in Point to Point topology [ Upstream commit 2bf81856a403c92a4ce375288f33fba82ca2ccc6 ] There is a timing race condition when a PRLI may be sent on the wire before PLOGI_ACC in Point to Point topology. Fix by deferring REG_RPI mbox completion handling to after PLOGI_ACC's CQE completion. Because the discovery state machine only sends PRLI after REG_RPI mbox completion, PRLI is now guaranteed to be sent after PLOGI_ACC. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-8-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fdf019f2a342bcdba6943bfbeb1bd144613ba9cd Author: Justin Tee Date: Mon Sep 15 11:08:05 2025 -0700 scsi: lpfc: Define size of debugfs entry for xri rebalancing [ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ] To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs entry is used. The debugfs file operations for xri rebalancing have been previously implemented, but lack definition for its information buffer size. Similar to other pre-existing debugfs entry buffers, define LPFC_HDWQINFO_SIZE as 8192 bytes. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-9-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 78273bfb21d9e4c026cb91396642f37555f731c9 Author: Justin Tee Date: Mon Sep 15 11:08:01 2025 -0700 scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in lpfc_cleanup [ Upstream commit a4809b98eb004fcbf7c4d45eb5a624d1c682bb73 ] In lpfc_cleanup, there is an extraneous nlp_put for NPIV ports on the F_Port_Ctrl ndlp object. In cases when an ABTS is issued, the outstanding kref is needed for when a second XRI_ABORTED CQE is received. The final kref for the ndlp is designed to be decremented in lpfc_sli4_els_xri_aborted instead. Also, add a new log message to allow for future diagnostics when debugging related issues. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-5-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dd475ead4bf7e3f1958264680a2f91573305574a Author: Justin Tee Date: Mon Sep 15 11:08:03 2025 -0700 scsi: lpfc: Check return status of lpfc_reset_flush_io_context during TGT_RESET [ Upstream commit f408dde2468b3957e92b25e7438f74c8e9fb9e73 ] If lpfc_reset_flush_io_context fails to execute, then the wrong return status code may be passed back to upper layers when issuing a target reset TMF command. Fix by checking the return status from lpfc_reset_flush_io_context() first in order to properly return FAILED or FAST_IO_FAIL. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-7-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 90b02095726f2ae8c3d5bdb71d08c97bff09508e Author: Justin Tee Date: Mon Sep 15 11:08:02 2025 -0700 scsi: lpfc: Decrement ndlp kref after FDISC retries exhausted [ Upstream commit b5bf6d681fce69cd1a57bfc0f1bdbbb348035117 ] The kref for Fabric_DID ndlps is not decremented after repeated FDISC failures and exhausting maximum allowed retries. This can leave the ndlp lingering unnecessarily. Add a test and set bit operation for the NLP_DROPPED flag. If not previously set, then a kref is decremented. The ndlp is freed when the remaining reference for the completing ELS is put. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-6-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 234cb3ca07c34ea9e73ccf163e4c8ff884db0bf7 Author: Justin Tee Date: Mon Sep 15 11:08:00 2025 -0700 scsi: lpfc: Clean up allocated queues when queue setup mbox commands fail [ Upstream commit 803dfd83df33b7565f23aef597d5dd036adfa792 ] lpfc_sli4_queue_setup() does not allocate memory and is used for submitting CREATE_QUEUE mailbox commands. Thus, if such mailbox commands fail we should clean up by also freeing the memory allocated for the queues with lpfc_sli4_queue_destroy(). Change the intended clean up label for the lpfc_sli4_queue_setup() error case to out_destroy_queue. Signed-off-by: Justin Tee Message-ID: <20250915180811.137530-4-justintee8345@gmail.com> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c6e1e2135d004d0d43f7c30551b0b6b625758e79 Author: Bart Van Assche Date: Tue Sep 9 12:06:07 2025 -0700 scsi: ufs: core: Disable timestamp functionality if not supported [ Upstream commit fb1f4568346153d2f80fdb4ffcfa0cf4fb257d3c ] Some Kioxia UFS 4 devices do not support the qTimestamp attribute. Set the UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT for these devices such that no error messages appear in the kernel log about failures to set the qTimestamp attribute. Signed-off-by: Bart Van Assche Reviewed-by: Avri Altman Tested-by: Nitin Rawat # on SM8650-QRD Reviewed-by: Nitin Rawat Reviewed-by: Peter Wang Reviewed-by: Manivannan Sadhasivam Message-ID: <20250909190614.3531435-1-bvanassche@acm.org> Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 961af1c22e55820e89f94f7481a2bdf1c6975ab8 Author: Nai-Chen Cheng Date: Wed Sep 10 19:30:32 2025 +0800 selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to clean net/lib dependency [ Upstream commit d3f7457da7b9527a06dbcbfaf666aa51ac2eeb53 ] The selftests 'make clean' does not clean the net/lib because it only processes $(TARGETS) and ignores $(INSTALL_DEP_TARGETS). This leaves compiled objects in net/lib after cleaning, requiring manual cleanup. Include $(INSTALL_DEP_TARGETS) in clean target to ensure net/lib dependency is properly cleaned. Signed-off-by: Nai-Chen Cheng Reviewed-by: Simon Horman Tested-by: Simon Horman # build-tested Acked-by: Shuah Khan Link: https://patch.msgid.link/20250910-selftests-makefile-clean-v1-1-29e7f496cd87@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f893ccd30b3f5a709e2efded32e6ee725d71a891 Author: Christian König Date: Wed Aug 27 13:14:43 2025 +0200 drm/amdgpu: reject gang submissions under SRIOV [ Upstream commit d7ddcf921e7d0d8ebe82e89635bc9dc26ba9540d ] Gang submission means that the kernel driver guarantees that multiple submissions are executed on the HW at the same time on different engines. Background is that those submissions then depend on each other and each can't finish stand alone. SRIOV now uses world switch to preempt submissions on the engines to allow sharing the HW resources between multiple VFs. The problem is now that the SRIOV world switch can't know about such inter dependencies and will cause a timeout if it waits for a partially running gang submission. To conclude SRIOV and gang submissions are fundamentally incompatible at the moment. For now just disable them. Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 91630b700fabd3548445cf564bbcd141a613456e Author: John Harrison Date: Tue Sep 9 15:41:31 2025 -0700 drm/xe/guc: Return an error code if the GuC load fails [ Upstream commit 3b09b11805bfee32d5a0000f5ede42c07237a6c4 ] Due to multiple explosion issues in the early days of the Xe driver, the GuC load was hacked to never return a failure. That prevented kernel panics and such initially, but now all it achieves is creating more confusing errors when the driver tries to submit commands to a GuC it already knows is not there. So fix that up. As a stop-gap and to help with debug of load failures due to invalid GuC init params, a wedge call had been added to the inner GuC load function. The reason being that it leaves the GuC log accessible via debugfs. However, for an end user, simply aborting the module load is much cleaner than wedging and trying to continue. The wedge blocks user submissions but it seems that various bits of the driver itself still try to submit to a dead GuC and lots of subsequent errors occur. And with regards to developers debugging why their particular code change is being rejected by the GuC, it is trivial to either add the wedge back in and hack the return code to zero again or to just do a GuC log dump to dmesg. v2: Add support for error injection testing and drop the now redundant wedge call. CC: Rodrigo Vivi Signed-off-by: John Harrison Reviewed-by: Matt Atwood Link: https://lore.kernel.org/r/20250909224132.536320-1-John.C.Harrison@Intel.com Signed-off-by: Sasha Levin commit 262e830ce16b07d0992798cec1dc5b074ba9a2e9 Author: Mario Limonciello (AMD) Date: Tue Sep 9 06:00:06 2025 -0500 HID: i2c-hid: Resolve touchpad issues on Dell systems during S4 [ Upstream commit 7d62beb102d6fa9a4e5e874be7fbf47a62fcc4f6 ] Dell systems utilize an EC-based touchpad emulation when the ACPI touchpad _DSM is not invoked. This emulation acts as a secondary master on the I2C bus, designed for scenarios where the I2C touchpad driver is absent, such as in BIOS menus. Typically, loading the i2c-hid module triggers the _DSM at initialization, disabling the EC-based emulation. However, if the i2c-hid module is missing from the boot kernel used for hibernation snapshot restoration, the _DSM remains uncalled, resulting in dual masters on the I2C bus and subsequent arbitration errors. This issue arises when i2c-hid resides in the rootfs instead of the kernel or initramfs. To address this, switch from using the SYSTEM_SLEEP_PM_OPS() macro to dedicated callbacks, introducing a specific callback for restoring the S4 image. This callback ensures the _DSM is invoked. Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 689ca6be7ee50b41dc0d99fb37ddf2f363fb75a8 Author: Stefan Wahren Date: Fri Sep 12 16:03:32 2025 +0200 ethernet: Extend device_get_mac_address() to use NVMEM [ Upstream commit d2d3f529e7b6ff2aa432b16a2317126621c28058 ] A lot of modern SoC have the ability to store MAC addresses in their NVMEM. So extend the generic function device_get_mac_address() to obtain the MAC address from an nvmem cell named 'mac-address' in case there is no firmware node which contains the MAC address directly. Signed-off-by: Stefan Wahren Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250912140332.35395-3-wahrenst@gmx.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3671a0775952026228ae44e096eb144bca75f8dc Author: Jakub Kicinski Date: Fri Sep 12 09:17:03 2025 -0700 page_pool: always add GFP_NOWARN for ATOMIC allocations [ Upstream commit f3b52167a0cb23b27414452fbc1278da2ee884fc ] Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default. Reviewed-by: Mina Almasry Link: https://patch.msgid.link/20250912161703.361272-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fccd5180fdf7d885a45f92e1dc6c15861f2e776 Author: Xi Ruoyao Date: Mon Aug 25 16:52:11 2025 +0800 drm/amd/display/dml2: Guard dml21_map_dc_state_into_dml_display_cfg with DC_FP_START [ Upstream commit c97a7dccb3ed680031011cfc1457506e6de49c9a ] dml21_map_dc_state_into_dml_display_cfg calls (the call is usually inlined by the compiler) populate_dml21_surface_config_from_plane_state and populate_dml21_plane_config_from_plane_state which may use FPU. In a x86-64 build: $ objdump --disassemble=dml21_map_dc_state_into_dml_display_cfg \ > drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_translation_helper.o | > grep %xmm -c 63 Thus it needs to be guarded with DC_FP_START. But we must note that the current code quality of the in-kernel FPU use in AMD dml2 is very much problematic: we are actually calling DC_FP_START in dml21_wrapper.c here, and this translation unit is built with CC_FLAGS_FPU. Strictly speaking this does not make any sense: with CC_FLAGS_FPU the compiler is allowed to generate FPU uses anywhere in the translated code, perhaps out of the DC_FP_START guard. This problematic pattern also occurs in at least dml2_wrapper.c, dcn35_fpu.c, and dcn351_fpu.c. Thus we really need a careful audit and refactor for the in-kernel FPU uses, and this patch is simply whacking a mole. However per the reporter, whacking this mole is enough to make a 9060XT "just work." Reported-by: Asiacn <710187964@qq.com> Closes: https://github.com/loongson-community/discussions/issues/102 Tested-by: Asiacn <710187964@qq.com> Signed-off-by: Xi Ruoyao Reviewed-by: Huacai Chen Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 15abc54efdcc6940163144582ff9d540655078b3 Author: Timur Kristóf Date: Mon Aug 25 23:56:30 2025 +0200 drm/amd/display: Disable VRR on DCE 6 [ Upstream commit 043c87d7d56e135393f8aab927148096e2d17589 ] DCE 6 was not advertised as being able to support VRR, so let's mark it as unsupported for now. The VRR implementation in amdgpu_dm depends on the VUPDATE interrupt which is not registered for DCE 6. Signed-off-by: Timur Kristóf Reviewed-by: Rodrigo Siqueira Reviewed-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cc9387df03f8032163c9c0c75cfe198b2135ff36 Author: Timur Kristóf Date: Mon Aug 25 23:33:33 2025 +0200 drm/amd/display: Fix DVI-D/HDMI adapters [ Upstream commit 489f0f600ce2c0dae640df9035e1d82677d2580f ] When the EDID has the HDMI bit, we should simply select the HDMI signal type even on DVI ports. For reference see, the legacy amdgpu display code: amdgpu_atombios_encoder_get_encoder_mode which selects ATOM_ENCODER_MODE_HDMI for the same case. This commit fixes DVI connectors to work with DVI-D/HDMI adapters so that they can now produce output over these connectors for HDMI monitors with higher bandwidth modes. With this change, even HDMI audio works through DVI. For testing, I used a CAA-DMDHFD3 DVI-D/HDMI adapter with the following GPUs: Tahiti (DCE 6) - DC can now output 4K 30 Hz over DVI Polaris 10 (DCE 11.2) - DC can now output 4K 60 Hz over DVI Signed-off-by: Timur Kristóf Acked-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 305cd0ca0efa2c8c06dafe1ac5e5cc077d7c35b3 Author: Mario Limonciello (AMD) Date: Mon Aug 11 12:00:06 2025 -0500 drm/amd: Avoid evicting resources at S5 [ Upstream commit 531df041f2a5296174abd8292d298eb62fe1ea97 ] Normally resources are evicted on dGPUs at suspend or hibernate and on APUs at hibernate. These steps are unnecessary when using the S4 callbacks to put the system into S5. Cc: AceLan Kao Cc: Kai-Heng Feng Cc: Mark Pearson Cc: Denis Benato Cc: Merthan Karakaş Tested-by: Eric Naim Acked-by: Alex Deucher Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bf3b34614f5e93b47039307b69e81dc4010a7f36 Author: Ausef Yousof Date: Tue Sep 2 12:10:18 2025 -0400 drm/amd/display: fix dml ms order of operations [ Upstream commit 02a6c2e4b28ff31f7a904c196a99fb2efe81e2cf ] [why&how] small error in order of operations in immediateflipbytes calculation on dml ms side that can result in dml ms and mp mismatch immediateflip support for a given pipe and thus an invalid hw state, correct the order to align with mp. Reviewed-by: Leo Chen Signed-off-by: Ausef Yousof Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit acf23b42132cc1a0aa17fc16a2227d7952cb512a Author: Mario Limonciello Date: Tue Aug 26 20:18:22 2025 -0500 drm/amd/display: Set up pixel encoding for YCBCR422 [ Upstream commit 5e76bc677cb7c92b37d8bc66bb67a18922895be2 ] [Why] fill_stream_properties_from_drm_display_mode() will not configure pixel encoding to YCBCR422 when the DRM color format supports YCBCR422 but not YCBCR420 or YCBCR4444. Instead it will fallback to RGB. [How] Add support for YCBCR422 in pixel encoding mapping. Suggested-by: Mauri Carvalho Reviewed-by: Wayne Lin Signed-off-by: Mario Limonciello Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c5b9a12c71f17842861706d2d2a746a6eb313f26 Author: Tvrtko Ursulin Date: Thu Jun 12 11:44:27 2025 +0100 drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl [ Upstream commit dea75df7afe14d6217576dbc28cc3ec1d1f712fb ] Replace kmalloc_array() + copy_from_user() with memdup_array_user(). This shrinks the source code and improves separation between the kernel and userspace slabs. Signed-off-by: Tvrtko Ursulin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit da91687f01f4640f89eb05f6bc782f002195d1b7 Author: Felix Fietkau Date: Mon Sep 15 09:59:00 2025 +0200 wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error [ Upstream commit 7c0f63fe37a5da2c13fc35c89053b31be8ead895 ] Free the allocated skb on error Link: https://patch.msgid.link/20250915075910.47558-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit bfb9d871844b40d2874d29ea6678716f31425a82 Author: John Keeping Date: Mon Sep 15 10:42:19 2025 +0100 ALSA: serial-generic: remove shared static buffer [ Upstream commit 84973249011fda3ff292f83439a062fec81ef982 ] If multiple instances of this driver are instantiated and try to send concurrently then the single static buffer snd_serial_generic_tx_work() will cause corruption in the data output. Move the buffer into the per-instance driver data to avoid this. Signed-off-by: John Keeping Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a534dd44b70e8ebfe986a07a087527950872d7e4 Author: Rosen Penev Date: Thu Sep 11 15:16:19 2025 -0700 wifi: mt76: mt76_eeprom_override to int [ Upstream commit c7c682100cec97b699fe24b26d89278fd459cc84 ] mt76_eeprom_override has of_get_mac_address, which can return -EPROBE_DEFER if the nvmem driver gets loaded after mt76 for some reason. Make sure this gets passed to probe so that nvmem mac overrides always work. Signed-off-by: Rosen Penev Link: https://patch.msgid.link/20250911221619.16035-1-rosenp@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit aa5ed215cfe87c5fffd27be90b8d73aabe543146 Author: Benjamin Lin Date: Thu Sep 4 09:56:42 2025 +0200 wifi: mt76: mt7996: Temporarily disable EPCS [ Upstream commit e6291bb7a5935b2f1d337fd7a58eab7ada6678ad ] EPCS is not yet ready, so do not claim to support it. Signed-off-by: Benjamin Lin Co-developed-by: Lorenzo Bianconi Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20250904-mt7996-mlo-more-fixes-v1-4-89d8fed67f20@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit efe2ef24feab096e34cd57bed5517467c6f7d00b Author: Quan Zhou Date: Thu Aug 28 20:39:42 2025 +0800 wifi: mt76: mt7921: Add 160MHz beamformee capability for mt7922 device [ Upstream commit 25ef5b5d02ac03fe8dd91cf25bd011a570fbeba2 ] Enable 160MHz beamformee support on mt7922 by updating HE capability element configuration. Previously, only 160MHz channel width was set, but beamformee for 160MHz was not properly advertised. This patch adds BEAMFORMEE_MAX_STS_ABOVE_80MHZ_4 capability to allow devices to utilize 160MHz BW for beamforming. Tested by connecting to 160MHz-bandwidth beamforming AP and verified HE capability. Signed-off-by: Quan Zhou Link: https://patch.msgid.link/ae637afaffed387018fdc43709470ef65898ff0b.1756383627.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 06a2fc1d1ef0dc72d6155e2bef7f286bb17932e8 Author: Yafang Shao Date: Tue Sep 2 14:29:33 2025 +0800 net/cls_cgroup: Fix task_get_classid() during qdisc run [ Upstream commit 66048f8b3cc7e462953c04285183cdee43a1cb89 ] During recent testing with the netem qdisc to inject delays into TCP traffic, we observed that our CLS BPF program failed to function correctly due to incorrect classid retrieval from task_get_classid(). The issue manifests in the following call stack: bpf_get_cgroup_classid+5 cls_bpf_classify+507 __tcf_classify+90 tcf_classify+217 __dev_queue_xmit+798 bond_dev_queue_xmit+43 __bond_start_xmit+211 bond_start_xmit+70 dev_hard_start_xmit+142 sch_direct_xmit+161 __qdisc_run+102 <<<<< Issue location __dev_xmit_skb+1015 __dev_queue_xmit+637 neigh_hh_output+159 ip_finish_output2+461 __ip_finish_output+183 ip_finish_output+41 ip_output+120 ip_local_out+94 __ip_queue_xmit+394 ip_queue_xmit+21 __tcp_transmit_skb+2169 tcp_write_xmit+959 __tcp_push_pending_frames+55 tcp_push+264 tcp_sendmsg_locked+661 tcp_sendmsg+45 inet_sendmsg+67 sock_sendmsg+98 sock_write_iter+147 vfs_write+786 ksys_write+181 __x64_sys_write+25 do_syscall_64+56 entry_SYSCALL_64_after_hwframe+100 The problem occurs when multiple tasks share a single qdisc. In such cases, __qdisc_run() may transmit skbs created by different tasks. Consequently, task_get_classid() retrieves an incorrect classid since it references the current task's context rather than the skb's originating task. Given that dev_queue_xmit() always executes with bh disabled, we can use softirq_count() instead to obtain the correct classid. The simple steps to reproduce this issue: 1. Add network delay to the network interface: such as: tc qdisc add dev bond0 root netem delay 1.5ms 2. Build two distinct net_cls cgroups, each with a network-intensive task 3. Initiate parallel TCP streams from both tasks to external servers. Under this specific condition, the issue reliably occurs. The kernel eventually dequeues an SKB that originated from Task-A while executing in the context of Task-B. It is worth noting that it will change the established behavior for a slightly different scenario: prior to this patch the skb will be classified with the 'new' task A classid, now with the old/original one. The bpf_get_cgroup_classid_curr() function is a more appropriate choice for this case. Signed-off-by: Yafang Shao Cc: Daniel Borkmann Cc: Thomas Graf Cc: Sebastian Andrzej Siewior Cc: Nikolay Aleksandrov Link: https://patch.msgid.link/20250902062933.30087-1-laoar.shao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 082dbb39af03682c030384d6c2a7b23e1c083ea1 Author: Gaurav Jain Date: Fri Sep 5 15:41:48 2025 +0530 crypto: caam - double the entropy delay interval for retry [ Upstream commit 9048beca9c5614d486e2b492c0a7867164bf56a8 ] during entropy evaluation, if the generated samples fail any statistical test, then, all of the bits will be discarded, and a second set of samples will be generated and tested. the entropy delay interval should be doubled before performing the retry. also, ctrlpriv->rng4_sh_init and inst_handles both reads RNG DRNG status register, but only inst_handles is updated before every retry. so only check inst_handles and removing ctrlpriv->rng4_sh_init Signed-off-by: Gaurav Jain Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dcfd2557325ac4b8e8c4bd35bfef884c7e41110b Author: Yunseong Kim Date: Wed Sep 3 22:16:43 2025 +0900 crypto: ccp - Fix incorrect payload size calculation in psp_poulate_hsti() [ Upstream commit 2b0dc40ac6ca16ee0c489927f4856cf9cd3874c7 ] payload_size field of the request header is incorrectly calculated using sizeof(req). Since 'req' is a pointer (struct hsti_request *), sizeof(req) returns the size of the pointer itself (e.g., 8 bytes on a 64-bit system), rather than the size of the structure it points to. This leads to an incorrect payload size being sent to the Platform Security Processor (PSP), potentially causing the HSTI query command to fail. Fix this by using sizeof(*req) to correctly calculate the size of the struct hsti_request. Signed-off-by: Yunseong Kim Reviewed-by: Mario Limonciello (AMD) > --- Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c65a83bcc90fbb3c9b4fba4e7cf37b1eb39db180 Author: Niklas Cassel Date: Mon Sep 8 18:59:15 2025 +0200 PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify() [ Upstream commit 09fefb24ed5e15f3b112f6c04b21a90ea23eaf8b ] dw_pcie_edma_irq_verify() is supposed to verify the eDMA IRQs in devicetree by fetching them using either 'dma' or 'dmaX' IRQ names. Former is used when the platform uses a single IRQ for all eDMA channels and latter is used when the platform uses separate IRQ per channel. But currently, dw_pcie_edma_irq_verify() bails out early if edma::nr_irqs is 1, i.e., when a single IRQ is used. This gives an impression that the driver could work with any single IRQ in devicetree, not necessarily with name 'dma'. But dw_pcie_edma_irq_vector(), which actually requests the IRQ, does require the single IRQ to be named as 'dma'. So this creates inconsistency between dw_pcie_edma_irq_verify() and dw_pcie_edma_irq_vector(). Thus, to fix this inconsistency, make sure dw_pcie_edma_irq_verify() also verifies the single IRQ name by removing the bail out code. Signed-off-by: Niklas Cassel [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam [bhelgaas: fix typos] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250908165914.547002-3-cassel@kernel.org Signed-off-by: Sasha Levin commit 1b3b8b67773e9e04bfb7037f23e3d528acab0940 Author: Ovidiu Panait Date: Tue Sep 2 16:21:26 2025 +0300 crypto: sun8i-ce - remove channel timeout field [ Upstream commit 9a23ea1f7558bdd3f8d2b35b1c2e16a2f9bf671e ] Using the number of bytes in the request as DMA timeout is really inconsistent, as large requests could possibly set a timeout of hundreds of seconds. Remove the per-channel timeout field and use a single, static DMA timeout of 3 seconds for all requests. Signed-off-by: Ovidiu Panait Tested-by: Corentin LABBE Reviewed-by: Corentin LABBE Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 09d0da8d29a2fe82065a56c7fd851ffd16ab5240 Author: Sangwook Shin Date: Mon Aug 18 11:18:23 2025 +0900 watchdog: s3c2410_wdt: Fix max_timeout being calculated larger [ Upstream commit df3c6e0b6d83450563d6266e1dacc7eaf25511f4 ] Fix the issue of max_timeout being calculated larger than actual value. The calculation result of freq / (S3C2410_WTCON_PRESCALE_MAX + 1) / S3C2410_WTCON_MAXDIV is smaller than the actual value because the remainder is discarded during the calculation process. This leads to a larger calculated value for max_timeout compared to the actual settable value. To resolve this issue, the order of calculations in the computation process has been adjusted. Reviewed-by: Sam Protsenko Signed-off-by: Sangwook Shin Reviewed-by: Guenter Roeck Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 77a3e9b0b3cd9e0f07238cd88b4a366ef370d6bf Author: Antheas Kapenekakis Date: Thu Aug 14 15:01:51 2025 +0200 HID: asus: add Z13 folio to generic group for multitouch to work [ Upstream commit b595974b4afe0e171dd707da570964ff642742e3 ] The Asus Z13 folio has a multitouch touchpad that needs to bind to the hid-multitouch driver in order to work properly. So bind it to the HID_GROUP_GENERIC group to release the touchpad and move it to the bottom so that the comment applies to it. While at it, change the generic KEYBOARD3 name to Z13_FOLIO. Reviewed-by: Luke D. Jones Signed-off-by: Antheas Kapenekakis Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 51b3033088f0420b19027e3d54cd989b6ebd987e Author: Alok Tiwari Date: Wed Sep 10 12:50:26 2025 -0700 udp_tunnel: use netdev_warn() instead of netdev_WARN() [ Upstream commit dc2f650f7e6857bf384069c1a56b2937a1ee370d ] netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly. Signed-off-by: Alok Tiwari Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910195031.3784748-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcd4e9fc4f181b1c7e295d993587035f93d84519 Author: Stanislav Fomichev Date: Wed Sep 10 09:24:29 2025 -0700 net: devmem: expose tcp_recvmsg_locked errors [ Upstream commit 18282100d7040614b553f1cad737cb689c04e2b9 ] tcp_recvmsg_dmabuf can export the following errors: - EFAULT when linear copy fails - ETOOSMALL when cmsg put fails - ENODEV if one of the frags is readable - ENOMEM on xarray failures But they are all ignored and replaced by EFAULT in the caller (tcp_recvmsg_locked). Expose real error to the userspace to add more transparency on what specifically fails. In non-devmem case (skb_copy_datagram_msg) doing `if (!copied) copied=-EFAULT` is ok because skb_copy_datagram_msg can return only EFAULT. Reviewed-by: David Ahern Reviewed-by: Mina Almasry Reviewed-by: Eric Dumazet Signed-off-by: Stanislav Fomichev Link: https://patch.msgid.link/20250910162429.4127997-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5a02be42517d4d18a7d7982ad88dde38240bd43 Author: David Ahern Date: Tue Sep 9 20:58:28 2025 -0600 selftests: Replace sleep with slowwait [ Upstream commit 2f186dd5585c3afb415df80e52f71af16c9d3655 ] Replace the sleep in kill_procs with slowwait. Signed-off-by: David Ahern Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910025828.38900-2-dsahern@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c25b38929e7d848c735d64ffb941040adf87b0d Author: Daniel Palmer Date: Sun Sep 7 15:43:49 2025 +0900 eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP [ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ] When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range() and from there __pci_ioport_map() for the PCI IO space. If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will always fail and the driver will complain it couldn't map the PIO space and return an error. NO_IOPORT_MAP seems to cover the case where what 8139too is trying to do cannot ever work so make 8139TOO_PIO depend on being it false and avoid creating an unusable driver. Signed-off-by: Daniel Palmer Link: https://patch.msgid.link/20250907064349.3427600-1-daniel@thingy.jp Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ce0145574d7483177c14ecdee8cf5bf3369f37e9 Author: David Ahern Date: Tue Sep 9 20:58:27 2025 -0600 selftests: Disable dad for ipv6 in fcnal-test.sh [ Upstream commit 53d591730ea34f97a82f7ec6e7c987ca6e34dc21 ] Constrained test environment; duplicate address detection is not needed and causes races so disable it. Signed-off-by: David Ahern Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250910025828.38900-1-dsahern@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 32718b63671ec81fc410e666f962e54afb0e2782 Author: Li RongQing Date: Tue Jul 22 19:00:05 2025 +0800 x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of PV_UNHALT [ Upstream commit 960550503965094b0babd7e8c83ec66c8a763b0b ] The commit b2798ba0b876 ("KVM: X86: Choose qspinlock when dedicated physical CPUs are available") states that when PV_DEDICATED=1 (vCPU has dedicated pCPU), qspinlock should be preferred regardless of PV_UNHALT. However, the current implementation doesn't reflect this: when PV_UNHALT=0, we still use virt_spin_lock() even with dedicated pCPUs. This is suboptimal because: 1. Native qspinlocks should outperform virt_spin_lock() for dedicated vCPUs irrespective of HALT exiting 2. virt_spin_lock() should only be preferred when vCPUs may be preempted (non-dedicated case) So reorder the PV spinlock checks to: 1. First handle dedicated pCPU case (disable virt_spin_lock_key) 2. Second check single CPU, and nopvspin configuration 3. Only then check PV_UNHALT support This ensures we always use native qspinlock for dedicated vCPUs, delivering pretty performance gains at high contention levels. Signed-off-by: Li RongQing Reviewed-by: Sean Christopherson Tested-by: Wangyang Guo Link: https://lore.kernel.org/r/20250722110005.4988-1-lirongqing@baidu.com Signed-off-by: Sean Christopherson Signed-off-by: Sasha Levin commit 7f56d81d1c3d8602132271b5e08979d301b8b562 Author: Florian Westphal Date: Fri Aug 29 17:01:02 2025 +0200 netfilter: nf_reject: don't reply to icmp error messages [ Upstream commit db99b2f2b3e2cd8227ac9990ca4a8a31a1e95e56 ] tcp reject code won't reply to a tcp reset. But the icmp reject 'netdev' family versions will reply to icmp dst-unreach errors, unlike icmp_send() and icmp6_send() which are used by the inet family implementation (and internally by the REJECT target). Check for the icmp(6) type and do not respond if its an unreachable error. Without this, something like 'ip protocol icmp reject', when used in a netdev chain attached to 'lo', cause a packet loop. Same for two hosts that both use such a rule: each error packet will be replied to. Such situation persist until the (bogus) rule is amended to ratelimit or checks the icmp type before the reject statement. As the inet versions don't do this make the netdev ones follow along. Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 483886e1f7760c41c06effd292b81e020202d3e0 Author: chenmiao Date: Fri Sep 5 18:12:56 2025 +0000 openrisc: Add R_OR1K_32_PCREL relocation type module support [ Upstream commit 9d0cb6d00be891586261a35da7f8c3c956825c39 ] To ensure the proper functioning of the jump_label test module, this patch adds support for the R_OR1K_32_PCREL relocation type for any modules. The implementation calculates the PC-relative offset by subtracting the instruction location from the target value and stores the result at the specified location. Signed-off-by: chenmiao Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 317d3bbc222200abca6117a9ab8e0c0e2016b07c Author: Ido Schimmel Date: Mon Sep 8 10:32:34 2025 +0300 selftests: traceroute: Return correct value on failure [ Upstream commit c068ba9d3ded56cb1ba4d5135ee84bf8039bd563 ] The test always returns success even if some tests were modified to fail. Fix by converting the test to use the appropriate library functions instead of using its own functions. Before: # ./traceroute.sh TEST: IPV6 traceroute [FAIL] TEST: IPV4 traceroute [ OK ] Tests passed: 1 Tests failed: 1 $ echo $? 0 After: # ./traceroute.sh TEST: IPv6 traceroute [FAIL] traceroute6 did not return 2000:102::2 TEST: IPv4 traceroute [ OK ] $ echo $? 1 Reviewed-by: Petr Machata Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250908073238.119240-5-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 51d35366f917502dc247c534d31a53575fe13aa7 Author: Ido Schimmel Date: Mon Sep 8 10:32:35 2025 +0300 selftests: traceroute: Use require_command() [ Upstream commit 47efbac9b768553331b9459743a29861e0acd797 ] Use require_command() so that the test will return SKIP (4) when a required command is not present. Before: # ./traceroute.sh SKIP: Could not run IPV6 test without traceroute6 SKIP: Could not run IPV4 test without traceroute $ echo $? 0 After: # ./traceroute.sh TEST: traceroute6 not installed [SKIP] $ echo $? 4 Reviewed-by: Petr Machata Reviewed-by: David Ahern Signed-off-by: Ido Schimmel Link: https://patch.msgid.link/20250908073238.119240-6-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1ca27d3174864847d5f5ec21dcbb1d0626a8de98 Author: Qianfeng Rong Date: Wed Aug 27 20:39:13 2025 +0800 media: redrat3: use int type to store negative error codes [ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ] Change "ret" from u8 to int type in redrat3_enable_detector() to store negative error codes or zero returned by redrat3_send_cmd() and usb_submit_urb() - this better aligns with the coding standards and maintains code consistency. No effect on runtime. Signed-off-by: Qianfeng Rong Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f4a427973f9252124cac00e4fb0cb709a308ac83 Author: Jakub Kicinski Date: Tue Sep 9 15:38:37 2025 -0700 selftests: net: replace sleeps in fcnal-test with waits [ Upstream commit 15c068cb214d74a2faca9293b25f454242d0d65e ] fcnal-test.sh already includes lib.sh, use relevant helpers instead of sleeping. Replace sleep after starting nettest as a server with wait_local_port_listen. Reviewed-by: David Ahern Link: https://patch.msgid.link/20250909223837.863217-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2d440f2c1d1d41e268811d99752a220939257d7 Author: Niklas Söderlund Date: Tue Sep 9 10:58:49 2025 +0200 net: sh_eth: Disable WoL if system can not suspend [ Upstream commit 9c02ea544ac35a9def5827d30594406947ccd81a ] The MAC can't facilitate WoL if the system can't go to sleep. Gate the WoL support callbacks in ethtool at compile time using CONFIG_PM_SLEEP. Signed-off-by: Niklas Söderlund Reviewed-by: Andrew Lunn Reviewed-by: Geert Uytterhoeven Link: https://patch.msgid.link/20250909085849.3808169-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 32f3d1e812f3ed55e3dc8151f9ef50ec6ecaa479 Author: Rob Clark Date: Mon Sep 8 12:30:07 2025 -0700 drm/msm/registers: Generate _HI/LO builders for reg64 [ Upstream commit 60e9f776b7932d67c88e8475df7830cb9cdf3154 ] The upstream mesa copy of the GPU regs has shifted more things to reg64 instead of seperate 32b HI/LO reg32's. This works better with the "new- style" c++ builders that mesa has been migrating to for a6xx+ (to better handle register shuffling between gens), but it leaves the C builders with missing _HI/LO builders. So handle the special case of reg64, automatically generating the missing _HI/LO builders. Signed-off-by: Rob Clark Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/673559/ Signed-off-by: Sasha Levin commit 66bb2a020d5945a94e76fc1dfa92e166b272270e Author: Michael Riesch Date: Wed Sep 3 19:04:52 2025 +0200 phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0 [ Upstream commit 8c7c19466c854fa86b82d2148eaa9bf0e6531423 ] The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF this offset is perfectly fine (in fact, register 0 is the only one in this register file). Introduce a boolean variable to indicate valid registers and allow writes to register 0. Reviewed-by: Neil Armstrong Signed-off-by: Michael Riesch Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-4-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1539159cf20893f83b3185ef26938a0cd5a9a83f Author: Michael Dege Date: Thu Jul 3 13:07:24 2025 +0200 phy: renesas: r8a779f0-ether-serdes: add new step added to latest datasheet [ Upstream commit e4a8db93b5ec9bca1cc66b295544899e3afd5e86 ] R-Car S4-8 datasheet Rev.1.20 describes some additional register settings at the end of the initialization. Signed-off-by: Michael Dege Link: https://lore.kernel.org/r/20250703-renesas-serdes-update-v4-2-1db5629cac2b@renesas.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3e9223eeb143a9b51b24c68373eaf4f5c5ff6a4a Author: Mario Limonciello (AMD) Date: Mon Aug 11 11:26:03 2025 -0500 Fix access to video_is_primary_device() when compiled without CONFIG_VIDEO [ Upstream commit 6e490dea61b88aac9762c9f79a54aad4ea2e6cd1 ] When compiled without CONFIG_VIDEO the architecture specific implementations of video_is_primary_device() include prototypes and assume that video-common.c will be linked. Guard against this so that the fallback inline implementation that returns false will be used when compiled without CONFIG_VIDEO. Acked-by: Thomas Zimmermann Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506221312.49Fy1aNA-lkp@intel.com/ Link: https://lore.kernel.org/r/20250811162606.587759-2-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 88f1caa0cdd8f2e79e6c4fa2765185b43c805555 Author: Harikrishna Shenoy Date: Thu Aug 7 10:50:02 2025 +0530 phy: cadence: cdns-dphy: Enable lower resolutions in dphy [ Upstream commit 43bd2c44515f8ee5c019ce6e6583f5640387a41b ] Enable support for data lane rates between 80-160 Mbps cdns dphy as mentioned in TRM [0] by setting the pll_opdiv field to 16. This change enables lower resolutions like 640x480 at 60Hz. [0]: https://www.ti.com/lit/zip/spruil1 (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions) Reviewed-by: Udit Kumar Reviewed-by: Devarsh Thakkar Signed-off-by: Harikrishna Shenoy Link: https://lore.kernel.org/r/20250807052002.717807-1-h-shenoy@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5de410dfb4d9019e2efb366b0577041bc6c1f5ea Author: Ilan Peer Date: Sun Sep 7 11:51:17 2025 +0300 wifi: mac80211: Fix HE capabilities element check [ Upstream commit ea928544f3215fdeac24d66bef85e10bb638b8c1 ] The element data length check did not account for the extra octet used for the extension ID. Fix it. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250907115109.8da0012e2286.I8c0c69a0011f7153c13b365b14dfef48cfe7c3e3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 37f65e68ba9852dc51c78dbb54a9881c3f0fe4f7 Author: Tetsuo Handa Date: Tue Sep 2 19:43:24 2025 +0900 ntfs3: pretend $Extend records as regular files [ Upstream commit 4e8011ffec79717e5fdac43a7e79faf811a384b7 ] Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 9c899984def9955e9bb6b650842945437e5bf9ba Author: Peter Wang Date: Wed Sep 3 10:44:42 2025 +0800 scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode changes [ Upstream commit f5ca8d0c7a6388abd5d8023cc682e1543728cc73 ] Disable auto-hibern8 during power mode transitions to prevent unintended entry into auto-hibern8. Restore the original auto-hibern8 timer value after completing the power mode change to maintain system stability and prevent potential issues during power state transitions. Signed-off-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 10ad4de87f32c8a93d95ca2c29bcfbd3abbfddab Author: Peter Wang Date: Wed Sep 3 10:44:39 2025 +0800 scsi: ufs: host: mediatek: Correct system PM flow [ Upstream commit 77b96ef70b6ba46e3473e5e3a66095c4bc0e93a4 ] Refine the system power management (PM) flow by skipping low power mode (LPM) and MTCMOS settings if runtime PM is already applied. Prevent redundant operations to ensure a more efficient PM process. Signed-off-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 70b956be58696247a83860da626076bd014251ef Author: Rohan G Thomas Date: Sat Sep 6 10:33:31 2025 +0800 net: phy: marvell: Fix 88e1510 downshift counter errata [ Upstream commit deb105f49879dd50d595f7f55207d6e74dec34e6 ] The 88e1510 PHY has an erratum where the phy downshift counter is not cleared after phy being suspended(BMCR_PDOWN set) and then later resumed(BMCR_PDOWN cleared). This can cause the gigabit link to intermittently downshift to a lower speed. Disabling and re-enabling the downshift feature clears the counter, allowing the PHY to retry gigabit link negotiation up to the programmed retry count times before downshifting. This behavior has been observed on copper links. Signed-off-by: Rohan G Thomas Reviewed-by: Matthew Gerlach Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250906-marvell_fix-v2-1-f6efb286937f@altera.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7783805fb864af2cba26d335db6b17182eea3eba Author: Peter Wang Date: Wed Sep 3 10:44:37 2025 +0800 scsi: ufs: host: mediatek: Enhance recovery on hibernation exit failure [ Upstream commit faac32d4ece30609f1a0930ca0ae951cf6dc1786 ] Improve the recovery process for hibernation exit failures. Trigger the error handler and break the suspend operation to ensure effective recovery from hibernation errors. Activate the error handling mechanism by ufshcd_force_error_recovery and scheduling the error handler work. Signed-off-by: Peter Wang Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0a762d32f1387bfe32f5942ac6b74faa656b46a6 Author: Peter Wang Date: Wed Sep 3 10:44:45 2025 +0800 scsi: ufs: host: mediatek: Fix unbalanced IRQ enable issue [ Upstream commit 91cad911edd1612ed28f5cfb2d4c53a8824951a5 ] Resolve the issue of unbalanced IRQ enablement by setting the 'is_mcq_intr_enabled' flag after the first successful IRQ enablement. Ensure proper tracking of the IRQ state and prevent potential mismatches in IRQ handling. Signed-off-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 074ecd24d0418d0ec53aebbc0cc48b689e22769e Author: Peter Wang Date: Wed Sep 3 10:44:38 2025 +0800 scsi: ufs: host: mediatek: Enhance recovery on resume failure [ Upstream commit 15ef3f5aa822f32524cba1463422a2c9372443f0 ] Improve the recovery process for failed resume operations. Log the device's power status and return 0 if both resume and recovery fail to prevent I/O hang. Signed-off-by: Peter Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a8482a6d412c93326ce784ef67a288f4b0a209da Author: Matthieu Baerts (NGI0) Date: Sun Sep 7 17:32:44 2025 +0200 selftests: mptcp: join: allow more time to send ADD_ADDR [ Upstream commit e2cda6343bfe459c3331db5afcd675ab333112dd ] When many ADD_ADDR need to be sent, it can take some time to send each of them, and create new subflows. Some CIs seem to occasionally have issues with these tests, especially with "debug" kernels. Two subtests will now run for a slightly longer time: the last two where 3 or more ADD_ADDR are sent during the test. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20250907-net-next-mptcp-add_addr-retrans-adapt-v1-3-824cc805772b@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d8ea98ebb08eda541dbe5516b9be52eccccd10c Author: Jaegeuk Kim Date: Tue Sep 9 00:26:06 2025 +0000 f2fs: fix wrong layout information on 16KB page [ Upstream commit a33be64b98d0723748d2fab0832b926613e1fce0 ] This patch fixes to support different block size. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e53f250bd1977d34b036fe237c8ad18f1af9dbd7 Author: Vladimir Zapolskiy Date: Sat Aug 23 16:22:06 2025 +0300 media: i2c: og01a1b: Specify monochrome media bus format instead of Bayer [ Upstream commit bfbd5aa5347fbd11ade188b316b800bfb27d9e22 ] The OmniVision OG01A1B image sensor is a monochrome sensor, it supports 8-bit and 10-bit RAW output formats only. That said the planar greyscale Y8/Y10 media formats are more appropriate for the sensor instead of the originally and arbitrary selected SGRBG one, since there is no red, green or blue color components. Signed-off-by: Vladimir Zapolskiy Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 1e792110823e904ecff2d9e79ae1a81efd786c8e Author: Hao Yao Date: Fri Apr 25 12:33:25 2025 +0800 media: ov08x40: Fix the horizontal flip control [ Upstream commit c7df6f339af94689fdc433887f9fbb480bf8a4ed ] The datasheet of ov08x40 doesn't match the hardware behavior. 0x3821[2] == 1 is the original state and 0 the horizontal flip enabled. Signed-off-by: Hao Yao Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Carbon Gen 12 & Gen 13 Reviewed-by: Stanislaw Gruszka Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f157d1cb2cdc5cf28989f9d67724288ca9e53738 Author: Nidhish A N Date: Tue Sep 9 06:21:21 2025 +0300 wifi: iwlwifi: fw: Add ASUS to PPAG and TAS list [ Upstream commit c5318e6e1c6436ce35ba521d96975e13cc5119f7 ] Add ASUS to the list of OEMs that are allowed to use the PPAG and TAS feature. Signed-off-by: Nidhish A N Reviewed-by: Pagadala Yesu Anjaneyulu Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250909061931.499af6568e89.Iafb2cb1c83ff82712c0e9d5529f76bc226ed12dd@changeid Signed-off-by: Sasha Levin commit e741dabcc52b92c48555187b2a61d197e0d947f9 Author: Marek Vasut Date: Fri Sep 5 20:42:10 2025 +0200 PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs [ Upstream commit d5f6bd3ee3f5048f272182dc91675c082773999e ] Currently, the test allocates BAR sizes according to fixed table bar_size. This does not work with controllers which have fixed size BARs that are smaller than the requested BAR size. One such controller is Renesas R-Car V4H PCIe controller, which has BAR4 size limited to 256 bytes, which is much less than one of the BAR size, 131072 currently requested by this test. A lot of controllers drivers in-tree have fixed size BARs, and they do work perfectly fine, but it is only because their fixed size is larger than the size requested by pci-epf-test.c Adjust the test such that in case a fixed size BAR is detected, the fixed BAR size is used, as that is the only possible option. This helps with test failures reported as follows: pci_epf_test pci_epf_test.0: requested BAR size is larger than fixed size pci_epf_test pci_epf_test.0: Failed to allocate space for BAR4 Signed-off-by: Marek Vasut [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20250905184240.144431-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin commit e9f66c989de4976ed29fcb32b6045bcdba07d396 Author: Xion Wang Date: Thu Sep 4 14:37:04 2025 +0800 char: Use list_del_init() in misc_deregister() to reinitialize list pointer [ Upstream commit e28022873c0d051e980c4145f1965cab5504b498 ] Currently, misc_deregister() uses list_del() to remove the device from the list. After list_del(), the list pointers are set to LIST_POISON1 and LIST_POISON2, which may help catch use-after-free bugs, but does not reset the list head. If misc_deregister() is called more than once on the same device, list_empty() will not return true, and list_del() may be called again, leading to undefined behavior. Replace list_del() with list_del_init() to reinitialize the list head after deletion. This makes the code more robust against double deregistration and allows safe usage of list_empty() on the miscdevice after deregistration. [ Note, this seems to keep broken out-of-tree drivers from doing foolish things. While this does not matter for any in-kernel drivers, external drivers could use a bit of help to show them they shouldn't be doing stuff like re-registering misc devices - gregkh ] Signed-off-by: Xion Wang Link: https://lore.kernel.org/r/20250904063714.28925-2-xion.wang@mediatek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 20d15d76605fd2680c276882a54405e8cfe09614 Author: Antonino Maniscalco Date: Thu Aug 21 15:06:34 2025 +0200 drm/msm: make sure to not queue up recovery more than once [ Upstream commit 10fb1b2fcaee5545a5e54db1ed4d7b15c2db50c8 ] If two fault IRQs arrive in short succession recovery work will be queued up twice. When recovery runs a second time it may end up killing an unrelated context. Prevent this by masking off interrupts when triggering recovery. Signed-off-by: Antonino Maniscalco Reviewed-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/670023/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit f0db721d8f3190ebba4508900dde49084d177f62 Author: Zizhi Wo Date: Thu Sep 4 10:39:55 2025 +0800 tty/vt: Add missing return value for VT_RESIZE in vt_ioctl() [ Upstream commit da7e8b3823962b13e713d4891e136a261ed8e6a2 ] In vt_ioctl(), the handler for VT_RESIZE always returns 0, which prevents users from detecting errors. Add the missing return value so that errors can be properly reported to users like vt_resizex(). Signed-off-by: Zizhi Wo Link: https://lore.kernel.org/r/20250904023955.3892120-1-wozizhi@huaweicloud.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9c52f01429c377a2d32cafc977465f37b5384f77 Author: Chen Yufeng Date: Fri Sep 5 17:48:42 2025 +0800 usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget [ Upstream commit 87c5ff5615dc0a37167e8faf3adeeddc6f1344a3 ] In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints"). Signed-off-by: Chen Yufeng Link: https://lore.kernel.org/r/20250905094842.1232-1-chenyufeng@iie.ac.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fd6820af0ac9cd197a918e07b490a654e41fc351 Author: William Wu Date: Tue Aug 26 18:28:07 2025 +0800 usb: gadget: f_hid: Fix zero length packet transfer [ Upstream commit ed6f727c575b1eb8136e744acfd5e7306c9548f6 ] Set the hid req->zero flag of ep0/in_ep to true by default, then the UDC drivers can transfer a zero length packet at the end if the hid transfer with size divisible to EPs max packet size according to the USB 2.0 spec. Signed-off-by: William Wu Link: https://lore.kernel.org/r/1756204087-26111-1-git-send-email-william.wu@rock-chips.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e014ff9ec18dd232a20d93a16f7fcc70b06daa8b Author: Vladimir Oltean Date: Wed Sep 3 16:07:26 2025 +0300 net: dsa: felix: support phy-mode = "10g-qxgmii" [ Upstream commit 6f616757dd306fce4b55131df23737732e347d8f ] The "usxgmii" phy-mode that the Felix switch ports support on LS1028A is not quite USXGMII, it is defined by the USXGMII multiport specification document as 10G-QXGMII. It uses the same signaling as USXGMII, but it multiplexes 4 ports over the link, resulting in a maximum speed of 2.5G per port. This change is needed in preparation for the lynx-10g SerDes driver on LS1028A, which will make a more clear distinction between usxgmii (supported on lane 0) and 10g-qxgmii (supported on lane 1). These protocols have their configuration in different PCCR registers (PCCRB vs PCCR9). Continue parsing and supporting single-port-per-lane USXGMII when found in the device tree as usual (because it works), but add support for 10G-QXGMII too. Using phy-mode = "10g-qxgmii" will be required when modifying the device trees to specify a "phys" phandle to the SerDes lane. The result when the "phys" phandle is present but the phy-mode is wrong is undefined. The only PHY driver in known use with this phy-mode, AQR412C, will gain logic to transition from "usxgmii" to "10g-qxgmii" in a future change. Prepare the driver by also setting PHY_INTERFACE_MODE_10G_QXGMII in supported_interfaces when PHY_INTERFACE_MODE_USXGMII is there, to prevent breakage with existing device trees. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20250903130730.2836022-3-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3cc2a33b3c79bb95f72053f7937fef7586dc787 Author: Fangzhi Zuo Date: Tue Apr 8 15:11:43 2025 -0400 drm/amd/display: Fix pbn_div Calculation Error [ Upstream commit 12cdfb61b32a7be581ec5932e0b6a482cb098204 ] [Why] dm_mst_get_pbn_divider() returns value integer coming from the cast from fixed point, but the casted integer will then be used in dfixed_const to be multiplied by 4096. The cast from fixed point to integer causes the calculation error becomes bigger when multiplied by 4096. That makes the calculated pbn_div value becomes smaller than it should be, which leads to the req_slot number becomes bigger. Such error is getting reflected in 8k30 timing, where the correct and incorrect calculated req_slot 62.9 Vs 63.1. That makes the wrong calculation failed to light up 8k30 after a dock under HBR3 x 4. [How] Restore the accuracy by keeping the fraction part calculated for the left shift operation. Reviewed-by: Aurabindo Pillai Signed-off-by: Fangzhi Zuo Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e4481e73e4ccf1082b6cb1171af21646d0a47df2 Author: Alex Deucher Date: Fri Jun 27 10:21:16 2025 -0400 drm/amdgpu: add support for cyan skillfish gpu_info [ Upstream commit fa819e3a7c1ee994ce014cc5a991c7fd91bc00f1 ] Some SOCs which are part of the cyan skillfish family rely on an explicit firmware for IP discovery. Add support for the gpu_info firmware. Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1f3eb6d464b010a9e70a9aa4bf246ce327431436 Author: Alex Deucher Date: Fri Jun 27 10:25:09 2025 -0400 drm/amdgpu: don't enable SMU on cyan skillfish [ Upstream commit 94bd7bf2c920998b4c756bc8a54fd3dbdf7e4360 ] Cyan skillfish uses different SMU firmware. Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1a15bde54e194fc975218d808ffa871e2708dc1d Author: Alex Deucher Date: Fri Jun 27 10:09:06 2025 -0400 drm/amd: add more cyan skillfish PCI ids [ Upstream commit 1e18746381793bef7c715fc5ec5611a422a75c4c ] Add additional PCI IDs to the cyan skillfish family. Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 512f9a6c1531e069f70073aa09704539c70eb6e0 Author: Hector Martin Date: Tue Aug 26 12:57:18 2025 +0200 iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs [ Upstream commit ecf6508923f87e4597228f70cc838af3d37f6662 ] These registers exist and at least on the t602x variant the IRQ only clears when theses are cleared. Signed-off-by: Hector Martin Signed-off-by: Janne Grunau Reviewed-by: Sven Peter Reviewed-by: Neal Gompa Link: https://lore.kernel.org/r/20250826-dart-t8110-stream-error-v1-1-e33395112014@jannau.net Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 1eefe9a9ceb63f9bfc6bb58b4a450f600ee5b3ea Author: Ashish Kalra Date: Mon Aug 25 21:46:38 2025 +0000 crypto: ccp: Skip SEV and SNP INIT for kdump boot [ Upstream commit 8c571019d8a817b701888926529a5d7a826b947b ] Since SEV or SNP may already be initialized in the previous kernel, attempting to initialize them again in the kdump kernel can result in SNP initialization failures, which in turn lead to IOMMU initialization failures. Moreover, SNP/SEV guests are not run under a kdump kernel, so there is no need to initialize SEV or SNP during kdump boot. Skip SNP and SEV INIT if doing kdump boot. Tested-by: Sairaj Kodilkar Signed-off-by: Ashish Kalra Link: https://lore.kernel.org/r/d884eff5f6180d8b8c6698a6168988118cf9cba1.1756157913.git.ashish.kalra@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 3344716ddee01d7caa35b470d30fd87781c661b1 Author: Ashish Kalra Date: Mon Aug 25 21:46:53 2025 +0000 iommu/amd: Skip enabling command/event buffers for kdump [ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ] After a panic if SNP is enabled in the previous kernel then the kdump kernel boots with IOMMU SNP enforcement still enabled. IOMMU command buffers and event buffer registers remain locked and exclusive to the previous kernel. Attempts to enable command and event buffers in the kdump kernel will fail, as hardware ignores writes to the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1. Skip enabling command buffers and event buffers for kdump boot as they are already enabled in the previous kernel. Reviewed-by: Vasant Hegde Tested-by: Sairaj Kodilkar Signed-off-by: Ashish Kalra Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 8cd230920bdf2a7622cc855f10b7e459605c3054 Author: Colin Foster Date: Wed Sep 3 08:26:10 2025 -0500 smsc911x: add second read of EEPROM mac when possible corruption seen [ Upstream commit 69777753a8919b0b8313c856e707e1d1fe5ced85 ] When the EEPROM MAC is read by way of ADDRH, it can return all 0s the first time. Subsequent reads succeed. This is fully reproduceable on the Phytec PCM049 SOM. Re-read the ADDRH when this behaviour is observed, in an attempt to correctly apply the EEPROM MAC address. Signed-off-by: Colin Foster Link: https://patch.msgid.link/20250903132610.966787-1-colin.foster@in-advantage.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 562bcdc0d776f25e136be4133c6e79577405ca76 Author: Eric Dumazet Date: Wed Sep 3 17:48:10 2025 +0000 net: call cond_resched() less often in __release_sock() [ Upstream commit 16c610162d1f1c332209de1c91ffb09b659bb65d ] While stress testing TCP I had unexpected retransmits and sack packets when a single cpu receives data from multiple high-throughput flows. super_netperf 4 -H srv -T,10 -l 3000 & Tcpdump extract: 00:00:00.000007 IP6 clnt > srv: Flags [.], seq 26062848:26124288, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26124288:26185728, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26185728:26243072, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26243072:26304512, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26304512:26365952, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440 00:00:00.000007 IP6 clnt > srv: Flags [P.], seq 26365952:26423296, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 57344 00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26423296:26484736, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26484736:26546176, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440 00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26546176:26603520, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 57344 00:00:00.003932 IP6 clnt > srv: Flags [P.], seq 26603520:26619904, ack 1, win 66, options [nop,nop,TS val 651464844 ecr 3100753141], length 16384 00:00:00.006602 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651471419 ecr 3100759716], length 4096 00:00:00.013000 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651484421 ecr 3100772718], length 4096 00:00:00.000416 IP6 srv > clnt: Flags [.], ack 26619904, win 1393, options [nop,nop,TS val 3100773185 ecr 651484421,nop,nop,sack 1 {24862720:24866816}], length 0 After analysis, it appears this is because of the cond_resched() call from __release_sock(). When current thread is yielding, while still holding the TCP socket lock, it might regain the cpu after a very long time. Other peer TLP/RTO is firing (multiple times) and packets are retransmit, while the initial copy is waiting in the socket backlog or receive queue. In this patch, I call cond_resched() only once every 16 packets. Modern TCP stack now spends less time per packet in the backlog, especially because ACK are no longer sent (commit 133c4c0d3717 "tcp: defer regular ACK while processing socket backlog") Before: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19046186 0.0 TcpRetransSegs 1471 0.0 TcpExtTCPTimeouts 1397 0.0 TcpExtTCPLossProbes 1356 0.0 TcpExtTCPDSACKRecv 1352 0.0 TcpExtTCPSpuriousRTOs 114 0.0 TcpExtTCPDSACKRecvSegs 1352 0.0 After: clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK" TcpOutSegs 19218936 0.0 Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250903174811.1930820-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8831d3a5d896e03b3be3eb3d0717ae14439f32f8 Author: Michal Wajdeczko Date: Thu Sep 4 00:33:30 2025 +0200 drm/xe/guc: Set upper limit of H2G retries over CTB [ Upstream commit 2506af5f8109a387a5e8e9e3d7c498480b8033db ] The GuC communication protocol allows GuC to send NO_RESPONSE_RETRY reply message to indicate that due to some interim condition it can not handle incoming H2G request and the host shall resend it. But in some cases, due to errors, this unsatisfied condition might be final and this could lead to endless retries as it was recently seen on the CI: [drm] GT0: PF: VF1 FLR didn't finish in 5000 ms (-ETIMEDOUT) [drm] GT0: PF: VF1 resource sanitizing failed (-ETIMEDOUT) [drm] GT0: PF: VF1 FLR failed! [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0 [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0 [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0 [drm:guc_ct_send_recv [xe]] GT0: H2G action 0x5503 retrying: reason 0x0 To avoid such dangerous loops allow only limited number of retries (for now 50) and add some delays (n * 5ms) to slow down the rate of resending this repeated request. Signed-off-by: Michal Wajdeczko Cc: John Harrison Cc: Matthew Brost Reviewed-by: Stuart Summers Reviewed-by: Julia Filipchuk Link: https://lore.kernel.org/r/20250903223330.6408-1-michal.wajdeczko@intel.com Signed-off-by: Sasha Levin commit 598e9fc58aa97e359b9a341f7dfb9a2abd2c075e Author: Richard Zhu Date: Wed Aug 20 10:23:28 2025 +0800 PCI: imx6: Enable the Vaux supply if available [ Upstream commit c221cbf8dc547eb8489152ac62ef103fede99545 ] When the 3.3Vaux supply is present, fetch it at the probe time and keep it enabled for the entire PCIe controller lifecycle so that the link can enter L2 state and the devices can signal wakeup using either Beacon or WAKE# mechanisms. Signed-off-by: Richard Zhu [mani: reworded the subject, description and error message] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20250820022328.2143374-1-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 73cd60aaba743c4c2015f301c1717e10331220a4 Author: Cryolitia PukNgae Date: Wed Sep 3 13:09:48 2025 +0800 ALSA: usb-audio: apply quirk for MOONDROP Quark2 [ Upstream commit a73349c5dd27bc544b048e2e2c8ef6394f05b793 ] It reports a MIN value -15360 for volume control, but will mute when setting it less than -14208 Tested-by: Guoli An Signed-off-by: Cryolitia PukNgae Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250903-sound-v1-4-d4ca777b8512@uniontech.com Signed-off-by: Sasha Levin commit c9df78e84e85c681f0fcc0945a0da1500da3864b Author: Ramya Gnanasekar Date: Fri Jun 6 16:14:36 2025 +0530 wifi: mac80211: Fix 6 GHz Band capabilities element advertisement in lower bands [ Upstream commit e53f8b12a21c2974b66fa8c706090182da06fff3 ] Currently, when adding the 6 GHz Band Capabilities element, the channel list of the wiphy is checked to determine if 6 GHz is supported for a given virtual interface. However, in a multi-radio wiphy (e.g., one that has both lower bands and 6 GHz combined), the wiphy advertises support for all bands. As a result, the 6 GHz Band Capabilities element is incorrectly included in mesh beacon and station's association request frames of interfaces operating in lower bands, without verifying whether the interface is actually operating in a 6 GHz channel. Fix this by verifying if the interface operates on 6 GHz channel before adding the element. Note that this check cannot be placed directly in ieee80211_put_he_6ghz_cap() as the same function is used to add probe request elements while initiating scan in which case the interface may not be operating in any band's channel. Signed-off-by: Ramya Gnanasekar Signed-off-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20250606104436.326654-1-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f013e6aadd6d8efb253f9bc162c19272916768cd Author: Paul Kocialkowski Date: Thu Aug 28 15:49:18 2025 +0200 media: verisilicon: Explicitly disable selection api ioctls for decoders [ Upstream commit 73d50aa92f28ee8414fbfde011974fce970b82cc ] Call the dedicated v4l2_disable_ioctl helper instead of manually checking whether the current context is an encoder for the selection api ioctls. Signed-off-by: Paul Kocialkowski Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f6405d5ea261fe355faac3065cf980cd817d07ce Author: Niklas Söderlund Date: Thu Aug 28 18:06:54 2025 +0200 media: adv7180: Only validate format in querystd [ Upstream commit 91c5d7c849273d14bc4bae1b92666bdb5409294a ] The .querystd callback should not program the device with the detected standard, it should only report the standard to user-space. User-space may then use .s_std to set the standard, if it wants to use it. All that is required of .querystd is to setup the auto detection of standards and report its findings. While at it add some documentation on why this can't happen while streaming and improve the error handling using a scoped guard. Signed-off-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 115a068cd28ccb2441aa673dd9514356fd7241ad Author: Niklas Söderlund Date: Thu Aug 28 18:06:52 2025 +0200 media: adv7180: Do not write format to device in set_fmt [ Upstream commit 46c1e7814d1c3310ef23c01ed1a582ef0c8ab1d2 ] The .set_fmt callback should not write the new format directly do the device, it should only store it and have it applied by .s_stream. The .s_stream callback already calls adv7180_set_field_mode() so it's safe to remove programming of the device and just store the format and have .s_stream apply it. Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5f9e09f28609b38997a7f9abdac21b234be3a2ff Author: Niklas Söderlund Date: Thu Aug 28 18:06:45 2025 +0200 media: adv7180: Add missing lock in suspend callback [ Upstream commit 878c496ac5080f94a93a9216a8f70cfd67ace8c9 ] The adv7180_set_power() utilizes adv7180_write() which in turn requires the state mutex to be held, take it before calling adv7180_set_power() to avoid tripping a lockdep_assert_held(). Signed-off-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e01a42c5a1855d912da644160f58591f52ff52dd Author: Juraj Šarinay Date: Tue Sep 2 13:36:28 2025 +0200 net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms [ Upstream commit 21f82062d0f241e55dd59eb630e8710862cc90b4 ] An exchange with a NFC target must complete within NCI_DATA_TIMEOUT. A delay of 700 ms is not sufficient for cryptographic operations on smart cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH or 3072-bit RSA. To prevent brute-force attacks, passports and similar documents introduce even longer delays into access control protocols (BAC/PACE). The timeout should be higher, but not too much. The expiration allows us to detect that a NFC target has disappeared. Signed-off-by: Juraj Šarinay Reviewed-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20250902113630.62393-1-juraj@sarinay.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1da1cfa9c2b55c9f771fa7c0aef1c071f5c21a92 Author: Antheas Kapenekakis Date: Fri Aug 29 16:55:36 2025 +0200 drm: panel-backlight-quirks: Make EDID match optional [ Upstream commit 9931e4be11f2129a20ffd908bc364598a63016f8 ] Currently, having a valid panel_id match is required to use the quirk system. For certain devices, we know that all SKUs need a certain quirk. Therefore, allow not specifying ident by only checking for a match if panel_id is non-zero. Tested-by: Philip Müller Reviewed-by: Mario Limonciello Signed-off-by: Antheas Kapenekakis Link: https://lore.kernel.org/r/20250829145541.512671-2-lkml@antheas.dev Acked-by: Alex Deucher Signed-off-by: Mario Limonciello (AMD) Signed-off-by: Sasha Levin commit 885c69a343101cce6f501f9da7ed8a491d68e2da Author: Chia-I Wu Date: Thu Aug 28 13:01:16 2025 -0700 drm/panthor: check bo offset alignment in vm bind [ Upstream commit 5afa9d2a9bb1410f816e0123846047288b16e4b9 ] Fail early from panthor_vm_bind_prepare_op_ctx instead of late from ops->map_pages. Signed-off-by: Chia-I Wu Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://lore.kernel.org/r/20250828200116.3532255-1-olvaffe@gmail.com Signed-off-by: Sasha Levin commit 483303d94c2d4452a5eac12ed97263c5c486ac5a Author: Yue Haibing Date: Mon Sep 1 20:37:26 2025 +0800 ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled [ Upstream commit 3d95261eeb74958cd496e1875684827dc5d028cc ] In ipv6_rpl_srh_rcv() we use min(net->ipv6.devconf_all->rpl_seg_enabled, idev->cnf.rpl_seg_enabled) is intended to return 0 when either value is zero, but if one of the values is negative it will in fact return non-zero. Signed-off-by: Yue Haibing Link: https://patch.msgid.link/20250901123726.1972881-3-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 356f6a277f05f1339d1d0c403b6df19f92c5f5f1 Author: Jakub Kicinski Date: Mon Sep 1 10:31:39 2025 -0700 selftests: drv-net: rss_ctx: make the test pass with few queues [ Upstream commit e2cf2d5baa09248d3d50b73522594b778388e3bc ] rss_ctx.test_rss_key_indir implicitly expects at least 5 queues, as it checks that the traffic on first 2 queues is lower than the remaining queues when we use all queues. Special case fewer queues. Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250901173139.881070-2-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a988c672b668a9e1be104e77c1c5e9804afe2c6 Author: Zhanjun Dong Date: Fri Aug 29 12:04:27 2025 -0400 drm/xe/guc: Increase GuC crash dump buffer size [ Upstream commit ad83b1da5b786ee2d245e41ce55cb1c71fed7c22 ] There are platforms already have a maximum dump size of 12KB, to avoid data truncating, increase GuC crash dump buffer size to 16KB. Signed-off-by: Zhanjun Dong Reviewed-by: Stuart Summers Signed-off-by: John Harrison Link: https://lore.kernel.org/r/20250829160427.1245732-1-zhanjun.dong@intel.com Signed-off-by: Sasha Levin commit 6238fab18c1c61c4c8c9dc41075315a1ce53deb8 Author: David Francis Date: Wed Feb 19 10:01:32 2025 -0500 drm/amdgpu: Allow kfd CRIU with no buffer objects [ Upstream commit 85705b18ae7674347f8675f64b2b3115fb1d5629 ] The kfd CRIU checkpoint ioctl would return an error if trying to checkpoint a process with no kfd buffer objects. This is a normal case and should not be an error. Reviewed-by: Felix Kuehling Signed-off-by: David Francis Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ddd8742737669de8510e412fdd06a6e7952dff4c Author: Krzysztof Kozlowski Date: Tue Jun 10 16:05:47 2025 +0200 drm/msm/dsi/phy_7nm: Fix missing initial VCO rate [ Upstream commit 5ddcb0cb9d10e6e70a68e0cb8f0b8e3a7eb8ccaf ] Driver unconditionally saves current state on first init in dsi_pll_7nm_init(), but does not save the VCO rate, only some of the divider registers. The state is then restored during probe/enable via msm_dsi_phy_enable() -> msm_dsi_phy_pll_restore_state() -> dsi_7nm_pll_restore_state(). Restoring calls dsi_pll_7nm_vco_set_rate() with pll_7nm->vco_current_rate=0, which basically overwrites existing rate of VCO and messes with clock hierarchy, by setting frequency to 0 to clock tree. This makes anyway little sense - VCO rate was not saved, so should not be restored. If PLL was not configured configure it to minimum rate to avoid glitches and configuring entire in clock hierarchy to 0 Hz. Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Patchwork: https://patchwork.freedesktop.org/patch/657827/ Link: https://lore.kernel.org/r/20250610-b4-sm8750-display-v6-9-ee633e3ddbff@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e8b63d342d4344d808df48947a486ce13c3b6e2f Author: Krzysztof Kozlowski Date: Tue Jun 10 16:05:44 2025 +0200 drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL [ Upstream commit b63f008f395ca5f6bc89123db97440bdc19981c4 ] According to Hardware Programming Guide for DSI PHY, the retime buffer resync should be done after PLL clock users (byte_clk and intf_byte_clk) are enabled. Downstream also does it as part of configuring the PLL. Driver was only turning off the resync FIFO buffer, but never bringing it on again. Reviewed-by: Dmitry Baryshkov Signed-off-by: Krzysztof Kozlowski Patchwork: https://patchwork.freedesktop.org/patch/657823/ Link: https://lore.kernel.org/r/20250610-b4-sm8750-display-v6-6-ee633e3ddbff@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 2c55ec15062e1da87a006ec54dc83c22f4af4642 Author: Devendra K Verma Date: Thu Aug 21 17:45:05 2025 +0530 dmaengine: dw-edma: Set status for callback_result [ Upstream commit 5e742de97c806a4048418237ef1283e7d71eaf4b ] DMA Engine has support for the callback_result which provides the status of the request and the residue. This helps in determining the correct status of the request and in efficient resource management of the request. The 'callback_result' method is preferred over the deprecated 'callback' method. Signed-off-by: Devendra K Verma Link: https://lore.kernel.org/r/20250821121505.318179-1-devverma@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4cd966067226e594240719494a32d13cab07fcf4 Author: Rosen Penev Date: Thu Aug 21 15:09:42 2025 -0700 dmaengine: mv_xor: match alloc_wc and free_wc [ Upstream commit a33e3b667d2f004fdfae6b442bd4676f6c510abb ] dma_alloc_wc is used but not dma_free_wc. Signed-off-by: Rosen Penev Link: https://lore.kernel.org/r/20250821220942.10578-1-rosenp@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0f0d31760811d0e68e0d7a340e8ab47ca8bc700a Author: Thomas Andreatta Date: Wed Aug 27 17:24:43 2025 +0200 dmaengine: sh: setup_xref error handling [ Upstream commit d9a3e9929452780df16f3414f0d59b5f69d058cf ] This patch modifies the type of setup_xref from void to int and handles errors since the function can fail. `setup_xref` now returns the (eventual) error from `dmae_set_dmars`|`dmae_set_chcr`, while `shdma_tx_submit` handles the result, removing the chunks from the queue and marking PM as idle in case of an error. Signed-off-by: Thomas Andreatta Link: https://lore.kernel.org/r/20250827152442.90962-1-thomas.andreatta2000@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3b66c3689fde9ee9e4757aa5b70e6b174e625f78 Author: Miroslav Lichvar Date: Thu Aug 28 12:32:53 2025 +0200 ptp: Limit time setting of PTP clocks [ Upstream commit 5a8c02a6bf52b1cf9cfb7868a8330f7c3c6aebe9 ] Networking drivers implementing PTP clocks and kernel socket code handling hardware timestamps use the 64-bit signed ktime_t type counting nanoseconds. When a PTP clock reaches the maximum value in year 2262, the timestamps returned to applications will overflow into year 1667. The same thing happens when injecting a large offset with clock_adjtime(ADJ_SETOFFSET). The commit 7a8e61f84786 ("timekeeping: Force upper bound for setting CLOCK_REALTIME") limited the maximum accepted value setting the system clock to 30 years before the maximum representable value (i.e. year 2232) to avoid the overflow, assuming the system will not run for more than 30 years. Enforce the same limit for PTP clocks. Don't allow negative values and values closer than 30 years to the maximum value. Drivers may implement an even lower limit if the hardware registers cannot represent the whole interval between years 1970 and 2262 in the required resolution. Signed-off-by: Miroslav Lichvar Cc: Richard Cochran Cc: Thomas Gleixner Cc: John Stultz Cc: Arnd Bergmann Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20250828103300.1387025-1-mlichvar@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 65d52148298b57df37ef4738ecbdba5c007017d3 Author: Bharat Uppal Date: Thu Aug 21 11:09:23 2025 +0530 scsi: ufs: exynos: fsd: Gate ref_clk and put UFS device in reset on suspend [ Upstream commit 6d55af0f0740bf3d77943425fdafb77dc0fa6bb9 ] On FSD platform, gating the reference clock (ref_clk) and putting the UFS device in reset by asserting the reset signal during UFS suspend, improves the power savings and ensures the PHY is fully turned off. These operations are added as FSD specific suspend hook to avoid unintended side effects on other SoCs supported by this driver. Co-developed-by: Nimesh Sati Signed-off-by: Nimesh Sati Signed-off-by: Bharat Uppal Link: https://lore.kernel.org/r/20250821053923.69411-1-bharat.uppal@samsung.com Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5838b11e668015c6733976787b00f75496ac9467 Author: Qianfeng Rong Date: Tue Aug 26 17:32:42 2025 +0800 scsi: pm8001: Use int instead of u32 to store error codes [ Upstream commit bee3554d1a4efbce91d6eca732f41b97272213a5 ] Use int instead of u32 for 'ret' variable to store negative error codes returned by PM8001_CHIP_DISP->set_nvmd_req(). Signed-off-by: Qianfeng Rong Link: https://lore.kernel.org/r/20250826093242.230344-1-rongqianfeng@vivo.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2ced7045c93197339ea3cc3f365caf178924b418 Author: Qianfeng Rong Date: Thu Aug 21 22:20:26 2025 +0800 crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof() [ Upstream commit 4c634b6b3c77bba237ee64bca172e73f9cee0cb2 ] As noted in the kernel documentation [1], open-coded multiplication in allocator arguments is discouraged because it can lead to integer overflow. Use kcalloc() to gain built-in overflow protection, making memory allocation safer when calculating allocation size compared to explicit multiplication. Similarly, use size_add() instead of explicit addition for 'uobj_chunk_num + sobj_chunk_num'. Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments #1 Signed-off-by: Qianfeng Rong Reviewed-by: Andy Shevchenko Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bc2b881a0896c111c1041d8bb1f92a3b3873ace5 Author: Eric Dumazet Date: Thu Aug 28 19:58:22 2025 +0000 tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check() [ Upstream commit b62a59c18b692f892dcb8109c1c2e653b2abc95c ] Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250828195823.3958522-8-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 047c08808c22db39ebb44fc50908089756f45ad9 Author: Parthiban Veerasooran Date: Thu Aug 28 17:15:49 2025 +0530 microchip: lan865x: add ndo_eth_ioctl handler to enable PHY ioctl support [ Upstream commit 34c21e91192aa1ff66f9d6cef8132717840d04e6 ] Introduce support for standard MII ioctl operations in the LAN865x Ethernet driver by implementing the .ndo_eth_ioctl callback. This allows PHY-related ioctl commands to be handled via phy_do_ioctl_running() and enables support for ethtool and other user-space tools that rely on ioctl interface to perform PHY register access using commands like SIOCGMIIREG and SIOCSMIIREG. This feature enables improved diagnostics and PHY configuration capabilities from userspace. Signed-off-by: Parthiban Veerasooran Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20250828114549.46116-1-parthiban.veerasooran@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 296357dcdc4b5860210857e15460c97dae69987c Author: Eric Dumazet Date: Thu Aug 28 10:27:36 2025 +0000 inet_diag: annotate data-races in inet_diag_bc_sk() [ Upstream commit 4fd84a0aaf2ba125b441aa09d415022385e66bf2 ] inet_diag_bc_sk() runs with an unlocked socket, annotate potential races with READ_ONCE(). Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20250828102738.2065992-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 62d07edc3408ab1ce87fb95615bfd0da7ccb8359 Author: Aleksander Jan Bajkowski Date: Fri Aug 15 14:12:24 2025 +0200 mips: lantiq: danube: rename stp node on EASY50712 reference board [ Upstream commit 2b9706ce84be9cb26be03e1ad2e43ec8bc3986be ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: stp@e100bb0 (lantiq,gpio-stp-xway): $nodename:0: 'stp@e100bb0' does not match '^gpio@[0-9a-f]+$' from schema $id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit b3b2bcb198cc3cf2cbb7886f74544d924ea8bf7d Author: Aleksander Jan Bajkowski Date: Fri Aug 15 14:12:23 2025 +0200 mips: lantiq: xway: sysctrl: rename stp clock [ Upstream commit b0d04fe6a633ada2c7bc1b5ddd011cbd85961868 ] Bindig requires a node name matching ‘^gpio@[0-9a-f]+$’. This patch changes the clock name from “stp” to “gpio”. Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 00f2c5bb59b10810bf1e551106932a52a55f7e3e Author: Aleksander Jan Bajkowski Date: Mon Aug 11 15:34:13 2025 +0200 mips: lantiq: danube: add missing device_type in pci node [ Upstream commit d66949a1875352d2ddd52b144333288952a9e36f ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: pci@e105400 (lantiq,pci-xway): 'device_type' is a required property from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e91be5cb71eec601f5c085b96331af4e4a6e871b Author: Aleksander Jan Bajkowski Date: Tue Aug 12 16:06:04 2025 +0200 mips: lantiq: danube: add model to EASY50712 dts [ Upstream commit cb96fd880ef78500b34d10fa76ddd3fa070287d6 ] This fixes the following warning: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: / (lantiq,xway): 'model' is a required property from schema $id: http://devicetree.org/schemas/root-node.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 77439a0d125e2a9c24cec96a1f92e46ec9331dca Author: Aleksander Jan Bajkowski Date: Mon Aug 11 13:58:15 2025 +0200 mips: lantiq: danube: add missing properties to cpu node [ Upstream commit e8dee66c37085dc9858eb8608bc783c2900e50e7 ] This fixes the following warnings: arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/cpus.yaml# arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpu@0 (mips,mips24Kc): 'reg' is a required property from schema $id: http://devicetree.org/schemas/mips/cpus.yaml# Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e14605b6035e9c50ed8e80bead2af3cda993bbc1 Author: Timur Kristóf Date: Thu Aug 28 16:50:36 2025 +0200 drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2) [ Upstream commit 585b2f685c56c5095cc22c7202bf74d8e9a73cdd ] Update the legacy (non-DC) display code to respect the maximum pixel clock for HDMI and DVI-D. Reject modes that would require a higher pixel clock than can be supported. Also update the maximum supported HDMI clock value depending on the ASIC type. For reference, see the DC code: check max_hdmi_pixel_clock in dce*_resource.c v2: Fix maximum clocks for DVI-D and DVI/HDMI adapters. Reviewed-by: Alex Deucher Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fd1052e860b43f1a558342d57b34dee224709381 Author: Mangesh Gadre Date: Mon Aug 25 21:22:30 2025 +0800 drm/amdgpu: Avoid vcn v5.0.1 poison irq call trace on sriov guest [ Upstream commit 37551277dfed796b6749e4fa52bdb62403cfdb42 ] Sriov guest side doesn't init ras feature hence the poison irq shouldn't be put during hw fini Signed-off-by: Mangesh Gadre Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 353c6373d8d9fcaff903ba605af30990cead2271 Author: Clay King Date: Wed Aug 20 15:04:29 2025 -0400 drm/amd/display: incorrect conditions for failing dto calculations [ Upstream commit 306cbcc6f687d791ab3cc8fbbe30f5286fd0d1e5 ] [Why & How] Previously, when calculating dto phase, we would incorrectly fail when phase <=0 without additionally checking for the integer value. This meant that calculations would incorrectly fail when the desired pixel clock was an exact multiple of the reference clock. Reviewed-by: Dillon Varone Signed-off-by: Clay King Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cc84d7a6ba01294050173ea0a8f27e71f545e4c1 Author: Relja Vojvodic Date: Thu Aug 14 11:33:22 2025 -0400 drm/amd/display: Increase minimum clock for TMDS 420 with pipe splitting [ Upstream commit 002a612023c8b105bd3829d81862dee04368d6de ] [Why] -Pipe splitting allows for clocks to be reduced, but when using TMDS 420, reduced clocks lead to missed clocks cycles on clock resyncing [How] -Impose a minimum clock when using TMDS 420 Reviewed-by: Chris Park Signed-off-by: Relja Vojvodic Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e5fd6965f6b557cf35bfd333a99c06fc272667d9 Author: Peter Ujfalusi Date: Fri Aug 29 13:53:03 2025 +0300 ASoC: SOF: ipc4-pcm: Add fixup for channels [ Upstream commit 6ad299a9b968e1c63988e2a327295e522cf6bbf5 ] We can have modules in path which can change the number of channels and in this case the BE params needs to be adjusted to configure the DAI according to the copier configuration. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Message-ID: <20250829105305.31818-2-peter.ujfalusi@linux.intel.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc7bb1a0dd2571141bf1effcf4034ee48bff1a11 Author: Martin Tůma Date: Tue Aug 26 18:28:29 2025 +0200 media: pci: mgb4: Fix timings comparison in VIDIOC_S_DV_TIMINGS [ Upstream commit 0750649b528ff18d1d68aecb45b34ec22d5ab778 ] Compare the whole v4l2_bt_timings struct, not just the width/height when setting new timings. Timings with the same resolution and different pixelclock can now be properly set. Signed-off-by: Martin Tůma Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d17dc9b16a1a6e23942e276f06df41f990658777 Author: Chelsy Ratnawat Date: Wed Aug 6 23:09:36 2025 -0700 media: fix uninitialized symbol warnings [ Upstream commit b4c441310c3baaa7c39a5457e305ca93c7a0400d ] Initialize variables to fix these smatch warnings drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'protocol'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'scancode'. drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized symbol 'toggle'. drivers/media/tuners/xc4000.c:1102 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc4000.c:1108 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc4000.c:1123 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc4000.c:1127 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:645 xc_debug_dump() error: uninitialized symbol 'adc_envelope'. drivers/media/tuners/xc5000.c:651 xc_debug_dump() error: uninitialized symbol 'lock_status'. drivers/media/tuners/xc5000.c:665 xc_debug_dump() error: uninitialized symbol 'frame_lines'. drivers/media/tuners/xc5000.c:668 xc_debug_dump() error: uninitialized symbol 'quality'. drivers/media/tuners/xc5000.c:671 xc_debug_dump() error: uninitialized symbol 'snr'. drivers/media/tuners/xc5000.c:674 xc_debug_dump() error: uninitialized symbol 'totalgain'. Signed-off-by: Chelsy Ratnawat Signed-off-by: Hans Verkuil [hverkuil: dropped ' = 0' from rc in ir-kbd-i2c.c, not needed] Signed-off-by: Sasha Levin commit 20b979de3fdc2eccaac4d754ea50efa124fe143b Author: Jakub Kicinski Date: Wed Aug 27 10:35:58 2025 -0700 selftests: drv-net: rss_ctx: fix the queue count check [ Upstream commit c158b5a570a188b990ef10ded172b8b93e737826 ] Commit 0d6ccfe6b319 ("selftests: drv-net: rss_ctx: check for all-zero keys") added a skip exception if NIC has fewer than 3 queues enabled, but it's just constructing the object, it's not actually rising this exception. Before: # Exception| net.lib.py.utils.CmdExitFailure: Command failed: ethtool -X enp1s0 equal 3 hkey d1:cc:77:47:9d:ea:15:f2:b9:6c:ef:68:62:c0:45:d5:b0:99:7d:cf:29:53:40:06:3d:8e:b9:bc:d4:70:89:b8:8d:59:04:ea:a9:c2:21:b3:55:b8:ab:6b:d9:48:b4:bd:4c:ff:a5:f0:a8:c2 not ok 1 rss_ctx.test_rss_key_indir After: ok 1 rss_ctx.test_rss_key_indir # SKIP Device has fewer than 3 queues (or doesn't support queue stats) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250827173558.3259072-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2f95f8cbc5df6082acb0a74da14595253f4d1380 Author: Srinivas Pandruvada Date: Tue Aug 19 14:10:34 2025 -0700 platform/x86/intel-uncore-freq: Fix warning in partitioned system [ Upstream commit 6d47b4f08436cb682fb2644e6265a3897fd42a77 ] A partitioned system configured with only one package and one compute die, warning will be generated for duplicate sysfs entry. This typically occurs during the platform bring-up phase. Partitioned systems expose dies, equivalent to TPMI compute domains, through the CPUID. Each partitioned system must contains at least one compute die per partition, resulting in a minimum of two dies per package. Hence the function topology_max_dies_per_package() returns at least two, and the condition "topology_max_dies_per_package() > 1" prevents the creation of a root domain. In this case topology_max_dies_per_package() will return 1 and root domain will be created for partition 0 and a duplicate sysfs warning for partition 1 as both partitions have same package ID. To address this also check for non zero partition in addition to topology_max_dies_per_package() > 1. Signed-off-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20250819211034.3776284-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 79670b12a4161e24468a2054501dac4eebbf01eb Author: Amber Lin Date: Fri Aug 15 14:04:15 2025 -0400 drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption [ Upstream commit f3820e9d356132e18405cd7606e22dc87ccfa6d1 ] When KFD asks CP to preempt queues, other than preempt CP queues, CP also requests SDMA to preempt SDMA queues with UNMAP_LATENCY timeout. Currently queue_preemption_timeout_ms is 9000 ms by default but can be configured via module parameter. KFD_UNMAP_LATENCY_MS is hard coded as 4000 ms though. This patch ties KFD_UNMAP_LATENCY_MS to queue_preemption_timeout_ms so in a slow system such as emulator, both CP and SDMA slowness are taken into account. Signed-off-by: Amber Lin Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3cc92e9bffa7ce2a68aac7e7d2bd2955a9d0499b Author: Ivan Lipski Date: Thu Aug 7 09:45:26 2025 -0400 drm/amd/display: Support HW cursor 180 rot for any number of pipe splits [ Upstream commit 8a359f0f138d5ac7ceffd21b73279be50e516c0a ] [Why] For the HW cursor, its current position in the pipe_ctx->stream struct is not affected by the 180 rotation, i. e. the top left corner is still at 0,0. However, the DPP & HUBP set_cursor_position functions require rotated position. The current approach is hard-coded for ODM 2:1, thus it's failing for ODM 4:1, resulting in a double cursor. [How] Instead of calculating the new cursor position relatively to the viewports, we calculate it using a viewavable clip_rect of each plane. The clip_rects are first offset and scaled to the same space as the src_rect, i. e. Stream space -> Plane space. In case of a pipe split, which divides the plane into 2 or more viewports, the clip_rect is the union of all the viewports of the given plane. With the assumption that the viewports in HUBP's set_cursor_position are in the Plane space as well, it should produce a correct cursor position for any number of pipe splits. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Ivan Lipski Signed-off-by: Leo Li Signed-off-by: Aurabindo Pillai Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 01ffa1ba69d9bb57a719a0909dba4eab650655e6 Author: Eric Huang Date: Mon Aug 18 14:22:53 2025 -0400 drm/amdkfd: fix vram allocation failure for a special case [ Upstream commit 93aa919ca05bec544b17ee9a1bfe394ce6c94bd8 ] When it only allocates vram without va, which is 0, and a SVM range allocated stays in this range, the vram allocation returns failure. It should be skipped for this case from SVM usage check. Signed-off-by: Eric Huang Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d367caca4a64a2dfde3ba374f5335b153d7408f4 Author: Ce Sun Date: Thu Aug 7 12:36:05 2025 +0800 drm/amdgpu: Correct the counts of nr_banks and nr_errors [ Upstream commit 907813e5d7cadfeafab12467d748705a5309efb0 ] Correct the counts of nr_banks and nr_errors Signed-off-by: Ce Sun Reviewed-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit deee089a226f84bd1ede4a38f04b6bca7b458808 Author: Miklos Szeredi Date: Tue Aug 19 16:44:02 2025 +0200 fuse: zero initialize inode private data [ Upstream commit 3ca1b311181072415b6432a169de765ac2034e5a ] This is slightly tricky, since the VFS uses non-zeroing allocation to preserve some fields that are left in a consistent state. Reported-by: Chunsheng Luo Closes: https://lore.kernel.org/all/20250818083224.229-1-luochunsheng@ustc.edu/ Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit c57da33f6316e9af4aea50788573747935b2549b Author: Heiner Kallweit Date: Sat Aug 23 23:25:05 2025 +0200 net: phy: fixed_phy: let fixed_phy_unregister free the phy_device [ Upstream commit a0f849c1cc6df0db9083b4c81c05a5456b1ed0fb ] fixed_phy_register() creates and registers the phy_device. To be symmetric, we should not only unregister, but also free the phy_device in fixed_phy_unregister(). This allows to simplify code in users. Note wrt of_phy_deregister_fixed_link(): put_device(&phydev->mdio.dev) and phy_device_free(phydev) are identical. Signed-off-by: Heiner Kallweit Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/ad8dda9a-10ed-4060-916b-3f13bdbb899d@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 67a9a278c96f465e7a190cd1559eaf4694367c6b Author: Andrew Davis Date: Thu Aug 14 10:39:37 2025 -0500 remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper [ Upstream commit 461edcf73eec57bc0006fbb5209f5012c514c58b ] Use device life-cycle managed runtime enable function to simplify probe and exit paths. Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20250814153940.670564-1-afd@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 8c30f5534b09779ac3cb8d369dbea99b2a37774c Author: Krzysztof Kozlowski Date: Thu May 1 16:33:21 2025 +0200 extcon: adc-jack: Fix wakeup source leaks on device unbind [ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ] Device can be unbound, so driver must also release memory for the wakeup source. Do not use devm interface, because it would change the order of cleanup. Link: https://lore.kernel.org/lkml/20250501-device-wakeup-leak-extcon-v2-1-7af77802cbea@linaro.org/ Acked-by: MyungJoo Ham Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit ad1c6577a0d3ce5fe8d87fdeb2fab7361cfcc676 Author: Francisco Gutierrez Date: Wed Jul 23 18:35:43 2025 +0000 scsi: pm80xx: Fix race condition caused by static variables [ Upstream commit d6477ee38ccfbeaed885733c13f41d9076e2f94a ] Eliminate the use of static variables within the log pull implementation to resolve a race condition and prevent data gaps when pulling logs from multiple controllers in parallel, ensuring each operation is properly isolated. Signed-off-by: Francisco Gutierrez Link: https://lore.kernel.org/r/20250723183543.1443301-1-frankramirez@google.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d4375909d89e05b17b72916ebc698e527657ce9e Author: Chandrakanth Patil Date: Wed Aug 20 14:11:34 2025 +0530 scsi: mpi3mr: Fix controller init failure on fault during queue creation [ Upstream commit 829fa1582b6ff607b0e2fe41ba1c45c77f686618 ] Firmware can enter a transient fault while creating operational queues. The driver fails the load immediately. Add a retry loop that checks controller status and history bit after queue creation. If either indicates a fault, retry init up to a set limit before failing. Signed-off-by: Chandrakanth Patil Link: https://lore.kernel.org/r/20250820084138.228471-3-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f3355d810570d42e4d4d0c0652fb21321092d2f8 Author: Chandrakanth Patil Date: Wed Aug 20 14:11:35 2025 +0530 scsi: mpi3mr: Fix I/O failures during controller reset [ Upstream commit b7b2176e30fc8e57664e5a8a23387af66eb7f72b ] I/Os can race with controller reset and fail. Block requests at the mid layer when reset starts using scsi_host_block(), and resume with scsi_host_unblock() after reset completes. Signed-off-by: Chandrakanth Patil Link: https://lore.kernel.org/r/20250820084138.228471-4-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a0559eb8dcc6a0c48b84963c092df6cf658cd6db Author: Oscar Maes Date: Tue Aug 19 19:46:41 2025 +0200 net: ipv4: allow directed broadcast routes to use dst hint [ Upstream commit 1b8c5fa0cb35efd08f07f700e6d78a541ebabe26 ] Currently, ip_extract_route_hint uses RTN_BROADCAST to decide whether to use the route dst hint mechanism. This check is too strict, as it prevents directed broadcast routes from using the hint, resulting in poor performance during bursts of directed broadcast traffic. Fix this in ip_extract_route_hint and modify ip_route_use_hint to preserve the intended behaviour. Signed-off-by: Oscar Maes Reviewed-by: David Ahern Link: https://patch.msgid.link/20250819174642.5148-2-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 212187161ececf56e617e3c0bce7d4f4804493e7 Author: Andrew Davis Date: Thu Jun 19 15:57:22 2025 -0500 rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table [ Upstream commit 6e29c30d8ddea6109ea7e0b9f17e7841df0794ea ] Module aliases are used by userspace to identify the correct module to load for a detected hardware. The currently supported RPMSG device IDs for this module include "rpmsg-raw", but the module alias is "rpmsg_chrdev". Use the helper macro MODULE_DEVICE_TABLE(rpmsg) to export the correct supported IDs. And while here, to keep backwards compatibility we also add the other ID "rpmsg_chrdev" so that it is also still exported as an alias. This has the side benefit of adding support for some legacy firmware which still uses the original "rpmsg_chrdev" ID. This was the ID used for this driver before it was upstreamed (as reflected by the module alias). Signed-off-by: Andrew Davis Acked-by: Hari Nagalla Tested-by: Hari Nagalla Link: https://lore.kernel.org/r/20250619205722.133827-1-afd@ti.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 0db2260ecd3cd1943bb36138d9113d198ea50c8e Author: Sakari Ailus Date: Wed May 21 11:06:16 2025 +0300 media: ipu6: isys: Set embedded data type correctly for metadata formats [ Upstream commit f5a2826cd50c6fd1af803812d1d910a64ae8e0a1 ] The IPU6 ISYS driver supported metadata formats but was missing correct embedded data type in the receiver configuration. Add it now. Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 93fbacaf4875ee30529abdaf5c73a93f033a0b36 Author: Jiawen Wu Date: Thu Aug 21 10:34:06 2025 +0800 net: wangxun: limit tx_max_coalesced_frames_irq [ Upstream commit fd4aa243f154a80bbeb3dd311d2114eeb538f479 ] Add limitation on tx_max_coalesced_frames_irq as 0 ~ 65535, because 'wx->tx_work_limit' is declared as a member of type u16. Signed-off-by: Jiawen Wu Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250821023408.53472-3-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c0aac13ce3789dd89ad92ea7906e5a5a5ba67948 Author: Ujwal Kundur Date: Wed Aug 20 23:25:49 2025 +0530 rds: Fix endianness annotation for RDS_MPATH_HASH [ Upstream commit 77907a068717fbefb25faf01fecca553aca6ccaa ] jhash_1word accepts host endian inputs while rs_bound_port is a be16 value (sockaddr_in6.sin6_port). Use ntohs() for consistency. Flagged by Sparse. Signed-off-by: Ujwal Kundur Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20250820175550.498-4-ujwal.kundur@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b2caf82bcdfe4f2bddcbe79409d10926d0024459 Author: Eric Dumazet Date: Mon Aug 18 19:59:34 2025 +0000 idpf: do not linearize big TSO packets [ Upstream commit 02614eee26fbdfd73b944769001cefeff6ed008c ] idpf has a limit on number of scatter-gather frags that can be used per segment. Currently, idpf_tx_start() checks if the limit is hit and forces a linearization of the whole packet. This requires high order allocations that can fail under memory pressure. A full size BIG-TCP packet would require order-7 alocation on x86_64 :/ We can move the check earlier from idpf_features_check() for TSO packets, to force GSO in this case, removing the cost of a big copy. This means that a linearization will eventually happen with sizes smaller than one MSS. __idpf_chk_linearize() is renamed to idpf_chk_tso_segment() and moved to idpf_lib.c Signed-off-by: Eric Dumazet Cc: Przemek Kitszel Cc: Jacob Keller Cc: Madhu Chittim Cc: Pavan Kumar Linga Cc: Willem de Bruijn Cc: Andrew Lunn Reviewed-by: Joshua Hay Tested-by: Brian Vazquez Acked-by: Tony Nguyen Link: https://patch.msgid.link/20250818195934.757936-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9b966c72b6a7a1a5152b266be5620ef87b97e38f Author: Takashi Iwai Date: Thu Aug 21 17:17:50 2025 +0200 ALSA: usb-audio: Add validation of UAC2/UAC3 effect units [ Upstream commit 2aec0b6a6b5395bca7d6fde9c7e9dc391d329698 ] Just add fixed struct size validations for UAC2 and UAC3 effect units. The descriptor has a variable-length array, so it should be validated with a proper function later once when the unit is really parsed and used by the driver (currently only referred partially for the input terminal parsing). Link: https://patch.msgid.link/20250821151751.12100-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 5a1e6d4dd11a748ce5f8a97e065cfad523b12375 Author: Xichao Zhao Date: Tue Aug 19 20:09:27 2025 +0800 tty: serial: Modify the use of dev_err_probe() [ Upstream commit 706c3c02eecd41dc675e9102b3719661cd3e30e2 ] The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Make the following two changes: (1) Replace -ENOMEM with -ENOSPC in max3100_probe(). (2) Just return -ENOMEM instead in max310x_probe(). Signed-off-by: Xichao Zhao Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250819120927.607744-1-zhao.xichao@vivo.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 97c9394124a0b1ff65c03db74b5393507fa00ce9 Author: Pavan Chebbi Date: Tue Aug 19 09:39:19 2025 -0700 bnxt_en: Add Hyper-V VF ID [ Upstream commit 5be7cb805bd9a6680b863a1477dbc6e7986cc223 ] VFs of the P7 chip family created by Hyper-V will have the device ID of 0x181b. Reviewed-by: Somnath Kotur Reviewed-by: Kalesh AP Signed-off-by: Pavan Chebbi Signed-off-by: Michael Chan Link: https://patch.msgid.link/20250819163919.104075-6-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ccb8a899530f1eddb764c93640f261d51d43f1a3 Author: Sungho Kim Date: Wed Aug 20 19:57:14 2025 +0900 PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call [ Upstream commit 6238784e502b6a9fbeb3a6b77284b29baa4135cc ] The error handling path in pci_p2pdma_add_resource() contains a bug in its `pgmap_free` label. Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`, which is a pointer to a member field within the `p2p_pgmap` struct, not the base pointer of the allocation. Correct the bug by passing the correct base pointer, `p2p_pgmap`, to devm_kfree(). Signed-off-by: Sungho Kim Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Link: https://patch.msgid.link/20250820105714.2939896-1-sungho.kim@furiosa.ai Signed-off-by: Sasha Levin commit 6b9525596a83cd5b7bbc2c7bd5f9ad9cf5ad60fa Author: Chao Yu Date: Thu Aug 7 10:44:31 2025 +0800 f2fs: fix to detect potential corrupted nid in free_nid_list [ Upstream commit 8fc6056dcf79937c46c97fa4996cda65956437a9 ] As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0f5cb5b089b0535413750aea1952f4fe7a41980c Author: Kuniyuki Iwashima Date: Fri Aug 15 20:16:12 2025 +0000 net: Call trace_sock_exceed_buf_limit() for memcg failure with SK_MEM_RECV. [ Upstream commit 9d85c565a7b7c78b732393c02bcaa4d5c275fe58 ] Initially, trace_sock_exceed_buf_limit() was invoked when __sk_mem_raise_allocated() failed due to the memcg limit or the global limit. However, commit d6f19938eb031 ("net: expose sk wmem in sock_exceed_buf_limit tracepoint") somehow suppressed the event only when memcg failed to charge for SK_MEM_RECV, although the memcg failure for SK_MEM_SEND still triggers the event. Let's restore the event for SK_MEM_RECV. Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Reviewed-by: Shakeel Butt Link: https://patch.msgid.link/20250815201712.1745332-5-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 719fcdf29051f7471d5d433475af76219019d33d Author: Oleksij Rempel Date: Mon Aug 18 11:02:15 2025 +0200 net: stmmac: Correctly handle Rx checksum offload errors [ Upstream commit ee0aace5f844ef59335148875d05bec8764e71e8 ] The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet. Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20250818090217.2789521-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2263e086abefb7e860dc1160762d7de6bb09f37a Author: Christoph Paasch Date: Sat Aug 16 16:12:49 2025 -0700 net: When removing nexthops, don't call synchronize_net if it is not necessary [ Upstream commit b0ac6d3b56a2384db151696cfda2836a8a961b6d ] When removing a nexthop, commit 90f33bffa382 ("nexthops: don't modify published nexthop groups") added a call to synchronize_rcu() (later changed to _net()) to make sure everyone sees the new nexthop-group before the rtnl-lock is released. When one wants to delete a large number of groups and nexthops, it is fastest to first flush the groups (ip nexthop flush groups) and then flush the nexthops themselves (ip -6 nexthop flush). As that way the groups don't need to be rebalanced. However, `ip -6 nexthop flush` will still take a long time if there is a very large number of nexthops because of the call to synchronize_net(). Now, if there are no more groups, there is no point in calling synchronize_net(). So, let's skip that entirely by checking if nh->grp_list is empty. This gives us a nice speedup: BEFORE: ======= $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 1m45.345s user 0m0.001s sys 0m0.005s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 3m10.430s user 0m0.002s sys 0m0.004s AFTER: ====== $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 2097152 nexthops real 0m17.545s user 0m0.003s sys 0m0.003s $ time sudo ip -6 nexthop flush Dump was interrupted and may be inconsistent. Flushed 4194304 nexthops real 0m35.823s user 0m0.002s sys 0m0.004s Signed-off-by: Christoph Paasch Reviewed-by: Ido Schimmel Reviewed-by: Nikolay Aleksandrov Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20250816-nexthop_dump-v2-2-491da3462118@openai.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6f3dcc809071deb8f7f07954d597b418cf62d3af Author: Zijun Hu Date: Mon Jul 14 23:34:17 2025 +0800 char: misc: Does not request module for miscdevice with dynamic minor [ Upstream commit 1ba0fb42aa6a5f072b1b8c0b0520b32ad4ef4b45 ] misc_open() may request module for miscdevice with dynamic minor, which is meaningless since: - The dynamic minor allocated is unknown in advance without registering miscdevice firstly. - Macro MODULE_ALIAS_MISCDEV() is not applicable for dynamic minor. Fix by only requesting module for miscdevice with fixed minor. Acked-by: Thadeu Lima de Souza Cascardo Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250714-rfc_miscdev-v6-6-2ed949665bde@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 72cd71ec60e89b4d9662578d46c5302d09957247 Author: Zijun Hu Date: Mon Jul 14 23:34:16 2025 +0800 char: misc: Make misc_register() reentry for miscdevice who wants dynamic minor [ Upstream commit 52e2bb5ff089d65e2c7d982fe2826dc88e473d50 ] For miscdevice who wants dynamic minor, it may fail to be registered again without reinitialization after being de-registered, which is illustrated by kunit test case miscdev_test_dynamic_reentry() newly added. There is a real case found by cascardo when a part of minor range were contained by range [0, 255): 1) wmi/dell-smbios registered minor 122, and acpi_thermal_rel registered minor 123 2) unbind "int3400 thermal" driver from its device, this will de-register acpi_thermal_rel 3) rmmod then insmod dell_smbios again, now wmi/dell-smbios is using minor 123 4) bind the device to "int3400 thermal" driver again, acpi_thermal_rel fails to register. Some drivers may reuse the miscdevice structure after they are deregistered If the intention is to allocate a dynamic minor, if the minor number is not reset to MISC_DYNAMIC_MINOR before calling misc_register(), it will try to register a previously dynamically allocated minor number, which may have been registered by a different driver. One such case is the acpi_thermal_rel misc device, registered by the int3400 thermal driver. If the device is unbound from the driver and later bound, if there was another dynamic misc device registered in between, it would fail to register the acpi_thermal_rel misc device. Other drivers behave similarly. Actually, this kind of issue is prone to happen if APIs misc_register()/misc_deregister() are invoked by driver's probe()/remove() separately. Instead of fixing all the drivers, just reset the minor member to MISC_DYNAMIC_MINOR in misc_deregister() in case it was a dynamically allocated minor number, as error handling of misc_register() does. Cc: Thadeu Lima de Souza Cascardo Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/20250714-rfc_miscdev-v6-5-2ed949665bde@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b40c7c348f6a635c625861d5278d0ab22b13e66c Author: Christoph Hellwig Date: Mon Aug 18 06:58:21 2025 +0200 dm error: mark as DM_TARGET_PASSES_INTEGRITY [ Upstream commit 499cbe0f2fb0641cf07a1a8ac9f7317674295fea ] Mark dm error as DM_TARGET_PASSES_INTEGRITY so that it can be stacked on top of PI capable devices. The claim is strictly speaking as lie as dm error fails all I/O and doesn't pass anything on, but doing the same for integrity I/O work just fine :) This helps to make about two dozen xfstests test cases pass on PI capable devices. Signed-off-by: Christoph Hellwig Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 958234997dd51875e5c7398eadd0c349203d44b5 Author: Kuan-Chung Chen Date: Mon Aug 11 20:39:50 2025 +0800 wifi: rtw89: fix BSSID comparison for non-transmitted BSSID [ Upstream commit c4c16c88e78417424b4e3f33177e84baf0bc9a99 ] For non-transmitted connections, beacons are received from the transmitted BSSID. Fix this to avoid missing beacon statistics. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250811123950.15697-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit ca18975c4de2e439f069e40a43f02a05d2caf5c6 Author: Kuan-Chung Chen Date: Mon Aug 11 20:37:39 2025 +0800 wifi: rtw89: wow: remove notify during WoWLAN net-detect [ Upstream commit 38846585f9df9af1f7261d85134a5510fc079458 ] In WoWLAN net-detect mode, the firmware periodically performs scans and sends scan reports via C2H, which driver does not need. These unnecessary C2H events cause firmware watchdog timeout, leading to unexpected wakeups and SER 0x2599 on 8922AE. Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250811123744.15361-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit 858e1b984408c9d733d9409866f4df4346564acd Author: raub camaioni Date: Fri Aug 15 09:07:21 2025 -0400 usb: gadget: f_ncm: Fix MAC assignment NCM ethernet [ Upstream commit 956606bafb5fc6e5968aadcda86fc0037e1d7548 ] This fix is already present in f_ecm.c and was never propagated to f_ncm.c When creating multiple NCM ethernet devices on a composite usb gadget device each MAC address on the HOST side will be identical. Having the same MAC on different network interfaces is bad. This fix updates the MAC address inside the ncm_strings_defs global during the ncm_bind call. This ensures each device has a unique MAC. In f_ecm.c ecm_string_defs is updated in the same way. The defunct MAC assignment in ncm_alloc has been removed. Signed-off-by: raub camaioni Link: https://lore.kernel.org/r/20250815131358.1047525-1-raubcameo@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5a46feb45873c76705bf9609f5eb7a4f8ac13ddf Author: Haibo Chen Date: Tue Aug 12 16:04:23 2025 +0800 iio: adc: imx93_adc: load calibrated values even calibration failed [ Upstream commit 12c9b09e981ab14ebec8e4eefa946cbd26dd306b ] ADC calibration might fail because of the noise on reference voltage. To avoid calibration fail, need to meet the following requirement: ADC reference voltage Noise < 1.8V * 1/2^ENOB For the case which the ADC reference voltage on board do not meet the requirement, still load the calibrated values, so ADC can also work but maybe not that accurate. Signed-off-by: Haibo Chen Reviewed-by: Frank Li Reviewed-by: Primoz Fiser Link: https://patch.msgid.link/20250812-adc-v2-2-0260833f13b8@nxp.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 71cb5d38a7398b005795d69fd579afd12d9a24fc Author: Rodrigo Gobbi Date: Thu Jul 17 19:13:49 2025 -0300 iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before setting register [ Upstream commit d75c7021c08e8ae3f311ef2464dca0eaf75fab9f ] avg sample info is a bit field coded inside the following bits: 5,6,7 and 8 of a device status register. Channel num info the same, but over bits: 1, 2 and 3. Mask both values in order to avoid touching other register bits, since the first info (avg sample), came from DT. Signed-off-by: Rodrigo Gobbi Reviewed-by: David Lechner Link: https://patch.msgid.link/20250717221559.158872-1-rodrigo.gobbi.7@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b8698db53a1b40583c164888008aa1442f2e56d5 Author: Kent Russell Date: Mon Jul 21 14:06:36 2025 -0400 drm/amdkfd: Handle lack of READ permissions in SVM mapping [ Upstream commit 0ed704d058cec7643a716a21888d58c7d03f2c3e ] HMM assumes that pages have READ permissions by default. Inside svm_range_validate_and_map, we add READ permissions then add WRITE permissions if the VMA isn't read-only. This will conflict with regions that only have PROT_WRITE or have PROT_NONE. When that happens, svm_range_restore_work will continue to retry, silently, giving the impression of a hang if pr_debug isn't enabled to show the retries.. If pages don't have READ permissions, simply unmap them and continue. If they weren't mapped in the first place, this would be a no-op. Since x86 doesn't support write-only, and PROT_NONE doesn't allow reads or writes anyways, this will allow the svm range validation to continue without getting stuck in a loop forever on mappings we can't use with HMM. Signed-off-by: Kent Russell Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 47281febebe337586569aa4c5694a7511063a42e Author: Heng Zhou Date: Wed Aug 13 11:18:04 2025 +0800 drm/amdgpu: fix nullptr err of vm_handle_moved [ Upstream commit 859958a7faefe5b7742b7b8cdbc170713d4bf158 ] If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved. Signed-off-by: Heng Zhou Reviewed-by: Kasiviswanathan, Harish Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ac5a106c6da6e922a8c71b7505c2084ab6d45728 Author: Dmitry Baryshkov Date: Sat Aug 2 13:40:35 2025 +0300 drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ] Detecting the monitor for DisplayPort targets is more complicated than just reading the HPD pin level: it requires reading the DPCD in order to check what kind of device is attached to the port and whether there is an actual display attached. In order to let DRM framework handle such configurations, disable DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so it is valid for the bridge to report HPD events. Currently inside the kernel there are only two targets which list hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and arm64/qcom/sa8295p-adp. Both should be fine with this change. Cc: Bjorn Andersson Cc: Konrad Dybcio Cc: linux-arm-msm@vger.kernel.org Acked-by: Laurent Pinchart Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit fecad289604988711c5891039be2699f65120e98 Author: Tomasz Pakuła Date: Wed Aug 13 22:10:00 2025 +0200 HID: pidff: PERMISSIVE_CONTROL quirk autodetection [ Upstream commit c2dc9f0b368c08c34674311cf78407718d5715a7 ] Fixes force feedback for devices built with MMOS firmware and many more not yet detected devices. Update quirks mask debug message to always contain all 32 bits of data. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 17107ba4050e1c6db6e3df7461371aa3adefd068 Author: Tomasz Pakuła Date: Wed Aug 13 22:09:49 2025 +0200 HID: pidff: Use direction fix only for conditional effects [ Upstream commit f345a4798dab800159b09d088e7bdae0f16076c3 ] The already fixed bug in SDL only affected conditional effects. This should fix FFB in Forza Horizion 4/5 on Moza Devices as Forza Horizon flips the constant force direction instead of using negative magnitude values. Changing the direction in the effect directly in pidff_upload_effect() would affect it's value in further operations like comparing to the old effect and/or just reading the effect values in the user application. This, in turn, would lead to constant PID_SET_EFFECT spam as the effect direction would constantly not match the value that's set by the application. This way, it's still transparent to any software/API. Only affects conditional effects now so it's better for it to explicitly state that in the name. If any HW ever needs fixed direction for other effects, we'll add more quirks. Signed-off-by: Tomasz Pakuła Reviewed-by: Oleg Makarenko Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 475e9d306c1c1479e49e1790bde022356f603b1d Author: Karunika Choo Date: Thu Aug 7 17:26:31 2025 +0100 drm/panthor: Serialize GPU cache flush operations [ Upstream commit e322a4844811b54477b7072eb40dc9e402a1725d ] In certain scenarios, it is possible for multiple cache flushes to be requested before the previous one completes. This patch introduces the cache_flush_lock mutex to serialize these operations and ensure that any requested cache flushes are completed instead of dropped. Reviewed-by: Liviu Dudau Co-developed-by: Dennis Tsiang Signed-off-by: Dennis Tsiang Signed-off-by: Karunika Choo Reviewed-by: Steven Price Signed-off-by: Steven Price Link: https://lore.kernel.org/r/20250807162633.3666310-6-karunika.choo@arm.com Signed-off-by: Sasha Levin commit 0213e4175abbb9dfcbf7c197e3817d527f459ad5 Author: Tetsuo Handa Date: Thu Jul 17 23:21:55 2025 +0900 media: imon: make send_packet() more robust [ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ] syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds. Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1] Link: https://lkml.kernel.org/r/d6da6709-d799-4be3-a695-850bddd6eb24@rowland.harvard.edu [2] Signed-off-by: Tetsuo Handa Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c14cf41094136691c92ef756872570645d61f4a1 Author: Charalampos Mitrodimas Date: Tue Aug 12 15:51:25 2025 +0000 net: ipv6: fix field-spanning memcpy warning in AH output [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ] Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication. Reported-by: syzbot+01b0667934cdceb4451c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c Signed-off-by: Charalampos Mitrodimas Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 22dd4394da5a2e2602bfefbf7568a480e55422b2 Author: Alice Chao Date: Mon Aug 11 21:11:26 2025 +0800 scsi: ufs: host: mediatek: Fix invalid access in vccqx handling [ Upstream commit 5863638598f5e4f64d2f85b03f376383ca1f2ab7 ] Add a NULL check before accessing the 'vccqx' pointer to prevent invalid memory access. This ensures that the function safely handles cases where 'vccq' and 'vccq2' are not initialized, improving the robustness of the power management code. Signed-off-by: Alice Chao Reviewed-by: Peter Wang Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20250811131423.3444014-11-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f394022d753e7414c2bfb0779d8c70081874364d Author: Peter Wang Date: Mon Aug 11 21:11:25 2025 +0800 scsi: ufs: host: mediatek: Change reset sequence for improved stability [ Upstream commit 878ed88c50bfb14d972dd3b86a1c8188c58de4e5 ] Modify the reset sequence to ensure that the device reset pin is set low before the host is disabled. This change enhances the stability of the reset process by ensuring the correct order of operations. Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20250811131423.3444014-10-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 514a0a4c4945ea9e924a258d94f8ee25cdf0a9c1 Author: Alice Chao Date: Mon Aug 11 21:11:22 2025 +0800 scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO mode change [ Upstream commit 979feee0cf43b32d288931649d7c6d9a5524ea55 ] Assign power mode userdata settings before transitioning to FASTAUTO power mode. This ensures that default timeout values are set for various parameters, enhancing the reliability and performance of the power mode change process. Signed-off-by: Alice Chao Reviewed-by: Peter Wang Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20250811131423.3444014-7-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3cedc28d28695f534b9cec4d6b1d0262d8cb33a9 Author: Peter Wang Date: Mon Aug 11 21:11:21 2025 +0800 scsi: ufs: host: mediatek: Fix PWM mode switch issue [ Upstream commit 7212d624f8638f8ea8ad1ecbb80622c7987bc7a1 ] Address a failure in switching to PWM mode by ensuring proper configuration of power modes and adaptation settings. The changes include checks for SLOW_MODE and adjustments to the desired working mode and adaptation configuration based on the device's power mode and hardware version. Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20250811131423.3444014-6-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9aa36bba595330389ee57bcbcbae82ed9927267a Author: Peter Wang Date: Mon Aug 11 21:11:18 2025 +0800 scsi: ufs: host: mediatek: Fix auto-hibern8 timer configuration [ Upstream commit aa86602a483ba48f51044fbaefa1ebbf6da194a4 ] Move the configuration of the Auto-Hibern8 (AHIT) timer from the post-link stage to the 'fixup_dev_quirks' function. This change allows setting the AHIT based on the vendor requirements: (a) Samsung: 3.5 ms (b) Micron: 2 ms (c) Others: 1 ms Additionally, the clock gating timer is adjusted based on the AHIT scale, with a maximum setting of 10 ms. This ensures that the clock gating delay is appropriately configured to match the AHIT settings. Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20250811131423.3444014-3-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d7e41e51c4d0e6d9e89760e27f722f3a3bf95594 Author: Ido Schimmel Date: Tue Aug 12 11:02:12 2025 +0300 bridge: Redirect to backup port when port is administratively down [ Upstream commit 3d05b24429e1de7a17c8fdccb04a04dbc8ad297b ] If a backup port is configured for a bridge port, the bridge will redirect known unicast traffic towards the backup port when the primary port is administratively up but without a carrier. This is useful, for example, in MLAG configurations where a system is connected to two switches and there is a peer link between both switches. The peer link serves as the backup port in case one of the switches loses its connection to the multi-homed system. In order to avoid flooding when the primary port loses its carrier, the bridge does not flush dynamic FDB entries pointing to the port upon STP disablement, if the port has a backup port. The above means that known unicast traffic destined to the primary port will be blackholed when the port is put administratively down, until the FDB entries pointing to it are aged-out. Given that the current behavior is quite weird and unlikely to be depended on by anyone, amend the bridge to redirect to the backup port also when the primary port is administratively down and not only when it does not have a carrier. The change is motivated by a report from a user who expected traffic to be redirected to the backup port when the primary port was put administratively down while debugging a network issue. Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20250812080213.325298-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a77f4ee149db75ae850a7bf70c03173d07e8f2bf Author: Niklas Schnelle Date: Thu Aug 7 15:55:39 2025 +0200 s390/pci: Use pci_uevent_ers() in PCI recovery [ Upstream commit dab32f2576a39d5f54f3dbbbc718d92fa5109ce9 ] Issue uevents on s390 during PCI recovery using pci_uevent_ers() as done by EEH and AER PCIe recovery routines. Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20250807-add_err_uevents-v5-2-adf85b0620b0@linux.ibm.com Signed-off-by: Sasha Levin commit 62b249b132fc17f4c6510c4d2317f0b3a607b3f9 Author: Niklas Schnelle Date: Thu Aug 7 15:55:40 2025 +0200 powerpc/eeh: Use result of error_detected() in uevent [ Upstream commit 704e5dd1c02371dfc7d22e1520102b197a3b628b ] Ever since uevent support was added for AER and EEH with commit 856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume"), it reported PCI_ERS_RESULT_NONE as uevent when recovery begins. Commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for udev") subsequently amended AER to report the actual return value of error_detected(). Make the same change to EEH to align it with AER and s390. Suggested-by: Lukas Wunner Link: https://lore.kernel.org/linux-pci/aIp6LiKJor9KLVpv@wunner.de/ Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Kuppuswamy Sathyanarayanan Acked-by: Mahesh Salgaonkar Link: https://patch.msgid.link/20250807-add_err_uevents-v5-3-adf85b0620b0@linux.ibm.com Signed-off-by: Sasha Levin commit 460e0dc9af2d7790d5194c6743d79f9b77b58836 Author: Thomas Bogendoerfer Date: Fri Jul 25 15:40:17 2025 +0200 tty: serial: ip22zilog: Use platform device for probing [ Upstream commit 3fc36ae6abd263a5cbf93b2f5539eccc1fc753f7 ] After commit 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") serial drivers need to provide a device in struct uart_port.dev otherwise an oops happens. To fix this issue for ip22zilog driver switch driver to a platform driver and setup the serial device in sgi-ip22 code. Signed-off-by: Thomas Bogendoerfer Link: https://lore.kernel.org/r/20250725134018.136113-1-tsbogend@alpha.franken.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c3b015d15c820b96df5d9522be11a0065569c1f9 Author: Lukas Wunner Date: Tue Aug 12 15:42:29 2025 +0200 thunderbolt: Use is_pciehp instead of is_hotplug_bridge [ Upstream commit 5d03847175e81e86d4865456c15638faaf7c0634 ] The thunderbolt driver sets up device link dependencies from hotplug ports to the Host Router (aka Native Host Interface, NHI). When resuming from system sleep, this allows the Host Router to re-establish tunnels to attached Thunderbolt devices before the hotplug ports resume. To identify the hotplug ports, the driver utilizes the is_hotplug_bridge flag which also encompasses ACPI slots handled by the ACPI hotplug driver. Thunderbolt hotplug ports are always Hot-Plug Capable PCIe ports, so it is more apt to identify them with the is_pciehp flag. Similarly, hotplug ports on older Thunderbolt controllers have broken MSI support and are quirked to use legacy INTx interrupts instead. The quirk identifies them with is_hotplug_bridge, even though all affected ports are also matched by is_pciehp. So use is_pciehp here as well. Signed-off-by: Lukas Wunner Acked-by: Bjorn Helgaas Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 747930be915efe7d5916a00b5730580f20b27d61 Author: Thomas Weißschuh Date: Mon Aug 11 11:43:18 2025 +0200 ice: Don't use %pK through printk or tracepoints [ Upstream commit 66ceb45b7d7e9673254116eefe5b6d3a44eba267 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Acked-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Reviewed-by: Simon Horman Reviewed-by: Paul Menzel Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250811-restricted-pointers-net-v5-1-2e2fdc7d3f2c@linutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 740bfb80ac59433b08847c51d0b85fab350a550a Author: Tiezhu Yang Date: Mon Aug 11 15:35:04 2025 +0800 net: stmmac: Check stmmac_hw_setup() in stmmac_resume() [ Upstream commit 6896c2449a1858acb643014894d01b3a1223d4e5 ] stmmac_hw_setup() may return 0 on success and an appropriate negative integer as defined in errno.h file on failure, just check it and then return early if failed in stmmac_resume(). Signed-off-by: Tiezhu Yang Reviewed-by: Maxime Chevallier Reviewed-by: Huacai Chen Link: https://patch.msgid.link/20250811073506.27513-2-yangtiezhu@loongson.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b2d4eea3f54cba5c216d456c0b6b944db31bc2c Author: Kirill A. Shutemov Date: Tue Jun 24 17:59:18 2025 +0300 x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall [ Upstream commit 8ba38a7a9a699905b84fa97578a8291010dec273 ] emulate_vsyscall() expects to see X86_PF_INSTR in PFEC on a vsyscall page fault, but the CPU does not report X86_PF_INSTR if neither X86_FEATURE_NX nor X86_FEATURE_SMEP are enabled. X86_FEATURE_NX should be enabled on nearly all 64-bit CPUs, except for early P4 processors that did not support this feature. Instead of explicitly checking for X86_PF_INSTR, compare the fault address to RIP. On machines with X86_FEATURE_NX enabled, issue a warning if RIP is equal to fault address but X86_PF_INSTR is absent. [ dhansen: flesh out code comments ] Originally-by: Dave Hansen Reported-by: Andrew Cooper Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Andrew Cooper Link: https://lore.kernel.org/all/bd81a98b-f8d4-4304-ac55-d4151a1a77ab@intel.com Link: https://lore.kernel.org/all/20250624145918.2720487-1-kirill.shutemov%40linux.intel.com Signed-off-by: Sasha Levin commit fea2f9e487d7db14dd024eb2f1f919b99139e1e7 Author: Lukas Wunner Date: Wed Aug 13 07:11:04 2025 +0200 PCI/ERR: Update device error_state already after reset [ Upstream commit 45bc82563d5505327d97963bc54d3709939fa8f8 ] After a Fatal Error has been reported by a device and has been recovered through a Secondary Bus Reset, AER updates the device's error_state to pci_channel_io_normal before invoking its driver's ->resume() callback. By contrast, EEH updates the error_state earlier, namely after resetting the device and before invoking its driver's ->slot_reset() callback. Commit c58dc575f3c8 ("powerpc/pseries: Set error_state to pci_channel_io_normal in eeh_report_reset()") explains in great detail that the earlier invocation is necessitated by various drivers checking accessibility of the device with pci_channel_offline() and avoiding accesses if it returns true. It returns true for any other error_state than pci_channel_io_normal. The device should be accessible already after reset, hence the reasoning is that it's safe to update the error_state immediately afterwards. This deviation between AER and EEH seems problematic because drivers behave differently depending on which error recovery mechanism the platform uses. Three drivers have gone so far as to update the error_state themselves, presumably to work around AER's behavior. For consistency, amend AER to update the error_state at the same recovery steps as EEH. Drop the now unnecessary workaround from the three drivers. Keep updating the error_state before ->resume() in case ->error_detected() or ->mmio_enabled() return PCI_ERS_RESULT_RECOVERED, which causes ->slot_reset() to be skipped. There are drivers doing this even for Fatal Errors, e.g. mhi_pci_error_detected(). Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/4517af6359ffb9d66152b827a5d2833459144e3f.1755008151.git.lukas@wunner.de Signed-off-by: Sasha Levin commit e12465e5b70c5fce14c9daf5121e1db8a53e8813 Author: Mehdi Djait Date: Mon Jul 14 15:23:56 2025 +0200 media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for VIDEO_CAMERA_SENSOR [ Upstream commit 2d240b124cc9df62ccccee6054bc3d1d19018758 ] Both ACPI and DT-based systems are required to obtain the external camera sensor clock using the new devm_v4l2_sensor_clk_get() helper function. Ensure a dependency on HAVE_CLK when config VIDEO_CAMERA_SENSOR is enabled. Signed-off-by: Mehdi Djait Reviewed-by: Arnd Bergmann Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 6f6a157df378e93c99ad34ea0352e7a79e3774d1 Author: Jayesh Choudhary Date: Tue Jun 24 13:34:02 2025 +0530 drm/tidss: Set crtc modesetting parameters with adjusted mode [ Upstream commit cfb29225db20c56432a8525366321c0c09edfb2e ] TIDSS uses crtc_* fields to propagate its registers and set the clock rates. So set the CRTC modesetting timing parameters with the adjusted mode when needed, to set correct values. Cc: Tomi Valkeinen Signed-off-by: Jayesh Choudhary Link: https://lore.kernel.org/r/20250624080402.302526-1-j-choudhary@ti.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit e6f4716011fd229eb022d0b1e60fff1b5dd24332 Author: Tomi Valkeinen Date: Wed Jul 23 13:05:21 2025 +0300 drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST [ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ] While the cdns-dsi does not support DSI burst mode, the burst mode is essentially DSI event mode with more versatile clocking and timings. Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests MIPI_DSI_MODE_VIDEO_BURST. In my particular use case, this allows the use of ti-sn65dsi83 driver. Tested-by: Parth Pancholi Tested-by: Jayesh Choudhary Reviewed-by: Devarsh Thakkar Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 6827f61b02f4d57d1a1805c68b5f2258a26b86cf Author: Tomi Valkeinen Date: Wed Jul 23 13:05:17 2025 +0300 drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value [ Upstream commit eea4f89b6461294ed6bea1d3285bb3f79c09a041 ] The driver tries to calculate the value for REG_WAKEUP_TIME. However, the calculation itself is not correct, and to add on it, the resulting value is almost always larger than the field's size, so the actual result is more or less random. According to the docs, figuring out the value for REG_WAKEUP_TIME requires HW characterization and there's no way to have a generic algorithm to come up with the value. That doesn't help at all... However, we know that the value must be smaller than the line time, and, at least in my understanding, the proper value for it is quite small. Testing shows that setting it to 1/10 of the line time seems to work well. All video modes from my HDMI monitor work with this algorithm. Hopefully we'll get more information on how to calculate the value, and we can then update this. Tested-by: Parth Pancholi Tested-by: Jayesh Choudhary Reviewed-by: Devarsh Thakkar Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-11-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 754cb9cc89f63d85458a19adcd189382991e9f82 Author: Tomi Valkeinen Date: Wed Jul 23 13:05:09 2025 +0300 drm/tidss: Use the crtc_* timings when programming the HW [ Upstream commit 478306edc23eec4f0ec24a46222485910c66212d ] Use the crtc_* fields from drm_display_mode, instead of the "logical" fields. This shouldn't change anything in practice, but afaiu the crtc_* fields are the correct ones to use here. Reviewed-by: Aradhya Bhatia Tested-by: Parth Pancholi Tested-by: Jayesh Choudhary Reviewed-by: Devarsh Thakkar Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-3-e61cc06074c2@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Sasha Levin commit 41edf187dd246ae9f192f06ad481802bec1ad778 Author: Laurent Pinchart Date: Sun Aug 10 04:29:56 2025 +0300 media: amphion: Delete v4l2_fh synchronously in .release() [ Upstream commit 19fb9c5b815f70eb90d5b545f65b83bc9c490ecd ] The v4l2_fh initialized and added in vpu_v4l2_open() is delete and cleaned up when the last reference to the vpu_inst is released. This may happen later than at vpu_v4l2_close() time. Not deleting and cleaning up the v4l2_fh when closing the file handle to the video device is not ideal, as the v4l2_fh will still be present in the video device's fh_list, and will store a copy of events queued to the video device. There may also be other side effects of keeping alive an object that represents an open file handle after the file handle is closed. The v4l2_fh instance is embedded in the vpu_inst structure, and is accessed in two different ways: - in vpu_notify_eos() and vpu_notify_source_change(), to queue V4L2 events to the file handle ; and - through the driver to access the v4l2_fh.m2m_ctx pointer. The v4l2_fh.m2m_ctx pointer is not touched by v4l2_fh_del() and v4l2_fh_exit(). It is set to NULL by the driver when closing the file handle, in vpu_v4l2_close(). The vpu_notify_eos() and vpu_notify_source_change() functions are called in vpu_set_last_buffer_dequeued() and vdec_handle_resolution_change() respectively, only if the v4l2_fh.m2m_ctx pointer is not NULL. There is therefore a guarantee that no new event will be queued to the v4l2_fh after vpu_v4l2_close() destroys the m2m_ctx. The vpu_notify_eos() function is also called from vpu_vb2_buf_finish(), which is guaranteed to be called for all queued buffers when vpu_v4l2_close() calls v4l2_m2m_ctx_release(), and will not be called later. It is therefore safe to assume that the driver will not touch the v4l2_fh, except to check the m2m_ctx pointer, after vpu_v4l2_close() destroys the m2m_ctx. We can safely delete and cleanup the v4l2_fh synchronously in vpu_v4l2_close(). Signed-off-by: Laurent Pinchart Reviewed-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c9d4cf333f3d78147ead2f1dd73d3360c955ede6 Author: Laurent Pinchart Date: Sun Aug 10 04:29:54 2025 +0300 media: pci: ivtv: Don't create fake v4l2_fh [ Upstream commit cc6e8d1ccea792d8550428e0831e3a35b0ccfddc ] The ivtv driver has a structure named ivtv_open_id that models an open file handle for the device. It embeds a v4l2_fh instance for file handles that correspond to a V4L2 video device, and stores a pointer to that v4l2_fh in struct ivtv_stream to identify which open file handle owns a particular stream. In addition to video devices, streams can be owned by ALSA PCM devices. Those devices do not make use of the v4l2_fh instance for obvious reasons, but the snd_ivtv_pcm_capture_open() function still initializes a "fake" v4l2_fh for the sole purpose of using it as an open file handle identifier. The v4l2_fh is not properly destroyed when the ALSA PCM device is closed, leading to possible resource leaks. Fortunately, the v4l2_fh instance pointed to by ivtv_stream is not accessed, only the pointer value is used for comparison. Replace it with a pointer to the ivtv_open_id structure that embeds the v4l2_fh, and don't initialize the v4l2_fh for ALSA PCM devices. Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0b240c76defc94893e6fb15504d291294655034b Author: Geoffrey McRae Date: Tue Jul 8 13:53:40 2025 +1000 drm/amdkfd: return -ENOTTY for unsupported IOCTLs [ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ] Some kfd ioctls may not be available depending on the kernel version the user is running, as such we need to report -ENOTTY so userland can determine the cause of the ioctl failure. Signed-off-by: Geoffrey McRae Acked-by: Alex Deucher Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bc1ca06998c1cb6d58e02e0f28c032ec88eb45dd Author: Ping-Ke Shih Date: Thu Jul 24 08:48:15 2025 +0800 wifi: rtw88: sdio: use indirect IO for device registers before power-on [ Upstream commit 58de1f91e033b1fface8d8948984583125f93736 ] The register REG_SYS_CFG1 is used to determine chip basic information as arguments of following flows, such as download firmware and load PHY parameters, so driver read the value early (before power-on). However, the direct IO is disallowed before power-on, or it causes wrong values, which driver recognizes a chip as a wrong type RF_1T1R, but actually RF_2T2R, causing driver warns: rtw88_8822cs mmc1:0001:1: unsupported rf path (1) Fix it by using indirect IO before power-on. Reported-by: Piotr Oniszczuk Closes: https://lore.kernel.org/linux-wireless/699C22B4-A3E3-4206-97D0-22AB3348EBF6@gmail.com/T/#t Suggested-by: Bitterblue Smith Tested-by: Piotr Oniszczuk Reviewed-by: Martin Blumenstingl Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250724004815.7043-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 8ebef59d029453bcb93f5518657758e2df98eb38 Author: Ping-Ke Shih Date: Mon Aug 4 09:22:33 2025 +0800 wifi: rtw89: print just once for unknown C2H events [ Upstream commit 7e1c44fe4c2e1e01fa47d9490893d95309a99687 ] When driver receives new or unknown C2H events, it print out messages repeatedly once events are received, like rtw89_8922ae 0000:81:00.0: PHY c2h class 2 not support To avoid the thousands of messages, use rtw89_info_once() instead. Also, print out class/func for unknown (undefined) class. Reported-by: Sean Anderson Closes: https://lore.kernel.org/linux-wireless/20250729204437.164320-1-sean.anderson@linux.dev/ Reviewed-by: Sean Anderson Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20250804012234.8913-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit b0faf30921d55b382fb7b332ad03bd387d2c9f31 Author: Wake Liu Date: Sat Aug 9 14:20:13 2025 +0800 selftests/net: Ensure assert() triggers in psock_tpacket.c [ Upstream commit bc4c0a48bdad7f225740b8e750fdc1da6d85e1eb ] The get_next_frame() function in psock_tpacket.c was missing a return statement in its default switch case, leading to a compiler warning. This was caused by a `bug_on(1)` call, which is defined as an `assert()`, being compiled out because NDEBUG is defined during the build. Instead of adding a `return NULL;` which would silently hide the error and could lead to crashes later, this change restores the original author's intent. By adding `#undef NDEBUG` before including , we ensure the assertion is active and will cause the test to abort if this unreachable code is ever executed. Signed-off-by: Wake Liu Link: https://patch.msgid.link/20250809062013.2407822-1-wakel@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f58cae7ccf94e7959fff9c16f23d89c3b9585c3 Author: Wake Liu Date: Thu Aug 7 16:09:32 2025 +0800 selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8 [ Upstream commit c36748e8733ef9c5f4cd1d7c4327994e5b88b8df ] The `__WORDSIZE` macro, defined in the non-standard `` header, is a GNU extension and not universally available with all toolchains, such as Clang when used with musl libc. This can lead to build failures in environments where this header is missing. The intention of the code is to determine the bit width of a C `long`. Replace the non-portable `__WORDSIZE` with the standard and portable `sizeof(long) * 8` expression to achieve the same result. This change also removes the inclusion of the now-unused `` header. Signed-off-by: Wake Liu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 59f223bace9fe8bd8dc800c3fea1dc6518a3f5ce Author: Marcos Del Sol Vives Date: Sun Jul 6 01:32:08 2025 +0200 PCI: Disable MSI on RDC PCI to PCIe bridges [ Upstream commit ebc7086b39e5e4f3d3ca82caaea20538c9b62d42 ] RDC PCI to PCIe bridges, present on Vortex86DX3 and Vortex86EX2 SoCs, do not support MSIs. If enabled, interrupts generated by PCIe devices never reach the processor. I have contacted the manufacturer (DM&P) and they confirmed that PCI MSIs need to be disabled for them. Signed-off-by: Marcos Del Sol Vives Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250705233209.721507-1-marcos@orca.pet Signed-off-by: Sasha Levin commit 1ffd2a2cdbbbbca72237f22032535ee8059cd55b Author: TungYu Lu Date: Tue Jul 15 16:56:59 2025 +0800 drm/amd/display: Wait until OTG enable state is cleared [ Upstream commit e7496c15d830689cc4fc666b976c845ed2c5ed28 ] [Why] Customer reported an issue that OS starts and stops device multiple times during driver installation. Frequently disabling and enabling OTG may prevent OTG from being safely disabled and cause incorrect configuration upon the next enablement. [How] Add a wait until OTG_CURRENT_MASTER_EN_STATE is cleared as a short term solution. Reviewed-by: Dillon Varone Signed-off-by: TungYu Lu Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc17bb647d41601ca7b23ddd01413a84a00a56f2 Author: Danny Wang Date: Thu Jul 24 13:58:21 2025 +0800 drm/amd/display: Reset apply_eamless_boot_optimization when dpms_off [ Upstream commit ad335b5fc9ed1cdeb33fbe97d2969b3a2eedaf3e ] [WHY&HOW] The user closed the lid while the system was powering on and opened it again before the “apply_seamless_boot_optimization” was set to false, resulting in the eDP remaining blank. Reset the “apply_seamless_boot_optimization” to false when dpms off. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Danny Wang Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3db7394212d02efab166fad24aa8e17a7da755f6 Author: Terry Cheong Date: Wed Jul 23 17:20:11 2025 +0800 ASoC: mediatek: Use SND_JACK_AVOUT for HDMI/DP jacks [ Upstream commit 8ed2dca4df2297177e0edcb7e0c72ef87f3fd81a ] The SND_JACK_AVOUT is a more specific jack type for HDMI and DisplayPort. Updatae the MediaTek drivers to use such jack type, allowing system to determine the device type based on jack event. Signed-off-by: Terry Cheong Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20250723-mtk-hdmi-v1-1-4ff945eb6136@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 630debf099baced9cf55fc7c71d1def5e8265d30 Author: Seyediman Seyedarab Date: Thu Jul 24 15:59:13 2025 -0400 drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf() [ Upstream commit 6510b62fe9303aaf48ff136ff69186bcfc32172d ] snprintf() returns the number of characters that *would* have been written, which can overestimate how much you actually wrote to the buffer in case of truncation. That leads to 'data += this' advancing the pointer past the end of the buffer and size going negative. Switching to scnprintf() prevents potential buffer overflows and ensures consistent behavior when building the output string. Signed-off-by: Seyediman Seyedarab Link: https://lore.kernel.org/r/20250724195913.60742-1-ImanDevel@gmail.com Signed-off-by: Danilo Krummrich Signed-off-by: Sasha Levin commit 86ddaac6f06fc47858cca32ff30910d093fada1d Author: Sathishkumar S Date: Tue Aug 5 21:28:25 2025 +0530 drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff [ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ] Acquire jpeg_pg_lock before changes to jpeg power state and release it after power off from idle work handler. Signed-off-by: Sathishkumar S Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8a379fd23e802d3ccc8a62f06ba5e1e6ddb71df5 Author: Lijo Lazar Date: Fri Jul 11 12:18:04 2025 +0530 drm/amd/pm: Use cached metrics data on arcturus [ Upstream commit 2f3b1ccf83be83a3330e38194ddfd1a91fec69be ] Cached metrics data validity is 1ms on arcturus. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b024916b365de6badecd1c9c01e62e8feab8c9c8 Author: Lijo Lazar Date: Fri Jul 11 12:15:45 2025 +0530 drm/amd/pm: Use cached metrics data on aldebaran [ Upstream commit e87577ef6daa0cfb10ca139c720f0c57bd894174 ] Cached metrics data validity is 1ms on aldebaran. It's not reasonable for any client to query gpu_metrics at a faster rate and constantly interrupt PMFW. Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7abc99984f8b27411e0905182900398479060039 Author: Paul Hsieh Date: Wed Jul 23 11:51:42 2025 +0800 drm/amd/display: update dpp/disp clock from smu clock table [ Upstream commit 2e72fdba8a32ce062a86571edff4592710c26215 ] [Why] The reason some high-resolution monitors fail to display properly is that this platform does not support sufficiently high DPP and DISP clock frequencies [How] Update DISP and DPP clocks from the smu clock table then DML can filter these mode if not support. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Paul Hsieh Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1b18a6fd7dd92f28a517b5eb7ecae567fbc460ed Author: Alex Deucher Date: Fri Jun 27 10:10:31 2025 -0400 drm/amd/display: add more cyan skillfish devices [ Upstream commit 3cf06bd4cf2512d564fdb451b07de0cebe7b138d ] Add PCI IDs to support display probe for cyan skillfish family of SOCs. Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 51ece8d2a98ad6761a8a7b7f52ce68475ff19b91 Author: Xiang Liu Date: Wed Jul 30 11:07:43 2025 +0800 drm/amdgpu: Skip poison aca bank from UE channel [ Upstream commit 8e8e08c831f088ed581444c58a635c49ea1222ab ] Avoid GFX poison consumption errors logged when fatal error occurs. Signed-off-by: Xiang Liu Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit eb553214dc9d5923ff3d72a9fabc2d9343dc29da Author: Meng Li Date: Fri May 9 13:44:24 2025 +0800 drm/amd/amdgpu: Release xcp drm memory after unplug [ Upstream commit e6c2b0f23221ed43c4cc6f636e9ab7862954d562 ] Add a new API amdgpu_xcp_drm_dev_free(). After unplug xcp device, need to release xcp drm memory etc. Co-developed-by: Jiang Liu Signed-off-by: Jiang Liu Signed-off-by: Meng Li Acked-by: Alex Deucher Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 55fadcd04ed2ec36f889e1fc573051b6a6bda1bc Author: Ce Sun Date: Sun Jul 27 12:06:55 2025 +0800 drm/amdgpu: Avoid rma causes GPU duplicate reset [ Upstream commit 21c0ffa612c98bcc6dab5bd9d977a18d565ee28e ] Try to ensure poison creation handle is completed in time to set device rma value. Signed-off-by: Ce Sun Signed-off-by: Stanley.Yang Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 99428bd6123d5676209dfb1d7a8f176cc830b665 Author: Maarten Lankhorst Date: Tue Jul 15 17:20:58 2025 +0200 drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test. [ Upstream commit 1cda3c755bb7770be07d75949bb0f45fb88651f6 ] I saw an oops in xe_gem_fault when running the xe-fast-feedback testlist against the realtime kernel without debug options enabled. The panic happens after core_hotunplug unbind-rebind finishes. Presumably what happens is that a process mmaps, unlocks because of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left, causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, since there was nothing left to populate, and then oopses in "mem_type_is_vram(tbo->resource->mem_type)" because tbo->resource is NULL. It's convoluted, but fits the data and explains the oops after the test exits. Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20250715152057.23254-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit efffbbbe80bce4a39a786fd773630a463a913111 Author: John Harrison Date: Fri Jul 25 19:43:37 2025 -0700 drm/xe/guc: Add more GuC load error status codes [ Upstream commit 45fbb51050e72723c2bdcedc1ce32305256c70ed ] The GuC load process will abort if certain status codes (which are indicative of a fatal error) are reported. Otherwise, it keeps waiting until the 'success' code is returned. New error codes have been added in recent GuC releases, so add support for aborting on those as well. v2: Shuffle HWCONFIG_START to the front of the switch to keep the ordering as per the enum define for clarity (review feedback by Jonathan). Also add a description for the basic 'invalid init data' code which was missing. Signed-off-by: John Harrison Reviewed-by: Stuart Summers Link: https://lore.kernel.org/r/20250726024337.4056272-1-John.C.Harrison@Intel.com Signed-off-by: Sasha Levin commit ec775767835147944ab26fef2ef4e184b447e4cd Author: Michael Strauss Date: Wed Mar 19 18:04:01 2025 -0400 drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration [ Upstream commit e3419e1e44b87d4176fb98679a77301b1ca40f63 ] [WHY] In the worst case, AUX intra-hop done can take hundreds of milliseconds as each retimer in a link might have to wait a full AUX_RD_INTERVAL to send LT abort downstream. [HOW] Wait 300ms for each retimer in a link to allow time to propagate a LT abort without infinitely waiting on intra-hop done. For no-retimer case, keep the max duration at 10ms. Reviewed-by: Wenjing Liu Signed-off-by: Michael Strauss Signed-off-by: Ivan Lipski Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 021fe59351fb2119579bf43732d62b7193c82a7c Author: Michael Strauss Date: Wed Feb 12 14:08:08 2025 -0500 drm/amd/display: Move setup_stream_attribute [ Upstream commit 2681bf4ae8d24df950138b8c9ea9c271cd62e414 ] [WHY] If symclk RCO is enabled, stream encoder may not be receiving an ungated clock by the time we attempt to set stream attributes when setting dpms on. Since the clock is gated, register writes to the stream encoder fail. [HOW] Move set_stream_attribute call into enable_stream, just after the point where symclk32_se is ungated. Logically there is no need to set stream attributes as early as is currently done in link_set_dpms_on, so this should have no impact beyond the RCO fix. Reviewed-by: Ovidiu (Ovi) Bunea Signed-off-by: Michael Strauss Signed-off-by: Ivan Lipski Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a72b486d41352168cc4ce539812ce8955acd341b Author: Sathishkumar S Date: Sun Jul 13 01:28:02 2025 +0530 drm/amdgpu: Check vcn sram load return value [ Upstream commit faab5ea0836733ef1c8e83cf6b05690a5c9066be ] Log an error when vcn sram load fails in indirect mode and return the same error value. Signed-off-by: Sathishkumar S Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9cb03fb9ec46e4e234fb6fe4d2a4eb92f3faf24c Author: Tao Zhou Date: Wed Jul 2 16:16:02 2025 +0800 drm/amdgpu: add range check for RAS bad page address [ Upstream commit 2b17c240e8cd9ac61d3c82277fbed27edad7f002 ] Exclude invalid bad pages. Signed-off-by: Tao Zhou Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 77e69d00a457f55a5580d8833c5bdacee0009a51 Author: Clay King Date: Mon Jul 7 13:21:30 2025 -0400 drm/amd/display: ensure committing streams is seamless [ Upstream commit ca74cc428f2b9d0170c56b473dbcfd7fa01daf2d ] [Why] When transitioning between topologies such as multi-display to single display ODM 2:1, pipes might not be freed before use. [How] In dc_commit_streams, commit an additional, minimal transition if original transition is not seamless to ensure pipes are freed. Reviewed-by: Alvin Lee Signed-off-by: Clay King Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 069dc0232ae4a7140cd5e55dc1ad888e47d70159 Author: Aurabindo Pillai Date: Wed Jun 25 10:11:22 2025 -0400 drm/amd/display: fix condition for setting timing_adjust_pending [ Upstream commit 1a6a3374ecb9899ccf0d209b5783a796bdba8cec ] timing_adjust_pending is used to defer certain programming sequences when OTG timing is about to be changed, like with VRR. Insufficient checking for timing change in this case caused a regression which reduces PSR Replay residency. Reviewed-by: Tom Chung Signed-off-by: Aurabindo Pillai Signed-off-by: Robin Chen Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 42e7440ac65c11a68f4c2f8bfdf806d3ef22d6f7 Author: Ilpo Järvinen Date: Mon Sep 15 14:29:36 2025 +0300 mfd: intel-lpss: Add Intel Wildcat Lake LPSS PCI IDs [ Upstream commit c91a0e4e549d0457c61f2199fcd84d699400bee1 ] Add Intel Wildcat Lake PCI IDs. Signed-off-by: Ilpo Järvinen Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250915112936.10696-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 67e8a4d0532330cb8ac21a8400efb9c6001e424f Author: Bastien Curutchet Date: Wed Aug 20 16:21:13 2025 +0200 mfd: core: Increment of_node's refcount before linking it to the platform device [ Upstream commit 5f4bbee069836e51ed0b6d7e565a292f070ababc ] When an MFD device is added, a platform_device is allocated. If this device is linked to a DT description, the corresponding OF node is linked to the new platform device but the OF node's refcount isn't incremented. As of_node_put() is called during the platform device release, it leads to a refcount underflow. Call of_node_get() to increment the OF node's refcount when the node is linked to the newly created platform device. Signed-off-by: Bastien Curutchet Link: https://lore.kernel.org/r/20250820-mfd-refcount-v1-1-6dcb5eb41756@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 933fc45da2777c232f6ec11c0cd8d224ed6f0ed8 Author: Jens Kehne Date: Mon Aug 4 15:37:54 2025 +0200 mfd: da9063: Split chip variant reading in two bus transactions [ Upstream commit 9ac4890ac39352ccea132109e32911495574c3ec ] We observed the initial probe of the da9063 failing in da9063_get_device_type in about 30% of boots on a Xilinx ZynqMP based board. The problem originates in da9063_i2c_blockreg_read, which uses a single bus transaction to turn the register page and then read a register. On the bus, this should translate to a write to register 0, followed by a read to the target register, separated by a repeated start. However, we found that after the write to register 0, the controller sometimes continues directly with the register address of the read request, without sending the chip address or a repeated start in between, which makes the read request invalid. To fix this, separate turning the page and reading the register into two separate transactions. This brings the initialization code in line with the rest of the driver, which uses register maps (which to my knowledge do not use repeated starts after turning the page). This has been included in our kernel for several months and was recently included in a shipped product. For us, it reliably fixes the issue, and we have not observed any new issues. While the underlying problem is probably with the i2c controller or its driver, I still propose a change here in the interest of robustness: First, I'm not sure this issue can be fixed on the controller side, since there are other issues related to repeated start which can't (AR# 60695, AR# 61664). Second, similar problems might exist with other controllers. Signed-off-by: Jens Kehne Link: https://lore.kernel.org/r/20250804133754.3496718-1-jens.kehne@agilent.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 3735ee5c21e0f765009d4acda6081afe86801c32 Author: Arnd Bergmann Date: Thu Aug 7 09:19:28 2025 +0200 mfd: madera: Work around false-positive -Wininitialized warning [ Upstream commit 364752aa0c6ab0a06a2d5bfdb362c1ca407f1a30 ] clang-21 warns about one uninitialized variable getting dereferenced in madera_dev_init: drivers/mfd/madera-core.c:739:10: error: variable 'mfd_devs' is uninitialized when used here [-Werror,-Wuninitialized] 739 | mfd_devs, n_devs, | ^~~~~~~~ drivers/mfd/madera-core.c:459:33: note: initialize the variable 'mfd_devs' to silence this warning 459 | const struct mfd_cell *mfd_devs; | ^ | = NULL The code is actually correct here because n_devs is only nonzero when mfd_devs is a valid pointer, but this is impossible for the compiler to see reliably. Change the logic to check for the pointer as well, to make this easier for the compiler to follow. Signed-off-by: Arnd Bergmann Reviewed-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20250807071932.4085458-1-arnd@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 38f73c37cf1ee3e3b3cf32f70fe34514ff2f4ae4 Author: Alexander Stein Date: Fri Jul 25 09:11:50 2025 +0200 mfd: stmpe-i2c: Add missing MODULE_LICENSE [ Upstream commit 00ea54f058cd4cb082302fe598cfe148e0aadf94 ] This driver is licensed GPL-2.0-only, so add the corresponding module flag. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250725071153.338912-3-alexander.stein@ew.tq-group.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 6dc754d517b4702acbcbe1c30a971542e5c795e5 Author: Alexander Stein Date: Fri Jul 25 09:07:48 2025 +0200 mfd: stmpe: Remove IRQ domain upon removal [ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ] The IRQ domain is (optionally) added during stmpe_probe, but never removed. Add the call to stmpe_remove. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20250725070752.338376-1-alexander.stein@ew.tq-group.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 634eaa0614ad1f859b0153b10159ef250acc2f5c Author: Len Brown Date: Fri Sep 19 15:56:46 2025 -0400 tools/power x86_energy_perf_policy: Prefer driver HWP limits [ Upstream commit 2734fdbc9bb8a3aeb309ba0d62212d7f53f30bc7 ] When we are successful in using cpufreq min/max limits, skip setting the raw MSR limits entirely. This is necessary to avoid undoing any modification that the cpufreq driver makes to our sysfs request. eg. intel_pstate may take our request for a limit that is valid according to HWP.CAP.MIN/MAX and clip it to be within the range available in PLATFORM_INFO. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit ece6d9d5125e7c270813056fb486d247e64d3147 Author: Len Brown Date: Fri Sep 19 14:07:02 2025 -0400 tools/power x86_energy_perf_policy: Enhance HWP enable [ Upstream commit c97c057d357c4b39b153e9e430bbf8976e05bd4e ] On enabling HWP, preserve the reserved bits in MSR_PM_ENABLE. Also, skip writing the MSR_PM_ENABLE if HWP is already enabled. Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 4535b7ec16b4bd77168119788f5252886fb1bec8 Author: Kaushlendra Kumar Date: Wed Aug 13 12:32:08 2025 +0530 tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage [ Upstream commit 62127655b7ab7b8c2997041aca48a81bf5c6da0c ] The fopen_or_die() function was previously hardcoded to open files in read-only mode ("r"), ignoring the mode parameter passed to it. This patch corrects fopen_or_die() to use the provided mode argument, allowing for flexible file access as intended. Additionally, the call to fopen_or_die() in err_on_hypervisor() incorrectly used the mode "ro", which is not a valid fopen mode. This is fixed to use the correct "r" mode. Signed-off-by: Kaushlendra Kumar Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 1dee521b9412f19c6d7c2190a4def7474de8c4f4 Author: Mykyta Yatsenko Date: Thu Sep 25 22:52:30 2025 +0100 selftests/bpf: Fix flaky bpf_cookie selftest [ Upstream commit 105eb5dc74109a9f53c2f26c9a918d9347a73595 ] bpf_cookie can fail on perf_event_open(), when it runs after the task_work selftest. The task_work test causes perf to lower sysctl_perf_event_sample_rate, and bpf_cookie uses sample_freq, which is validated against that sysctl. As a result, perf_event_open() rejects the attr if the (now tighter) limit is exceeded. >From perf_event_open(): if (attr.freq) { if (attr.sample_freq > sysctl_perf_event_sample_rate) return -EINVAL; } else { if (attr.sample_period & (1ULL << 63)) return -EINVAL; } Switch bpf_cookie to use sample_period, which is not checked against sysctl_perf_event_sample_rate. Signed-off-by: Mykyta Yatsenko Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250925215230.265501-1-mykyta.yatsenko5@gmail.com Signed-off-by: Sasha Levin commit 02e73f9f561480364e44f4cc23a80e990f859400 Author: Kaushlendra Kumar Date: Wed Sep 17 10:38:20 2025 +0530 tools/cpupower: Fix incorrect size in cpuidle_state_disable() [ Upstream commit 23199d2aa6dcaf6dd2da772f93d2c94317d71459 ] Fix incorrect size parameter passed to cpuidle_state_write_file() in cpuidle_state_disable(). The function was incorrectly using sizeof(disable) which returns the size of the unsigned int variable (4 bytes) instead of the actual length of the string stored in the 'value' buffer. Since 'value' is populated with snprintf() to contain the string representation of the disable value, we should use the length returned by snprintf() to get the correct string length for writing to the sysfs file. This ensures the correct number of bytes is written to the cpuidle state disable file in sysfs. Link: https://lore.kernel.org/r/20250917050820.1785377-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit e913f379acfaa5965a4739ed0d18bb1895a8000e Author: Armin Wolf Date: Wed Sep 17 20:10:33 2025 +0200 hwmon: (dell-smm) Remove Dell Precision 490 custom config data [ Upstream commit ddb61e737f04e3c6c8299c1e00bf17a42a7f05cf ] It turns out the second fan on the Dell Precision 490 does not really support I8K_FAN_TURBO. Setting the fan state to 3 enables automatic fan control, just like on the other two fans. The reason why this was misinterpreted as turbo mode was that the second fan normally spins faster in automatic mode than in the previous fan states. Yet when in state 3, the fan speed reacts to heat exposure, exposing the automatic mode setting. Link: https://github.com/lm-sensors/lm-sensors/pull/383 Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20250917181036.10972-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 527fbd192c0203f0eb2b8c2ac981318d373bfb61 Author: Ben Copeland Date: Tue Sep 23 21:26:56 2025 +0200 hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex [ Upstream commit 584d55be66ef151e6ef9ccb3dcbc0a2155559be1 ] Some motherboards require more time to acquire the ACPI mutex, causing "Failed to acquire mutex" messages to appear in the kernel log. Increase the timeout from 500ms to 800ms to accommodate these cases. Signed-off-by: Ben Copeland Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20250923192935.11339-3-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 945d73ef5c9f3ee4f3622260f1516813b1c9e4c6 Author: Jiri Olsa Date: Tue Sep 16 23:52:57 2025 +0200 uprobe: Do not emulate/sstep original instruction when ip is changed [ Upstream commit 4363264111e1297fa37aa39b0598faa19298ecca ] If uprobe handler changes instruction pointer we still execute single step) or emulate the original instruction and increment the (new) ip with its length. This makes the new instruction pointer bogus and application will likely crash on illegal instruction execution. If user decided to take execution elsewhere, it makes little sense to execute the original instruction, so let's skip it. Acked-by: Oleg Nesterov Acked-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20250916215301.664963-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a8576f1e80d99c9aa7abad0e28ad8c51f4fe6362 Author: Alistair Francis Date: Tue Sep 2 13:52:11 2025 +1000 nvme: Use non zero KATO for persistent discovery connections [ Upstream commit 2e482655019ab6fcfe8865b62432c6d03f0b5f80 ] The NVMe Base Specification 2.1 states that: """ A host requests an explicit persistent connection ... by specifying a non-zero Keep Alive Timer value in the Connect command. """ As such if we are starting a persistent connection to a discovery controller and the KATO is currently 0 we need to update KATO to a non zero value to avoid continuous timeouts on the target. Signed-off-by: Alistair Francis Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit a7ced9d338c7bdce3194eb2ea21ead16b92368f4 Author: Amery Hung Date: Mon Sep 22 16:33:49 2025 -0700 bpf: Clear pfmemalloc flag when freeing all fragments [ Upstream commit 8f12d1137c2382c80aada8e05d7cc650cd4e403c ] It is possible for bpf_xdp_adjust_tail() to free all fragments. The kfunc currently clears the XDP_FLAGS_HAS_FRAGS bit, but not XDP_FLAGS_FRAGS_PF_MEMALLOC. So far, this has not caused a issue when building sk_buff from xdp_buff since all readers of xdp_buff->flags use the flag only when there are fragments. Clear the XDP_FLAGS_FRAGS_PF_MEMALLOC bit as well to make the flags correct. Signed-off-by: Amery Hung Signed-off-by: Martin KaFai Lau Reviewed-by: Maciej Fijalkowski Link: https://patch.msgid.link/20250922233356.3356453-2-ameryhung@gmail.com Signed-off-by: Sasha Levin commit e628b0524b37840b821ce69c4bd9ac4d0a5ff7ed Author: Chenghao Duan Date: Mon Sep 22 14:22:44 2025 +0800 riscv: bpf: Fix uninitialized symbol 'retval_off' [ Upstream commit d0bf7cd5df18466d969bb60e8890b74cf96081ca ] In the __arch_prepare_bpf_trampoline() function, retval_off is only meaningful when save_ret is true, so the current logic is correct. However, in the original logic, retval_off is only initialized under certain conditions; for example, in the fmod_ret logic, the compiler is not aware that the flags of the fmod_ret program (prog) have set BPF_TRAMP_F_CALL_ORIG, which results in an uninitialized symbol compilation warning. So initialize retval_off unconditionally to fix it. Signed-off-by: Chenghao Duan Reviewed-by: Pu Lehui Link: https://lore.kernel.org/r/20250922062244.822937-2-duanchenghao@kylinos.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 56ac639d6fa6fbb99caee74ee1c7276fc9bb47ed Author: Yu Kuai Date: Tue Sep 23 15:55:20 2025 +0800 blk-cgroup: fix possible deadlock while configuring policy [ Upstream commit 5d726c4dbeeddef612e6bed27edd29733f4d13af ] Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO. Signed-off-by: Yu Kuai Reviewed-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8cc561dd9d02f1753ae34dfdd565662828be9a9d Author: Markus Stockhausen Date: Mon Aug 4 04:03:27 2025 -0400 clocksource/drivers/timer-rtl-otto: Do not interfere with interrupts [ Upstream commit c445bffbf28f721e05d0ce06895045fc62aaff7c ] During normal operation the timers are reprogrammed including an interrupt acknowledgement. This has no effect as the whole timer is setup from scratch afterwards. Especially in an interrupt this has already been done by rttm_timer_interrupt(). Change the behaviour as follows: - Use rttm_disable_timer() during reprogramming - Keep rttm_stop_timer() for all other use cases. Downstream has already tested and confirmed a patch. See https://github.com/openwrt/openwrt/pull/19468 https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3788 Signed-off-by: Markus Stockhausen Signed-off-by: Daniel Lezcano Tested-by: Stephen Howell Tested-by: Bjørn Mork Link: https://lore.kernel.org/r/20250804080328.2609287-4-markus.stockhausen@gmx.de Signed-off-by: Sasha Levin commit d0e217b33d42bfe52ef7ef447916a23a586e6e5c Author: Markus Stockhausen Date: Mon Aug 4 04:03:25 2025 -0400 clocksource/drivers/timer-rtl-otto: Work around dying timers [ Upstream commit e7a25106335041aeca4fdf50a84804c90142c886 ] The OpenWrt distribution has switched from kernel longterm 6.6 to 6.12. Reports show that devices with the Realtek Otto switch platform die during operation and are rebooted by the watchdog. Sorting out other possible reasons the Otto timer is to blame. The platform currently consists of 4 targets with different hardware revisions. It is not 100% clear which devices and revisions are affected. Analysis shows: A more aggressive sched/deadline handling leads to more timer starts with small intervals. This increases the bug chances. See https://marc.info/?l=linux-kernel&m=175276556023276&w=2 Focusing on the real issue a hardware limitation on some devices was found. There is a minimal chance that a timer ends without firing an interrupt if it is reprogrammed within the 5us before its expiration time. Work around this issue by introducing a bounce() function. It restarts the timer directly before the normal restart functions as follows: - Stop timer - Restart timer with a slow frequency. - Target time will be >5us - The subsequent normal restart is outside the critical window Downstream has already tested and confirmed a patch. See https://github.com/openwrt/openwrt/pull/19468 https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/3788 Signed-off-by: Markus Stockhausen Signed-off-by: Daniel Lezcano Tested-by: Stephen Howell Tested-by: Bjørn Mork Link: https://lore.kernel.org/r/20250804080328.2609287-2-markus.stockhausen@gmx.de Signed-off-by: Sasha Levin commit 355c1a72cb39a1e3c17e43aeb4d0ee960f068c98 Author: Daniel Lezcano Date: Mon Aug 4 17:23:19 2025 +0200 clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel [ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ] The driver uses the raw_readl() and raw_writel() functions. Those are not for MMIO devices. Replace them with readl() and writel() [ dlezcano: Fixed typo in the subject s/reald/readl/ ] Signed-off-by: Daniel Lezcano Acked-by: Arnd Bergmann Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20250804152344.1109310-2-daniel.lezcano@linaro.org Signed-off-by: Sasha Levin commit c9172cced19bf2a84f3563817076326e71e7cca3 Author: Chen Pei Date: Sat Sep 13 15:08:15 2025 +0800 ACPI: SPCR: Support Precise Baud Rate field [ Upstream commit 4d330fe54145ecfbb657ac01a554fdedf3c1927e ] The Microsoft Serial Port Console Redirection (SPCR) specification revision 1.09 comprises additional field: Precise Baud Rate [1]. It is used to describe non-traditional baud rates (such as those used by high-speed UARTs). It contains a specific non-zero baud rate which overrides the value of the Configured Baud Rate field. If this field is zero or not present, Configured Baud Rate is used. Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [1] Signed-off-by: Chen Pei Link: https://patch.msgid.link/20250913070815.16758-1-cp0613@linux.alibaba.com [ rjw: Corrected typo in the subject ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f25411c9d87bdc8a35eecfbac525a081677470ff Author: Biju Das Date: Sun Sep 21 12:26:46 2025 +0100 spi: rpc-if: Add resume support for RZ/G3E [ Upstream commit ad4728740bd68d74365a43acc25a65339a9b2173 ] On RZ/G3E using PSCI, s2ram powers down the SoC. After resume, reinitialize the hardware for SPI operations. Signed-off-by: Biju Das Link: https://patch.msgid.link/20250921112649.104516-3-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7163513c1c7028652194f62fb86802a5f4eaa363 Author: Yonghong Song Date: Fri Sep 19 21:58:05 2025 -0700 selftests/bpf: Fix selftest verifier_arena_large failure [ Upstream commit 5a427fddec5e76360725a0f03df3a2a003efbe2e ] With latest llvm22, I got the following verification failure: ... ; int big_alloc2(void *ctx) @ verifier_arena_large.c:207 0: (b4) w6 = 1 ; R6_w=1 ... ; if (err) @ verifier_arena_large.c:233 53: (56) if w6 != 0x0 goto pc+62 ; R6=0 54: (b7) r7 = -4 ; R7_w=-4 55: (18) r8 = 0x7f4000000000 ; R8_w=scalar() 57: (bf) r9 = addr_space_cast(r8, 0, 1) ; R8_w=scalar() R9_w=arena 58: (b4) w6 = 5 ; R6_w=5 ; pg = page[i]; @ verifier_arena_large.c:238 59: (bf) r1 = r7 ; R1_w=-4 R7_w=-4 60: (07) r1 += 4 ; R1_w=0 61: (79) r2 = *(u64 *)(r9 +0) ; R2_w=scalar() R9_w=arena ; if (*pg != i) @ verifier_arena_large.c:239 62: (bf) r3 = addr_space_cast(r2, 0, 1) ; R2_w=scalar() R3_w=arena 63: (71) r3 = *(u8 *)(r3 +0) ; R3_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 64: (5d) if r1 != r3 goto pc+51 ; R1_w=0 R3_w=0 ; bpf_arena_free_pages(&arena, (void __arena *)pg, 2); @ verifier_arena_large.c:241 65: (18) r1 = 0xff11000114548000 ; R1_w=map_ptr(map=arena,ks=0,vs=0) 67: (b4) w3 = 2 ; R3_w=2 68: (85) call bpf_arena_free_pages#72675 ; 69: (b7) r1 = 0 ; R1_w=0 ; page[i + 1] = NULL; @ verifier_arena_large.c:243 70: (7b) *(u64 *)(r8 +8) = r1 R8 invalid mem access 'scalar' processed 61 insns (limit 1000000) max_states_per_insn 0 total_states 6 peak_states 6 mark_read 2 ============= #489/5 verifier_arena_large/big_alloc2:FAIL The main reason is that 'r8' in insn '70' is not an arena pointer. Further debugging at llvm side shows that llvm commit ([1]) caused the failure. For the original code: page[i] = NULL; page[i + 1] = NULL; the llvm transformed it to something like below at source level: __builtin_memset(&page[i], 0, 16) Such transformation prevents llvm BPFCheckAndAdjustIR pass from generating proper addr_space_cast insns ([2]). Adding support in llvm BPFCheckAndAdjustIR pass should work, but not sure that such a pattern exists or not in real applications. At the same time, simply adding a memory barrier between two 'page' assignment can fix the issue. [1] https://github.com/llvm/llvm-project/pull/155415 [2] https://github.com/llvm/llvm-project/pull/84410 Cc: Eduard Zingerman Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20250920045805.3288551-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3b4222494489f6d4b8705a496dab03384b7ca998 Author: Pranav Tyagi Date: Mon Sep 15 23:51:54 2025 +0530 futex: Don't leak robust_list pointer on exec race [ Upstream commit 6b54082c3ed4dc9821cdf0edb17302355cc5bb45 ] sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials. Suggested-by: Jann Horn Signed-off-by: Pranav Tyagi Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/linux-fsdevel/1477863998-3298-5-git-send-email-jann@thejh.net/ Link: https://github.com/KSPP/linux/issues/119 Signed-off-by: Sasha Levin commit c876a729a4cd1e03c8b00a08965a7f2de1644414 Author: Rafael J. Wysocki Date: Fri Sep 19 13:22:20 2025 +0200 cpuidle: Fail cpuidle device registration if there is one already [ Upstream commit 7b1b7961170e4fcad488755e5ffaaaf9bd527e8f ] Refuse to register a cpuidle device if the given CPU has a cpuidle device already and print a message regarding it. Without this, an attempt to register a new cpuidle device without unregistering the existing one leads to the removal of the existing cpuidle device without removing its sysfs interface. Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7e7d5bfbbec0e9317dfb45cd9d4f9b21e824a8af Author: Tom Stellard Date: Wed Sep 17 11:38:47 2025 -0700 bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21 [ Upstream commit 5612ea8b554375d45c14cbb0f8ea93ec5d172891 ] This fixes the build with -Werror -Wall. btf_dumper.c:71:31: error: variable 'finfo' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 71 | info.func_info = ptr_to_u64(&finfo); | ^~~~~ prog.c:2294:31: error: variable 'func_info' is uninitialized when passed as a const pointer argument here [-Werror,-Wuninitialized-const-pointer] 2294 | info.func_info = ptr_to_u64(&func_info); | v2: - Initialize instead of using memset. Signed-off-by: Tom Stellard Signed-off-by: Andrii Nakryiko Acked-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20250917183847.318163-1-tstellar@redhat.com Signed-off-by: Sasha Levin commit 13276961ae6881216f3902d3e37603172529e376 Author: Fenglin Wu Date: Fri Sep 19 11:18:51 2025 +0800 power: supply: qcom_battmgr: handle charging state change notifications [ Upstream commit 41307ec7df057239aae3d0f089cc35a0d735cdf8 ] The X1E80100 battery management firmware sends a notification with code 0x83 when the battery charging state changes, such as switching between fast charge, taper charge, end of charge, or any other error charging states. The same notification code is used with bit[8] set when charging stops because the charge control end threshold is reached. Additionally, a 2-bit value is included in bit[10:9] with the same code to indicate the charging source capability, which is determined by the calculated power from voltage and current readings from PDOs: 2 means a strong charger over 60W, 1 indicates a weak charger, and 0 means there is no charging source. These 3-MSB [10:8] in the notification code is not much useful for now, hence just ignore them and trigger a power supply change event whenever 0x83 notification code is received. This helps to eliminate the unknown notification error messages. Reported-by: Sebastian Reichel Closes: https://lore.kernel.org/all/r65idyc4of5obo6untebw4iqfj2zteiggnnzabrqtlcinvtddx@xc4aig5abesu/ Signed-off-by: Fenglin Wu Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a4914df87fddad3af628e1c9ab74c05b7513fd0a Author: Janne Grunau Date: Thu Aug 28 16:01:22 2025 +0200 pmdomain: apple: Add "apple,t8103-pmgr-pwrstate" [ Upstream commit 442816f97a4f84cb321d3359177a3b9b0ce48a60 ] After discussion with the devicetree maintainers we agreed to not extend lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use "apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC the driver and bindings were written for. [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/ Signed-off-by: Janne Grunau Acked-by: Ulf Hansson Reviewed-by: Neal Gompa Acked-by: Rob Herring (Arm) Signed-off-by: Sven Peter Signed-off-by: Sasha Levin commit eff9be1646922a3a0d2c0dc569d82f2f041db312 Author: Kaushlendra Kumar Date: Thu Aug 28 12:00:00 2025 +0530 tools/cpupower: fix error return value in cpupower_write_sysfs() [ Upstream commit 57b100d4cf14276e0340eecb561005c07c129eb8 ] The cpupower_write_sysfs() function currently returns -1 on write failure, but the function signature indicates it should return an unsigned int. Returning -1 from an unsigned function results in a large positive value rather than indicating an error condition. Fix this by returning 0 on failure, which is more appropriate for an unsigned return type and maintains consistency with typical success/failure semantics where 0 indicates failure and non-zero indicates success (bytes written). Link: https://lore.kernel.org/r/20250828063000.803229-1-kaushlendra.kumar@intel.com Signed-off-by: Kaushlendra Kumar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ffd87e786745b366458957afa87441808d916b17 Author: Svyatoslav Ryhel Date: Tue Sep 9 10:43:04 2025 +0300 video: backlight: lp855x_bl: Set correct EPROM start for LP8556 [ Upstream commit 07c7efda24453e05951fb2879f5452b720b91169 ] According to LP8556 datasheet EPROM region starts at 0x98 so adjust value in the driver accordingly. Signed-off-by: Svyatoslav Ryhel Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250909074304.92135-2-clamor95@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 16c0240a4b30e00cfca48ea93dceb67ebcdc566c Author: Jarkko Nikula Date: Fri Aug 8 16:17:32 2025 +0300 i3c: mipi-i3c-hci-pci: Add support for Intel Wildcat Lake-U I3C [ Upstream commit d515503f3c8a8475b2f78782534aad09722904e1 ] Add I3C controller PCI IDs on Intel Wildcat Lake-U. Signed-off-by: Jarkko Nikula Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250808131732.1213227-1-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit dea5e008d5c7236bbddebf1339bf4d0153144928 Author: Kumar Kartikeya Dwivedi Date: Mon Sep 15 03:26:17 2025 +0000 bpf: Do not limit bpf_cgroup_from_id to current's namespace [ Upstream commit 2c895133950646f45e5cf3900b168c952c8dbee8 ] The bpf_cgroup_from_id kfunc relies on cgroup_get_from_id to obtain the cgroup corresponding to a given cgroup ID. This helper can be called in a lot of contexts where the current thread can be random. A recent example was its use in sched_ext's ops.tick(), to obtain the root cgroup pointer. Since the current task can be whatever random user space task preempted by the timer tick, this makes the behavior of the helper unreliable. Refactor out __cgroup_get_from_id as the non-namespace aware version of cgroup_get_from_id, and change bpf_cgroup_from_id to make use of it. There is no compatibility breakage here, since changing the namespace against which the lookup is being done to the root cgroup namespace only permits a wider set of lookups to succeed now. The cgroup IDs across namespaces are globally unique, and thus don't need to be retranslated. Reported-by: Dan Schatzberg Signed-off-by: Kumar Kartikeya Dwivedi Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20250915032618.1551762-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9950af4303942081dc8c7a5fdc3688c17c7eb6c0 Author: Daniel Wagner Date: Tue Sep 2 12:22:03 2025 +0200 nvme-fc: use lock accessing port_state and rport state [ Upstream commit 891cdbb162ccdb079cd5228ae43bdeebce8597ad ] nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46nwzgeo5ausc@uyrkdls2muwx Signed-off-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 04d17540ef51e2c291eb863ca87fd332259b2d40 Author: Daniel Wagner Date: Tue Sep 2 12:22:01 2025 +0200 nvmet-fc: avoid scheduling association deletion twice [ Upstream commit f2537be4f8421f6495edfa0bc284d722f253841d ] When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted. Reported-by: Shinichiro Kawasaki Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2ih5aregghax5@mhr7v3eryci3/ Reviewed-by: Hannes Reinecke Signed-off-by: Daniel Wagner Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 819c619cc4ec65c2b1d6c5796c166ad884747d79 Author: Amirreza Zarrabi Date: Thu Sep 11 21:07:42 2025 -0700 tee: allow a driver to allocate a tee_device without a pool [ Upstream commit 6dbcd5a9ab6cb6644e7d728521da1c9035ec7235 ] A TEE driver doesn't always need to provide a pool if it doesn't support memory sharing ioctls and can allocate memory for TEE messages in another way. Although this is mentioned in the documentation for tee_device_alloc(), it is not handled correctly. Reviewed-by: Sumit Garg Signed-off-by: Amirreza Zarrabi Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit fd39594a000127bf164d5b6d6ba760c6d7a653a0 Author: Hans de Goede Date: Fri Sep 12 22:00:17 2025 +0200 ACPICA: dispatcher: Use acpi_ds_clear_operands() in acpi_ds_call_control_method() [ Upstream commit e9dff11a7a50fcef23fe3e8314fafae6d5641826 ] When deleting the previous walkstate operand stack acpi_ds_call_control_method() was deleting obj_desc->Method.param_count operands. But Method.param_count does not necessarily match this_walk_state->num_operands, it may be either less or more. After correcting the for loop to check `i < this_walk_state->num_operands` the code is identical to acpi_ds_clear_operands(), so just outright replace the code with acpi_ds_clear_operands() to fix this. Link: https://github.com/acpica/acpica/commit/53fc0220 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b89e25efa2bd13de66eb153097fed60ec08bd72d Author: Uwe Kleine-König Date: Tue Jul 29 12:36:01 2025 +0200 pwm: pca9685: Use bulk write to atomicially update registers [ Upstream commit de5855613263b426ee697dd30224322f2e634dec ] The output of a PWM channel is configured by four register values. Write them in a single i2c transaction to ensure glitch free updates. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/bfa8c0267c9ec059d0d77f146998d564654c75ca.1753784092.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 03d4d9a1d818df59b079bbc3a6cbdd51eb2c47d9 Author: Sarthak Garg Date: Mon Sep 8 16:11:19 2025 +0530 mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card [ Upstream commit 08b68ca543ee9d5a8d2dc406165e4887dd8f170b ] For Qualcomm SoCs which needs level shifter for SD card, extra delay is seen on receiver data path. To compensate this delay enable tuning for SDR50 mode for targets which has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets with level shifter on Qualcomm SOC's. Signed-off-by: Sarthak Garg Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ebac995a8aedd5b0ddfda762efe87adca624b4d3 Author: Nikita Travkin Date: Mon Jul 21 18:28:03 2025 +0500 firmware: qcom: tzmem: disable sc7180 platform [ Upstream commit 3cc9a8cadaf66e1a53e5fee48f8bcdb0a3fd5075 ] When SHM bridge is enabled, assigning RMTFS memory causes the calling core to hang if the system is running in EL1. Disable SHM bridge on sc7180 devices to avoid that hang. Signed-off-by: Nikita Travkin Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20250721-sc7180-shm-hang-v1-1-99ad9ffeb5b4@trvn.ru Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 168b8941261d832584d1942b699c06bca82982ea Author: Svyatoslav Ryhel Date: Sat Sep 6 09:29:32 2025 +0300 ARM: tegra: transformer-20: fix audio-codec interrupt [ Upstream commit 3f973d78d176768fa7456def97f0b9824235024f ] Correct audio-codec interrupt should be PX3 while PX1 is used for external microphone detection. Tested-by: Winona Schroeer-Smith # ASUS SL101 Tested-by: Antoni Aloy Torrens # ASUS TF101 Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5c95e96e94181985bcff93cec66fcf89ec85122e Author: Svyatoslav Ryhel Date: Sat Sep 6 09:29:31 2025 +0300 ARM: tegra: transformer-20: add missing magnetometer interrupt [ Upstream commit cca41614d15ce2bbc2c661362d3eafe53c9990af ] Add missing interrupt to magnetometer node. Tested-by: Winona Schroeer-Smith # ASUS SL101 Tested-by: Antoni Aloy Torrens # ASUS TF101 Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 27517baf234eccb249e4f70895402b7f3e4857b0 Author: Jonas Schwöbel Date: Wed Sep 3 19:19:46 2025 +0300 ARM: tegra: p880: set correct touchscreen clipping [ Upstream commit b49a73a08100ab139e07cfa7ca36e9b15787d0ab ] Existing touchscreen clipping is too small and causes problems with touchscreen accuracy. Signed-off-by: Jonas Schwöbel Signed-off-by: Svyatoslav Ryhel Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 472452e76d9c0034f8578b43c62fcee606c91758 Author: Svyatoslav Ryhel Date: Thu Aug 28 08:50:59 2025 +0300 soc/tegra: fuse: Add Tegra114 nvmem cells and fuse lookups [ Upstream commit b9c01adedf38c69abb725a60a05305ef70dbce03 ] Add missing Tegra114 nvmem cells and fuse lookups which were added for Tegra124+ but omitted for Tegra114. Signed-off-by: Svyatoslav Ryhel Reviewed-by: Mikko Perttunen Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 10bda7ac2ac52930ab6d155f6eeffceaca35a85d Author: Radhey Shyam Pandey Date: Tue Sep 2 09:56:19 2025 +0200 arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106 [ Upstream commit 767ecf9da7b31e5c0c22c273001cb2784705fe8c ] On a few zcu106 boards USB devices (Dell MS116 USB Optical Mouse, Dell USB Entry Keyboard) are not enumerated on linux boot due to commit 'b8745e7eb488 ("arm64: zynqmp: Fix usb node drive strength and slew rate")'. To fix it as a workaround revert to working version and then investigate at board level why drive strength from 12mA to 4mA and slew from fast to slow is not working. Signed-off-by: Radhey Shyam Pandey Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/85a70cb014ec1f07972fccb60b875596eeaa6b5c.1756799774.git.michal.simek@amd.com Signed-off-by: Sasha Levin commit ea6534d41f6d29bffee3bc749319373d2189fc5f Author: Quanyang Wang Date: Tue Sep 2 09:56:18 2025 +0200 arm64: zynqmp: Disable coresight by default [ Upstream commit 0e3f9140ad04dca9a6a93dd6a6decdc53fd665ca ] When secure-boot mode of bootloader is enabled, the registers of coresight are not permitted to access that's why disable it by default. Signed-off-by: Quanyang Wang Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/7e308b8efe977c4912079b4d1b1ab3d24908559e.1756799774.git.michal.simek@amd.com Signed-off-by: Sasha Levin commit ff023ab94f3324f75316ffcbbcb1c9da1a8f0b73 Author: Sohil Mehta Date: Mon Sep 8 16:06:55 2025 -0700 cpufreq: ondemand: Update the efficient idle check for Intel extended Families [ Upstream commit 7f3cfb7943d27a7b61bdac8db739cf0bdc28e87d ] IO time is considered busy by default for modern Intel processors. The current check covers recent Family 6 models but excludes the brand new Families 18 and 19. According to Arjan van de Ven, the model check was mainly due to a lack of testing on systems before INTEL_CORE2_MEROM. He suggests considering all Intel processors as having an efficient idle. Extend the IO busy classification to all Intel processors starting with Family 6, including Family 15 (Pentium 4s) and upcoming Families 18/19. Use an x86 VFM check and move the function to the header file to avoid using arch-specific #ifdefs in the C file. Signed-off-by: Sohil Mehta Link: https://patch.msgid.link/20250908230655.2562440-1-sohil.mehta@intel.com [ rjw: Added empty line after #include ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f420b7cb807f1e043b44afd3a2a6f9554429821e Author: Ming Wang Date: Tue Sep 9 20:58:40 2025 +0800 irqchip/loongson-pch-lpc: Use legacy domain for PCH-LPC IRQ controller [ Upstream commit c33c43f71bda362b292a6e57ac41b64342dc87b3 ] On certain Loongson platforms, drivers attempting to request a legacy ISA IRQ directly via request_irq() (e.g., IRQ 4) may fail. The virtual IRQ descriptor is not fully initialized and lacks a valid irqchip. This issue does not affect ACPI-enumerated devices described in DSDT, as their interrupts are properly mapped via the GSI translation path. This indicates the LPC irqdomain itself is functional but is not correctly handling direct VIRQ-to-HWIRQ mappings. The root cause is the use of irq_domain_create_linear(). This API sets up a domain for dynamic, on-demand mapping, typically triggered by a GSI request. It does not pre-populate the mappings for the legacy VIRQ range (0-15). Consequently, if no ACPI device claims a specific GSI (e.g., GSI 4), the corresponding VIRQ (e.g., VIRQ 4) is never mapped to the LPC domain. A direct call to request_irq(4, ...) then fails because the kernel cannot resolve this VIRQ to a hardware interrupt managed by the LPC controller. The PCH-LPC interrupt controller is an i8259-compatible legacy device that requires a deterministic, static 1-to-1 mapping for IRQs 0-15 to support legacy drivers. Fix this by replacing irq_domain_create_linear() with irq_domain_create_legacy(). This API is specifically designed for such controllers. It establishes the required static 1-to-1 VIRQ-to-HWIRQ mapping for the entire legacy range (0-15) immediately upon domain creation. This ensures that any VIRQ in this range is always resolvable, making direct calls to request_irq() for legacy IRQs function correctly. Signed-off-by: Ming Wang Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit aa06016d5b31c2cdfb3af4a8fb6336f311b1f85c Author: Andreas Kemnade Date: Tue Sep 9 10:02:49 2025 +0200 hwmon: sy7636a: add alias [ Upstream commit 80038a758b7fc0cdb6987532cbbf3f75b13e0826 ] Add module alias to have it autoloaded. Signed-off-by: Andreas Kemnade Link: https://lore.kernel.org/r/20250909080249.30656-1-andreas@kemnade.info Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 94a612b6b7397bed7a742970789766d89925dba6 Author: Fabien Proriol Date: Mon Jul 7 17:55:08 2025 +0200 power: supply: sbs-charger: Support multiple devices [ Upstream commit 3ec600210849cf122606e24caab85f0b936cf63c ] If we have 2 instances of sbs-charger in the DTS, the driver probe for the second instance will fail: [ 8.012874] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 8.039094] sbs-charger 18-0009: ltc4100: smart charger device registered [ 8.112911] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 8.134533] sysfs: cannot create duplicate filename '/class/power_supply/sbs-charger' [ 8.143871] CPU: 3 PID: 295 Comm: systemd-udevd Tainted: G O 5.10.147 #22 [ 8.151974] Hardware name: ALE AMB (DT) [ 8.155828] Call trace: [ 8.158292] dump_backtrace+0x0/0x1d4 [ 8.161960] show_stack+0x18/0x6c [ 8.165280] dump_stack+0xcc/0x128 [ 8.168687] sysfs_warn_dup+0x60/0x7c [ 8.172353] sysfs_do_create_link_sd+0xf0/0x100 [ 8.176886] sysfs_create_link+0x20/0x40 [ 8.180816] device_add+0x270/0x7a4 [ 8.184311] __power_supply_register+0x304/0x560 [ 8.188930] devm_power_supply_register+0x54/0xa0 [ 8.193644] sbs_probe+0xc0/0x214 [sbs_charger] [ 8.198183] i2c_device_probe+0x2dc/0x2f4 [ 8.202196] really_probe+0xf0/0x510 [ 8.205774] driver_probe_device+0xfc/0x160 [ 8.209960] device_driver_attach+0xc0/0xcc [ 8.214146] __driver_attach+0xc0/0x170 [ 8.218002] bus_for_each_dev+0x74/0xd4 [ 8.221862] driver_attach+0x24/0x30 [ 8.225444] bus_add_driver+0x148/0x250 [ 8.229283] driver_register+0x78/0x130 [ 8.233140] i2c_register_driver+0x4c/0xe0 [ 8.237250] sbs_driver_init+0x20/0x1000 [sbs_charger] [ 8.242424] do_one_initcall+0x50/0x1b0 [ 8.242434] do_init_module+0x44/0x230 [ 8.242438] load_module+0x2200/0x27c0 [ 8.242442] __do_sys_finit_module+0xa8/0x11c [ 8.242447] __arm64_sys_finit_module+0x20/0x30 [ 8.242457] el0_svc_common.constprop.0+0x64/0x154 [ 8.242464] do_el0_svc+0x24/0x8c [ 8.242474] el0_svc+0x10/0x20 [ 8.242481] el0_sync_handler+0x108/0x114 [ 8.242485] el0_sync+0x180/0x1c0 [ 8.243847] sbs-charger 20-0009: Failed to register power supply [ 8.287934] sbs-charger: probe of 20-0009 failed with error -17 This is mainly because the "name" field of power_supply_desc is a constant. This patch fixes the issue by reusing the same approach as sbs-battery. With this patch, the result is: [ 7.819532] sbs-charger 18-0009: ltc4100: smart charger device registered [ 7.825305] sbs-battery 18-000b: sbs-battery: battery gas gauge device registered [ 7.887423] sbs-battery 20-000b: sbs-battery: battery gas gauge device registered [ 7.893501] sbs-charger 20-0009: ltc4100: smart charger device registered Signed-off-by: Fabien Proriol Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e237d61d10ce560c9f9402bc083433e48aae79e1 Author: Bartosz Golaszewski Date: Tue Sep 2 13:59:17 2025 +0200 pinctrl: keembay: release allocated memory in detach path [ Upstream commit aae7a2876c3b39d07aa7655ea082af8e7862f3a5 ] Unlike all the other allocations in this driver, the memory for storing the pin function descriptions allocated with kcalloc() and later resized with krealloc() is never freed. Use devres like elsewhere to handle that. While at it - replace krealloc() with more suitable devm_krealloc_array(). Note: the logic in this module is pretty convoluted and could probably use some revisiting, we should probably be able to calculate the exact amount of memory needed in advance or even skip the allocation altogether and just add each function to the radix tree separately. Tested-by: Neil Armstrong Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c79a51eaf67694a960870ed80106e108c0dec171 Author: Chuande Chen Date: Thu Aug 14 13:39:40 2025 +0800 hwmon: (sbtsi_temp) AMD CPU extended temperature range support [ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ] Many AMD CPUs can support this feature now. We would get a wrong CPU DIE temperature if don't consider this. In low-temperature environments, the CPU die temperature can drop below zero. So many platforms would like to make extended temperature range as their default configuration. Default temperature range (0C to 255.875C). Extended temperature range (-49C to +206.875C). Ref Doc: AMD V3000 PPR (Doc ID #56558). Signed-off-by: Chuande Chen Link: https://lore.kernel.org/r/20250814053940.96764-1-chenchuande@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit db2056038deca236269f1ec3c1c22f86dc08f5a7 Author: David Ober Date: Thu Aug 7 06:32:28 2025 -0400 hwmon: (lenovo-ec-sensors) Update P8 supprt [ Upstream commit 43c056ac85b60232861005765153707f1b0354b6 ] This fixes differences for the P8 system that was initially set to the same thermal values as the P7, also adds in the PSU sensor for all of the supported systems Signed-off-by: David Ober Signed-off-by: David Ober Link: https://lore.kernel.org/r/20250807103228.10465-1-dober6023@gmail.com [groeck: Update subject] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f9c64e110da1bcb5c2794acf88b7000b2029f3be Author: Rong Zhang Date: Sun Aug 24 02:04:41 2025 +0800 hwmon: (k10temp) Add device ID for Strix Halo [ Upstream commit e5d1e313d7b6272d6dfda983906d99f97ad9062b ] The device ID of Strix Halo Data Fabric Function 3 has been in the tree since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family 0x1a"), but is somehow missing from k10temp_id_table. Add it so that it works out of the box. Tested on Beelink GTR9 Pro Mini PC. Signed-off-by: Rong Zhang Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20250823180443.85512-1-i@rong.moe Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2bd194738ca929c1194b24cdd9b1cc87cf2310d5 Author: Avadhut Naik Date: Tue Jul 29 00:15:43 2025 +0000 hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based models [ Upstream commit f116af2eb51ed9df24911537fda32a033f1c58da ] Add thermal info support for newer AMD Family 1Ah-based models. Signed-off-by: Avadhut Naik Link: https://lore.kernel.org/r/20250729001644.257645-1-avadhut.naik@amd.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ce7c0d7be1f154c7de3776443eeea3fd47b9582f Author: Christopher Ruehl Date: Mon Aug 11 17:22:09 2025 +0200 power: supply: qcom_battmgr: add OOI chemistry [ Upstream commit fee0904441325d83e7578ca457ec65a9d3f21264 ] The ASUS S15 xElite model report the Li-ion battery with an OOI, hence this update the detection and return the appropriate type. Signed-off-by: Christopher Ruehl Reviewed-by: Dmitry Baryshkov Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit bbe77f5bb5c7f37587d2aa356c81b6c5b92e9d64 Author: Srinivas Pandruvada Date: Thu Aug 28 13:15:41 2025 -0700 thermal: intel: selftests: workload_hint: Mask unsupported types [ Upstream commit 0115d063559fa6d25e41751cf455dda40aa2c856 ] The workload hint may contain some other hints which are not defined. So mask out unsupported types. Currently only lower 4 bits of workload type hints are defined. Signed-off-by: Srinivas Pandruvada Link: https://patch.msgid.link/20250828201541.931425-1-srinivas.pandruvada@linux.intel.com [ rjw: Subject cleanup ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 91507503663d8d041ae3584eac63624249db8595 Author: Rafael J. Wysocki Date: Mon Aug 25 15:31:53 2025 +0200 thermal: gov_step_wise: Allow cooling level to be reduced earlier [ Upstream commit 2e82368359f63567862a0d438710ddffcb1ace83 ] The current behavior of the Step-wise thermal governor is to increase the cooling level one step at a time after trip point threshold passing by thermal zone temperature until the temperature stops to rise. Then, nothing is done until the temperature decreases below the (possibly updated) trip point threshold, at which point the cooling level is reduced straight to the applicable minimum. While this generally works, it is not in agreement with the throttling logic description comment in step_wise_manage() any more after some relatively recent changes, and in the case of passive cooling, it may lead to undesirable performance oscillations between high and low levels. For this reason, modify the governor's cooling device state selection function, get_target_state(), to reduce cooling by one level even if the temperature is still above the thermal zone threshold, but the temperature has started to fall down. However, ensure that the cooling level will remain above the applicable minimum in that case to pull the zone temperature further down, possibly until it falls below the trip threshold (which may now be equal to the low temperature of the trip). Doing so should help higher performance to be restored earlier in some cases which is desirable especially for passive trip points with relatively high hysteresis values. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/1947735.tdWV9SEqCh@rafael.j.wysocki [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 0725fc68fc671888b463e2bb6cfdb363260931e2 Author: Hans de Goede Date: Fri Aug 29 16:27:48 2025 +0200 ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[] [ Upstream commit 4405a214df146775338a1e6232701a29024b82e1 ] Some x86/ACPI laptops with MIPI cameras have a INTC10DE or INTC10E0 ACPI device in the _DEP dependency list of the ACPI devices for the camera- sensors (which have flags.honor_deps set). These devices are for an Intel Vision CVS chip for which an out of tree driver is available [1]. The camera sensor works fine without a driver being loaded for this ACPI device on the 2 laptops this was tested on: ThinkPad X1 Carbon Gen 12 (Meteor Lake) ThinkPad X1 2-in-1 Gen 10 (Arrow Lake) For now add these HIDs to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met and an i2c_client for the camera sensor will get instantiated. Link: https://github.com/intel/vision-drivers/ [1] Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20250829142748.21089-1-hansg@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6bb7489f38d9e271a79fea58332f032268282721 Author: Sam van Kampen Date: Fri Aug 29 14:52:22 2025 +0000 ACPI: resource: Skip IRQ override on ASUS Vivobook Pro N6506CU [ Upstream commit 3a351de0d9c86e23b9eca25838b19468aab02f38 ] Just like the other Vivobooks here, the N6506CU has its keyboard IRQ described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh, causing the internal keyboard not to work. Add the N6506CU to the irq1_level_low_skip_override[] quirk table to fix this. Signed-off-by: Sam van Kampen Link: https://patch.msgid.link/20250829145221.2294784-2-sam@tehsvk.net Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c1e1a5653b684f791a7c756653d2f68851c39d3b Author: Shang song (Lenovo) Date: Mon Aug 25 23:02:29 2025 -0400 ACPI: PRM: Skip handlers with NULL handler_address or NULL VA [ Upstream commit 311942ce763e21dacef7e53996d5a1e19b8adab1 ] If handler_address or mapped VA is NULL, the related buffer address and VA can be ignored, so make acpi_parse_prmt() skip the current handler in those cases. Signed-off-by: Shang song (Lenovo) Link: https://patch.msgid.link/20250826030229.834901-1-shangsong2@foxmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cd63490ff4ed52dea081399fe4c38adcf48057d8 Author: Christian Bruel Date: Tue Sep 2 11:10:45 2025 +0200 irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment [ Upstream commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ] The PCI Local Bus Specification 3.0 (section 6.8.1.6) allows modifying the low-order bits of the MSI Message DATA register to encode nr_irqs interrupt numbers in the log2(nr_irqs) bits for the domain. The problem arises if the base vector (GICV2m base spi) is not aligned with nr_irqs; in this case, the low-order log2(nr_irqs) bits from the base vector conflict with the nr_irqs masking, causing the wrong MSI interrupt to be identified. To fix this, use bitmap_find_next_zero_area_off() instead of bitmap_find_free_region() to align the initial base vector with nr_irqs. Signed-off-by: Christian Bruel Signed-off-by: Thomas Gleixner Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/all/20250902091045.220847-1-christian.bruel@foss.st.com Signed-off-by: Sasha Levin commit c9a1c43f762ce685740945c2efa738f0b9d8bdc2 Author: Ricardo B. Marlière Date: Thu Aug 28 15:48:30 2025 -0300 selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh [ Upstream commit 2a912258c90e895363c0ffc0be8a47f112ab67b7 ] Currently, even if some subtests fails, the end result will still yield "ok 1 selftests: bpf: test_xsk.sh". Fix it by exiting with 1 if there are any failures. Signed-off-by: Ricardo B. Marlière Signed-off-by: Andrii Nakryiko Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20250828-selftests-bpf-test_xsk_ret-v1-1-e6656c01f397@suse.com Signed-off-by: Sasha Levin commit e8e0637b85a12b22ebbb1b767d16bbd8b7c5c67a Author: Kees Cook Date: Sat Aug 30 19:23:53 2025 -0700 arc: Fix __fls() const-foldability via __builtin_clzl() [ Upstream commit a3fecb9160482367365cc384c59dd220b162b066 ] While tracking down a problem where constant expressions used by BUILD_BUG_ON() suddenly stopped working[1], we found that an added static initializer was convincing the compiler that it couldn't track the state of the prior statically initialized value. Tracing this down found that ffs() was used in the initializer macro, but since it wasn't marked with __attribute__const__, the compiler had to assume the function might change variable states as a side-effect (which is not true for ffs(), which provides deterministic math results). For arc architecture with CONFIG_ISA_ARCV2=y, the __fls() function uses __builtin_arc_fls() which lacks GCC's const attribute, preventing compile-time constant folding, and KUnit testing of ffs/fls fails on arc[3]. A patch[2] to GCC to solve this has been sent. Add a fix for this by handling compile-time constants with the standard __builtin_clzl() builtin (which has const attribute) while preserving the optimized arc-specific builtin for runtime cases. This has the added benefit of skipping runtime calculation of compile-time constant values. Even with the GCC bug fixed (which is about "attribute const") this is a good change to avoid needless runtime costs, and should be done regardless of the state of GCC's bug. Build tested ARCH=arc allyesconfig with GCC arc-linux 15.2.0. Link: https://github.com/KSPP/linux/issues/364 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508031025.doWxtzzc-lkp@intel.com/ [3] Signed-off-by: Kees Cook Acked-by: Vineet Gupta Signed-off-by: Yury Norov (NVIDIA) Signed-off-by: Sasha Levin commit 64adabb6d9d51b7e7c02fe733346a2c4dd738488 Author: Dennis Beier Date: Sat Aug 30 16:43:59 2025 +0200 cpufreq/longhaul: handle NULL policy in longhaul_exit [ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ] longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962 Signed-off-by: Dennis Beier Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit e832948915e2abb9142d9e247592d83e5c55c547 Author: Ricardo B. Marlière Date: Thu Aug 28 10:12:33 2025 -0300 selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2 [ Upstream commit 98857d111c53954aa038fcbc4cf48873e4240f7c ] Commit e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt the usage in test_lirc_mode2_user.c. Signed-off-by: Ricardo B. Marlière Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250828-selftests-bpf-v1-1-c7811cd8b98c@suse.com Signed-off-by: Sasha Levin commit 4aeae7cc715630b5e087cf7b3a0239f22f737cba Author: Jiawei Zhao Date: Wed Aug 27 05:31:27 2025 +0000 libbpf: Fix USDT SIB argument handling causing unrecognized register error [ Upstream commit 758acb9ccfdbf854b55abaceaf1f3f229cde3d19 ] On x86-64, USDT arguments can be specified using Scale-Index-Base (SIB) addressing, e.g. "1@-96(%rbp,%rax,8)". The current USDT implementation in libbpf cannot parse this format, causing `bpf_program__attach_usdt()` to fail with -ENOENT (unrecognized register). This patch fixes this by implementing the necessary changes: - add correct handling for SIB-addressed arguments in `bpf_usdt_arg`. - add adaptive support to `__bpf_usdt_arg_type` and `__bpf_usdt_arg_spec` to represent SIB addressing parameters. Signed-off-by: Jiawei Zhao Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250827053128.1301287-2-phoenix500526@163.com Signed-off-by: Sasha Levin commit e38c07cc59c9c65424ed4e43defb496826ea49b5 Author: Mario Limonciello (AMD) Date: Wed Aug 20 12:09:26 2025 -0500 ACPI: video: force native for Lenovo 82K8 [ Upstream commit f144bc21befdcf8e54d2f19b23b4e84f13be01f9 ] Lenovo 82K8 has a broken brightness control provided by nvidia_wmi_ec. Add a quirk to prevent using it. Reported-by: Wilson Alvarez Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4512 Tested-by: Wilson Alvarez Signed-off-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20250820170927.895573-1-superm1@kernel.org Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c0cc3080aae076e463b8bc7778e5688dcc588dcc Author: Kaushlendra Kumar Date: Fri Aug 22 11:49:46 2025 +0530 ACPI: sysfs: Use ACPI_FREE() for freeing an ACPI object [ Upstream commit 149139ddcb99583fdec8d1eaf7dada41e5896101 ] Since str_obj is allocated by ACPICA in acpi_evaluate_object_typed(), it should be free with ACPI_FREE() rather than with kfree(), so use the former instead of the latter for freeing it. Signed-off-by: Kaushlendra Kumar Link: https://patch.msgid.link/20250822061946.472594-1-kaushlendra.kumar@intel.com [ rjw: Subject and changelog rewrite ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit aaafd17d3f4be2c15539359a5b4bfa00237f687f Author: Pavel Begunkov Date: Thu Aug 14 15:40:57 2025 +0100 io_uring/zctx: check chained notif contexts [ Upstream commit ab3ea6eac5f45669b091309f592c4ea324003053 ] Send zc only links ubuf_info for requests coming from the same context. There are some ambiguous syz reports, so let's check the assumption on notification completion. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/fd527d8638203fe0f1c5ff06ff2e1d8fd68f831b.1755179962.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a3c875e9aeb4dbc0a222ac3eb1f90b1c221658c0 Author: Inochi Amaoto Date: Mon Aug 11 08:26:32 2025 +0800 irqchip/sifive-plic: Respect mask state when setting affinity [ Upstream commit adecf78df945f4c7a1d29111b0002827f487df51 ] plic_set_affinity() always calls plic_irq_enable(), which clears up the priority setting even the interrupt is only masked. This unmasks the interrupt unexpectly. Replace the plic_irq_enable/disable() with plic_irq_toggle() to avoid changing the priority setting. Suggested-by: Thomas Gleixner Signed-off-by: Inochi Amaoto Signed-off-by: Thomas Gleixner Tested-by: Nam Cao # VisionFive 2 Tested-by: Chen Wang # Pioneerbox Reviewed-by: Nam Cao Reviewed-by: Chen Wang Link: https://lore.kernel.org/all/20250811002633.55275-1-inochiama@gmail.com Link: https://lore.kernel.org/lkml/20250722224513.22125-1-inochiama@gmail.com/ Signed-off-by: Sasha Levin commit a4af74391b549f4ed6853d926bef493a20732a2d Author: Takashi Sakamoto Date: Sat Aug 23 12:09:52 2025 +0900 firewire: ohci: move self_id_complete tracepoint after validating register [ Upstream commit 696968262aeee51e1c0529c3c060ddd180702e02 ] The value of OHCI1394_SelfIDCount register includes an error-indicating bit. It is safer to place the tracepoint probe after validating the register value. Link: https://lore.kernel.org/r/20250823030954.268412-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 0f20be8733d1e6368d8fcc2758c18de70c01146a Author: Paul Chaignon Date: Wed Aug 20 15:18:06 2025 +0200 bpf: Use tnums for JEQ/JNE is_branch_taken logic [ Upstream commit f41345f47fb267a9c95ca710c33448f8d0d81d83 ] In the following toy program (reg states minimized for readability), R0 and R1 always have different values at instruction 6. This is obvious when reading the program but cannot be guessed from ranges alone as they overlap (R0 in [0; 0xc0000000], R1 in [1024; 0xc0000400]). 0: call bpf_get_prandom_u32#7 ; R0_w=scalar() 1: w0 = w0 ; R0_w=scalar(var_off=(0x0; 0xffffffff)) 2: r0 >>= 30 ; R0_w=scalar(var_off=(0x0; 0x3)) 3: r0 <<= 30 ; R0_w=scalar(var_off=(0x0; 0xc0000000)) 4: r1 = r0 ; R1_w=scalar(var_off=(0x0; 0xc0000000)) 5: r1 += 1024 ; R1_w=scalar(var_off=(0x400; 0xc0000000)) 6: if r1 != r0 goto pc+1 Looking at tnums however, we can deduce that R1 is always different from R0 because their tnums don't agree on known bits. This patch uses this logic to improve is_scalar_branch_taken in case of BPF_JEQ and BPF_JNE. This change has a tiny impact on complexity, which was measured with the Cilium complexity CI test. That test covers 72 programs with various build and load time configurations for a total of 970 test cases. For 80% of test cases, the patch has no impact. On the other test cases, the patch decreases complexity by only 0.08% on average. In the best case, the verifier needs to walk 3% less instructions and, in the worst case, 1.5% more. Overall, the patch has a small positive impact, especially for our largest programs. Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Acked-by: Shung-Hsi Yu Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/be3ee70b6e489c49881cb1646114b1d861b5c334.1755694147.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin commit 6dc536165ba5fc9697d34524f01bee637f206fab Author: Paresh Bhagat Date: Wed Aug 20 14:03:31 2025 +0530 cpufreq: ti: Add support for AM62D2 [ Upstream commit b5af45302ebc141662b2b60c713c9202e88c943c ] Add support for TI K3 AM62D2 SoC to read speed and revision values from hardware and pass to OPP layer. AM62D shares the same configuations as AM62A so use existing am62a7_soc_data. Signed-off-by: Paresh Bhagat Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 09daf72a64b73eb3349ba55dde4e2019ccf8f41e Author: Jiayi Li Date: Mon Aug 4 10:48:25 2025 +0800 memstick: Add timeout to prevent indefinite waiting [ Upstream commit b65e630a55a490a0269ab1e4a282af975848064c ] Add timeout handling to wait_for_completion calls in memstick_set_rw_addr() and memstick_alloc_card() to prevent indefinite blocking in case of hardware or communication failures. Signed-off-by: Jiayi Li Link: https://lore.kernel.org/r/20250804024825.1565078-1-lijiayi@kylinos.cn Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 37aa3afbf8c6f88896e97fdc6c33c4c409fb3d1f Author: Biju Das Date: Sun Jun 29 21:38:56 2025 +0100 mmc: host: renesas_sdhi: Fix the actual clock [ Upstream commit 9c174e4dacee9fb2014a4ffc953d79a5707b77e4 ] Wrong actual clock reported, if the SD clock division ratio is other than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111). On high speed mode, cat /sys/kernel/debug/mmc1/ios Without the patch: clock: 50000000 Hz actual clock: 200000000 Hz After the fix: clock: 50000000 Hz actual clock: 50000000 Hz Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20250629203859.170850-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 9673c58764ed4ec9a4674f3c1d3f61a7db465a01 Author: Chi Zhang Date: Thu Aug 7 14:20:38 2025 +0800 pinctrl: single: fix bias pull up/down handling in pin_config_set [ Upstream commit 236152dd9b1675a35eee912e79e6c57ca6b6732f ] In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias() which writes the register. However, the subsequent operations continue using the stale 'data' value from before the register write, effectively causing the bias clear operation to be overwritten and not take effect. Fix this by reading the 'data' value from the register after calling pcs_pinconf_clear_bias(). This bug seems to have existed when this code was first merged in commit 9dddb4df90d1 ("pinctrl: single: support generic pinconf"). Signed-off-by: Chi Zhang Link: https://lore.kernel.org/20250807062038.13610-1-chizhang@asrmicro.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 943797cbe89b1954211b624b4bdd3d4c3003dadd Author: Thomas Weißschuh Date: Mon Aug 11 14:08:04 2025 +0200 bpf: Don't use %pK through printk [ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250811-restricted-pointers-bpf-v1-1-a1d7cc3cb9e7@linutronix.de Signed-off-by: Sasha Levin commit b51878b5edb9d075b8f1810aaedc3bae0513d6b4 Author: Thomas Weißschuh Date: Mon Aug 11 09:48:30 2025 +0200 soc: ti: pruss: don't use %pK through printk [ Upstream commit a5039648f86424885aae37f03dc39bc9cb972ecb ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250811-restricted-pointers-soc-v2-1-7af7ed993546@linutronix.de Signed-off-by: Nishanth Menon Signed-off-by: Sasha Levin commit 1c2c60c9bb6ae573ca1933c93bc6b21cd88e504e Author: Thomas Weißschuh Date: Mon Aug 11 14:10:21 2025 +0200 spi: loopback-test: Don't use %pK through printk [ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ] In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20250811-restricted-pointers-spi-v1-1-32c47f954e4d@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1bc4a402c018496a63b3985d491d80b38f13c63c Author: Jens Reidel Date: Sun Jul 27 01:56:46 2025 +0200 soc: qcom: smem: Fix endian-unaware access of num_entries [ Upstream commit 19e7aa0e9e46d0ad111a4af55b3d681b6ad945e0 ] Add a missing le32_to_cpu when accessing num_entries, which is always a little endian integer. Fixes booting on Xiaomi Mi 9T (xiaomi-davinci) in big endian. Signed-off-by: Jens Reidel Link: https://lore.kernel.org/r/20250726235646.254730-1-adrian@mainlining.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 27568eeee66d9091b4cbd9c0f24bc7e042e9144a Author: Mukesh Ojha Date: Thu Aug 7 18:14:51 2025 +0530 firmware: qcom: scm: preserve assign_mem() error return value [ Upstream commit 121fcf3c871181edce0708a49d2397cedd6ad21f ] When qcom_scm_assign_mem() fails, the error value is currently being overwritten after it is logged, resulting in the loss of the original error code. Fix this by retaining and returning the original error value as intended. Signed-off-by: Mukesh Ojha Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250807124451.2623019-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit afc13decf32b6844ec39f9bc4665f0ed3229defc Author: Ryan Chen Date: Thu Aug 7 08:52:08 2025 +0800 soc: aspeed: socinfo: Add AST27xx silicon IDs [ Upstream commit c30dcfd4b5a0f0e3fe7138bf287f6de6b1b00278 ] Extend the ASPEED SoC info driver to support AST27XX silicon IDs. Signed-off-by: Ryan Chen Link: https://patch.msgid.link/20250807005208.3517283-1-ryan_chen@aspeedtech.com Signed-off-by: Andrew Jeffery Signed-off-by: Sasha Levin commit 5e23918e4352288323d13fb511116cdea0234b71 Author: Heiko Carstens Date: Sun Nov 2 21:24:16 2025 -0500 s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP [ Upstream commit 64e2f60f355e556337fcffe80b9bcff1b22c9c42 ] As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it. Reported-by: Luiz Capitulino Closes: https://lore.kernel.org/all/20251028153930.37107-1-luizcap@redhat.com/ Fixes: 00a34d5a99c0 ("s390: select ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP") Cc: stable@vger.kernel.org Tested-by: Luiz Capitulino Reviewed-by: Gerald Schaefer Reviewed-by: David Hildenbrand Signed-off-by: Heiko Carstens [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3591d56ea9bfd3e7fbbe70f749bdeed689d415f9 Author: Gerd Bayer Date: Sun Nov 2 21:24:19 2025 -0500 s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump [ Upstream commit 0fd20f65df6aa430454a0deed8f43efa91c54835 ] Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/ reporter fw_fatal while PCI error recovery is executed on the same physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space. Link: https://lore.kernel.org/all/20251007144826.2825134-1-gbayer@linux.ibm.com/ Cc: stable@vger.kernel.org Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery") Reviewed-by: Niklas Schnelle Signed-off-by: Gerd Bayer Signed-off-by: Heiko Carstens [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6be3d7f731dcf2e0ae8b88a4f7e7cefb0e1fb991 Author: Philipp Stanner Date: Mon Nov 3 07:44:50 2025 -0500 drm/sched: Fix race in drm_sched_entity_select_rq() [ Upstream commit d25e3a610bae03bffc5c14b5d944a5d0cd844678 ] In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: stable@vger.kernel.org # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Reviewed-by: Tvrtko Ursulin Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251022063402.87318-2-phasta@kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f78da4cad3b112375881244a3538e2ba0feb2220 Author: Tvrtko Ursulin Date: Mon Nov 3 07:44:49 2025 -0500 drm/sched: Re-group and rename the entity run-queue lock [ Upstream commit f93126f5d55920d1447ef00a3fbe6706f40f53de ] When writing to a drm_sched_entity's run-queue, writers are protected through the lock drm_sched_entity.rq_lock. This naming, however, frequently collides with the separate internal lock of struct drm_sched_rq, resulting in uses like this: spin_lock(&entity->rq_lock); spin_lock(&entity->rq->lock); Rename drm_sched_entity.rq_lock to improve readability. While at it, re-order that struct's members to make it more obvious what the lock protects. v2: * Rename some rq_lock straddlers in kerneldoc, improve commit text. (Philipp) Signed-off-by: Tvrtko Ursulin Suggested-by: Christian König Cc: Alex Deucher Cc: Luben Tuikov Cc: Matthew Brost Cc: Philipp Stanner Reviewed-by: Christian König [pstanner: Fix typo in docstring] Signed-off-by: Philipp Stanner Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-5-tursulin@igalia.com Stable-dep-of: d25e3a610bae ("drm/sched: Fix race in drm_sched_entity_select_rq()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 431b4e8c7bfdc7c5535aaa8bf7f1dabf848fca1e Author: Tvrtko Ursulin Date: Mon Nov 3 07:44:48 2025 -0500 drm/sched: Optimise drm_sched_entity_push_job [ Upstream commit d42a254633c773921884a19e8a1a0f53a31150c3 ] In FIFO mode (which is the default), both drm_sched_entity_push_job() and drm_sched_rq_update_fifo(), where the latter calls the former, are currently taking and releasing the same entity->rq_lock. We can avoid that design inelegance, and also have a miniscule efficiency improvement on the submit from idle path, by introducing a new drm_sched_rq_update_fifo_locked() helper and pulling up the lock taking to its callers. v2: * Remove drm_sched_rq_update_fifo() altogether. (Christian) v3: * Improved commit message. (Philipp) Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Alex Deucher Cc: Luben Tuikov Cc: Matthew Brost Cc: Philipp Stanner Reviewed-by: Christian König Signed-off-by: Philipp Stanner Link: https://patchwork.freedesktop.org/patch/msgid/20241016122013.7857-2-tursulin@igalia.com Stable-dep-of: d25e3a610bae ("drm/sched: Fix race in drm_sched_entity_select_rq()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d62b808d5c68a931ad0849a00a5e3be3dd7e0019 Author: Owen Gu Date: Mon Sep 15 17:29:07 2025 +0800 usb: gadget: f_fs: Fix epfile null pointer access after ep enable. commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 upstream. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues Signed-off-by: Owen Gu Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman commit e980de2ff109dacb6d9d3a77f01b27c467115ecb Author: Gregory Price Date: Mon Oct 20 11:13:55 2025 +0200 x86/CPU/AMD: Add RDSEED fix for Zen5 commit 607b9fb2ce248cc5b633c5949e0153838992c152 upstream. There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ] Cc: stable@vger.kernel.org Signed-off-by: Gregory Price Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net [ bp: 6.12 backport: use the alternative microcode version checking. ] Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman commit 958999dbd18ece791f30b47033f7576df4bf067e Author: Heijligen, Thomas Date: Thu Jul 31 14:45:00 2025 +0000 mfd: kempld: Switch back to earlier ->init() behavior commit 309e65d151ab9be1e7b01d822880cd8c4e611dff upstream. Commit 9e36775c22c7 ("mfd: kempld: Remove custom DMI matching code") removes the ability to load the driver if no matching system DMI data is found. Before this commit the driver could be loaded using alternative methods such as ACPI or `force_device_id` in the absence of a matching system DMI entry. Restore this ability while keeping the refactored `platform_device_info` table. Signed-off-by: Thomas Heijligen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/7d2c7e92253d851194a781720051536cca2722b8.camel@secunet.com Signed-off-by: Lee Jones Cc: Michael Brunner Signed-off-by: Greg Kroah-Hartman commit acbbd683b3ea6583fe22157f51ba1a2a499aeef1 Author: Rafael J. Wysocki Date: Sun Nov 2 13:57:30 2025 -0500 cpuidle: governors: menu: Select polling state in some more cases [ Upstream commit db86f55bf81a3a297be05ee8775ae9a8c6e3a599 ] A throughput regression of 11% introduced by commit 779b1a1cb13a ("cpuidle: governors: menu: Avoid selecting states with too much latency") has been reported and it is related to the case when the menu governor checks if selecting a proper idle state instead of a polling one makes sense. In particular, it is questionable to do so if the exit latency of the idle state in question exceeds the predicted idle duration, so add a check for that, which is sufficient to make the reported regression go away, and update the related code comment accordingly. Fixes: 779b1a1cb13a ("cpuidle: governors: menu: Avoid selecting states with too much latency") Closes: https://lore.kernel.org/linux-pm/004501dc43c9$ec8aa930$c59ffb90$@telus.net/ Reported-by: Doug Smythies Tested-by: Doug Smythies Cc: All applicable Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/12786727.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e3853abbba50657349177ee32056de50c6411007 Author: Rafael J. Wysocki Date: Sun Nov 2 13:57:29 2025 -0500 cpuidle: governors: menu: Rearrange main loop in menu_select() [ Upstream commit 17224c1d2574d29668c4879e1fbf36d6f68cd22b ] Reduce the indentation level in the main loop of menu_select() by rearranging some checks and assignments in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Christian Loehle Link: https://patch.msgid.link/2389215.ElGaqSPkdT@rafael.j.wysocki Stable-dep-of: db86f55bf81a ("cpuidle: governors: menu: Select polling state in some more cases") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46fcee9f99ef401a61a97368263b37f60bc6a0c7 Author: Tejun Heo Date: Sun Nov 2 09:44:17 2025 -0500 sched_ext: Mark scx_bpf_dsq_move_set_[slice|vtime]() with KF_RCU [ Upstream commit 54e96258a6930909b690fd7e8889749231ba8085 ] scx_bpf_dsq_move_set_slice() and scx_bpf_dsq_move_set_vtime() take a DSQ iterator argument which has to be valid. Mark them with KF_RCU. Fixes: 4c30f5ce4f7a ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()") Cc: stable@vger.kernel.org # v6.12+ Acked-by: Andrea Righi Signed-off-by: Tejun Heo [ scx_bpf_dsq_move_set_* => scx_bpf_dispatch_from_dsq_set_* ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 094932903f6d1ecc6df7669c052f9c59a3428a79 Author: Armin Wolf Date: Sun Nov 2 09:35:14 2025 -0500 ACPI: fan: Use platform device for devres-related actions [ Upstream commit d91a1d129b63614fa4c2e45e60918409ce36db7e ] Device-managed resources are cleaned up when the driver unbinds from the underlying device. In our case this is the platform device as this driver is a platform driver. Registering device-managed resources on the associated ACPI device will thus result in a resource leak when this driver unbinds. Ensure that any device-managed resources are only registered on the platform device to ensure that they are cleaned up during removal. Fixes: 35c50d853adc ("ACPI: fan: Add hwmon support") Signed-off-by: Armin Wolf Cc: 6.11+ # 6.11+ Link: https://patch.msgid.link/20251007234149.2769-4-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2e07b95e0a1b929a59d7c14de789385b5ac501b Author: Joshua Grisham Date: Sun Nov 2 09:35:13 2025 -0500 ACPI: fan: Add fan speed reporting for fans with only _FST [ Upstream commit 6c00f29f74cb2c063b6f31a0b6d73f9db132b9ac ] Add support for ACPI fans with _FST to report their speed even if they do not support fan control. As suggested by Armin Wolf [1] and per the Windows Thermal Management Design Guide [2], Samsung Galaxy Book series devices (and possibly many more devices where the Windows guide was strictly followed) only implement the _FST method and do not support ACPI-based fan control. Currently, these fans are not supported by the kernel driver but this patch will make some very small adjustments to allow them to be supported. This patch is tested and working for me on a Samsung Galaxy Book2 Pro whose DSDT (and several other Samsung Galaxy Book series notebooks which currently have the same issue) can be found at [3]. Link: https://lore.kernel.org/platform-driver-x86/53c5075b-1967-45d0-937f-463912dd966d@gmx.de [1] Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/design-guide [2] Link: https://github.com/joshuagrisham/samsung-galaxybook-extras/tree/8e3087a06b8bdcdfdd081367af4b744a56cc4ee9/dsdt [3] Signed-off-by: Joshua Grisham Reviewed-by: Armin Wolf Link: https://patch.msgid.link/20250222094407.9753-1-josh@joshuagrisham.com Signed-off-by: Rafael J. Wysocki Stable-dep-of: d91a1d129b63 ("ACPI: fan: Use platform device for devres-related actions") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ab574f883307cab920fd0663c40a416231741983 Author: Ivan Lipski Date: Wed Sep 17 11:00:02 2025 -0400 drm/amd/display: Fix incorrect return of vblank enable on unconfigured crtc commit b3656b355b5522cef1b52a7469010009c98156db upstream. [Why&How] Return -EINVAL when userspace asks us to enable vblank on a crtc that is not yet enabled. Suggested-by: Aurabindo Pillai Reviewed-by: Aurabindo Pillai Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1856 Signed-off-by: Ivan Lipski Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit cb57b8cdb072dc37723b6906da1c37ff9cbc2da4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3daad56d20db357e9c5c1b4b09b323141cd546f5 Author: Mario Limonciello Date: Thu Oct 16 13:55:27 2025 -0500 drm/amd: Check that VPE has reached DPM0 in idle handler commit ba10f8d92a2c026b1052b4c0fa2cd7538838c965 upstream. [Why] Newer VPE microcode has functionality that will decrease DPM level only when a workload has run for 2 or more seconds. If VPE is turned off before this DPM decrease and the PMFW doesn't reset it when power gating VPE, the SOC can get stuck with a higher DPM level. This can happen from amdgpu's ring buffer test because it's a short quick workload for VPE and VPE is turned off after 1s. [How] In idle handler besides checking fences are drained check PMFW version to determine if it will reset DPM when power gating VPE. If PMFW will not do this, then check VPE DPM level. If it is not DPM0 reschedule delayed work again until it is. v2: squash in return fix (Alex) Cc: Peyton.Lee@amd.com Reported-by: Sultan Alsawaf Reviewed-by: Sultan Alsawaf Tested-by: Sultan Alsawaf Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4615 Reviewed-by: Lijo Lazar Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 3ac635367eb589bee8edcc722f812a89970e14b7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit aeb1cf1e8db36938a54c01ed509a7dcab17bfa8b Author: Thomas Zimmermann Date: Fri Oct 24 09:35:53 2025 +0200 drm/ast: Clear preserved bits from register output value commit a9fb41b5def8e1e0103d5fd1453787993587281e upstream. Preserve the I/O register bits in __ast_write8_i_masked() as specified by preserve_mask. Accidentally OR-ing the output value into these will overwrite the register's previous settings. Fixes display output on the AST2300, where the screen can go blank at boot. The driver's original commit 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") already added the broken code. Commit 6f719373b943 ("drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off") triggered the bug. Signed-off-by: Thomas Zimmermann Reported-by: Peter Schneider Closes: https://lore.kernel.org/dri-devel/a40caf8e-58ad-4f9c-af7f-54f6f69c29bb@googlemail.com/ Tested-by: Peter Schneider Reviewed-by: Jocelyn Falempe Fixes: 6f719373b943 ("drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off") Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Thomas Zimmermann Cc: Nick Bowler Cc: Douglas Anderson Cc: Dave Airlie Cc: Jocelyn Falempe Cc: dri-devel@lists.freedesktop.org Cc: # v3.5+ Link: https://patch.msgid.link/20251024073626.129032-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 0142fe895986addf35885b43440718e567121155 Author: Johan Hovold Date: Mon Oct 6 11:39:37 2025 +0200 drm/mediatek: Fix device use-after-free on unbind commit 926d002e6d7e2f1fd5c1b53cf6208153ee7d380d upstream. A recent change fixed device reference leaks when looking up drm platform device driver data during bind() but failed to remove a partial fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix kobject put for component sub-drivers"). This results in a reference imbalance on component bind() failures and on unbind() which could lead to a user-after-free. Make sure to only drop the references after retrieving the driver data by effectively reverting the previous partial fix. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") Reported-by: Sjoerd Simons Closes: https://lore.kernel.org/r/20251003-mtk-drm-refcount-v1-1-3b3f2813b0db@collabora.com Cc: stable@vger.kernel.org Cc: Ma Ke Cc: AngeloGioacchino Del Regno Signed-off-by: Johan Hovold Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Sjoerd Simons Tested-by: Sjoerd Simons Tested-by: Ritesh Raj Sarraf Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20251006093937.27869-1-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 23c3745dba57a0a3d18d7370d7f840144fed55be Author: Philipp Stanner Date: Fri Oct 24 18:12:22 2025 +0200 drm/nouveau: Fix race in nouveau_sched_fini() commit e0023c8a74028739643aa14bd201c41a99866ca4 upstream. nouveau_sched_fini() uses a memory barrier before wait_event(). wait_event(), however, is a macro which expands to a loop which might check the passed condition several times. The barrier would only take effect for the first check. Replace the barrier with a function which takes the spinlock. Cc: stable@vger.kernel.org # v6.8+ Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Acked-by: Danilo Krummrich Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251024161221.196155-2-phasta@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3ec3d47e3a03d5f1fe663edafcf0051cf0460788 Author: David Rosca Date: Wed Oct 15 16:01:28 2025 +0200 drm/sched: avoid killing parent entity on child SIGKILL commit 9e8b3201c7302d5b522ba3535630bed21cc03c27 upstream. The DRM scheduler tracks who last uses an entity and when that process is killed blocks all further submissions to that entity. The problem is that we didn't track who initially created an entity, so when a process accidently leaked its file descriptor to a child and that child got killed, we killed the parent's entities. Avoid that and instead initialize the entities last user on entity creation. This also allows to drop the extra NULL check. Signed-off-by: David Rosca Signed-off-by: Christian König Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4568 Reviewed-by: Alex Deucher CC: stable@vger.kernel.org Acked-by: Philipp Stanner Link: https://lore.kernel.org/r/20251015140128.1470-1-christian.koenig@amd.com Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251015140128.1470-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit 6bdef5648a60e49d4a3b02461ab7ae3776877e77 Author: Thomas Zimmermann Date: Fri Oct 17 11:13:36 2025 +0200 drm/sysfb: Do not dereference NULL pointer in plane reset commit 14e02ed3876f4ab0ed6d3f41972175f8b8df3d70 upstream. The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier) Signed-off-by: Thomas Zimmermann Fixes: b71565022031 ("drm/gem: Export implementation of shadow-plane helpers") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/dri-devel/aPIDAsHIUHp_qSW4@stanley.mountain/ Cc: Thomas Zimmermann Cc: Melissa Wen Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Simona Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.15+ Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20251017091407.58488-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit c8788295ce5275eab1fc215134e9c5e10a353f01 Author: Matthew Brost Date: Tue Oct 21 17:55:37 2025 -0700 drm/xe: Do not wake device during a GT reset commit b3fbda1a630a9439c885b2a5dc5230cc49a87e9e upstream. Waking the device during a GT reset can lead to unintended memory allocation, which is not allowed since GT resets occur in the reclaim path. Prevent this by holding a PM reference while a reset is in flight. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20251022005538.828980-3-matthew.brost@intel.com (cherry picked from commit 480b358e7d8ef69fd8f1b0cad6e07c7d70a36ee4) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit 7eb7ee2bbd866b7fbd4305abc42b16bf0c3d12ae Author: Miaoqian Lin Date: Mon Oct 27 23:08:38 2025 +0800 s390/mm: Fix memory leak in add_marker() when kvrealloc() fails commit 07ad45e06b4039adf96882aefcb1d3299fb7c305 upstream. The function has a memory leak when kvrealloc() fails. The function directly assigns NULL to the markers pointer, losing the reference to the previously allocated memory. This causes kvfree() in pt_dump_init() to free NULL instead of the leaked memory. Fix by: 1. Using kvrealloc() uniformly for all allocations 2. Using a temporary variable to preserve the original pointer until allocation succeeds 3. Removing the error path that sets markers_cnt=0 to keep consistency between markers and markers_cnt Found via static analysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit a16e92f8d7dc7371e68f17a9926cb92d2244be7b Author: Alexey Klimov Date: Wed Oct 22 21:10:12 2025 +0100 regmap: slimbus: fix bus_context pointer in regmap init calls commit 434f7349a1f00618a620b316f091bd13a12bc8d2 upstream. Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two "Fixes" tags. While at this, also correct the same argument in __regmap_init_slimbus(). Fixes: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support") Cc: stable@vger.kernel.org Cc: Dmitry Baryshkov Cc: Ma Ke Cc: Steev Klimaszewski Cc: Srinivas Kandagatla Reviewed-by: Abel Vesa Signed-off-by: Alexey Klimov Reviewed-by: Dmitry Baryshkov Link: https://patch.msgid.link/20251022201013.1740211-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1b61a1da3d8105ea1be548c94c2856697eb7ffd1 Author: Dapeng Mi Date: Tue Oct 28 14:42:14 2025 +0800 perf/x86/intel: Fix KASAN global-out-of-bounds warning commit 0ba6502ce167fc3d598c08c2cc3b4ed7ca5aa251 upstream. When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80 The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue. Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions") Reported-by: Xudong Hao Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Zide Chen Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251028064214.1451968-1-dapeng1.mi@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f9caae663343b89b7b81b3cf63fb7344db47660f Author: Damien Le Moal Date: Mon Oct 27 09:27:33 2025 +0900 block: make REQ_OP_ZONE_OPEN a write operation commit 19de03b312d69a7e9bacb51c806c6e3f4207376c upstream. A REQ_OP_OPEN_ZONE request changes the condition of a sequential zone of a zoned block device to the explicitly open condition (BLK_ZONE_COND_EXP_OPEN). As such, it should be considered a write operation. Change this operation code to be an odd number to reflect this. The following operation numbers are changed to keep the numbering compact. No problems were reported without this change as this operation has no data. However, this unifies the zone operation to reflect that they modify the device state and also allows strengthening checks in the block layer, e.g. checking if this operation is not issued against a read-only device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1e84391707b5b1d4695d3330520c8adfe62366e0 Author: Damien Le Moal Date: Mon Oct 27 09:27:32 2025 +0900 block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL commit 12a1c9353c47c0fb3464eba2d78cdf649dee1cf7 upstream. REQ_OP_ZONE_RESET_ALL is a zone management request. Fix op_is_zone_mgmt() to return true for that operation, like it already does for REQ_OP_ZONE_RESET. While no problems were reported without this fix, this change allows strengthening checks in various block device drivers (scsi sd, virtioblk, DM) where op_is_zone_mgmt() is used to verify that a zone management command is not being issued to a regular block device. Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a53c8e15153a3768959f7b55c566e682ee53f8f4 Author: Armin Wolf Date: Wed Oct 8 01:41:44 2025 +0200 ACPI: fan: Use ACPI handle when retrieving _FST commit 58764259ebe0c9efd569194444629f6b26f86583 upstream. Usage of the ACPI device should be phased out in the future, as the driver itself is now using the platform bus. Replace any usage of struct acpi_device in acpi_fan_get_fst() to allow users to drop usage of struct acpi_device. Also extend the integer check to all three package elements. Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20251007234149.2769-2-W_Armin@gmx.de Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ba58efa890cc8c9df8e072397ad153f04d06c24b Author: John Smith Date: Tue Oct 21 11:09:09 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland [ Upstream commit 501672e3c1576aa9a8364144213c77b98a31a42c ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Signed-off-by: John Smith Signed-off-by: Alex Deucher (cherry picked from commit 92b0a6ae6672857ddeabf892223943d2f0e06c97) Signed-off-by: Sasha Levin commit 6f18f14eb3edf5b89c07bd179ecfdb43a02b4a31 Author: John Smith Date: Tue Oct 21 11:08:13 2025 +0200 drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji [ Upstream commit 07a13f913c291d6ec72ee4fc848d13ecfdc0e705 ] Previously this was initialized with zero which represented PCIe Gen 1.0 instead of using the maximum value from the speed table which is the behaviour of all other smumgr implementations. Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.") Signed-off-by: John Smith Signed-off-by: Alex Deucher (cherry picked from commit c52238c9fb414555c68340cd80e487d982c1921c) Signed-off-by: Sasha Levin commit 3545f3cb517c1440eb7d7c503c71be95ae395574 Author: Yang Wang Date: Wed Oct 22 14:12:21 2025 +0800 drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table() [ Upstream commit 238d468d3ed18a324bb9d8c99f18c665dbac0511 ] 'table_index' is a variable defined by the smu driver (kmd) 'table_id' is a variable defined by the hw smu (pmfw) This code should use table_index as a bounds check. Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c") Signed-off-by: Yang Wang Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher (cherry picked from commit fca0c66b22303de0d1d6313059baf4dc960a4753) Signed-off-by: Sasha Levin commit 2fa41445d8c98f2a65503c373796466496edc0e7 Author: Daniel Palmer Date: Sat Oct 18 14:44:51 2025 +0900 drm/radeon: Remove calls to drm_put_dev() [ Upstream commit 745bae76acdd71709773c129a69deca01036250b ] Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd should be done by devres. However, drm_put_dev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drm_put_dev() after the driver already did it. [ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcount_t: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer Signed-off-by: Alex Deucher (cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4) Signed-off-by: Sasha Levin commit f7482516002a11317912e29577bbf33cf59a0fb1 Author: Daniel Palmer Date: Sat Oct 18 14:44:50 2025 +0900 drm/radeon: Do not kfree() devres managed rdev [ Upstream commit 3328443363a0895fd9c096edfe8ecd372ca9145e ] Since the allocation of the drivers main structure was changed to devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling kfree() on it. This fixes things exploding if the driver probe fails and devres cleans up the rdev after we already free'd it. Fixes: a9ed2f052c5c ("drm/radeon: change drm_dev_alloc to devm_drm_dev_alloc") Signed-off-by: Daniel Palmer Signed-off-by: Alex Deucher (cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b) Signed-off-by: Sasha Levin commit 3e8b6796df1e37eec3d3b1293d495dd3a80fdf5b Author: Maarten Zanders Date: Fri Oct 24 15:57:15 2025 +0200 ASoC: fsl_sai: Fix sync error in consumer mode [ Upstream commit b2dd1d0d322dce5f331961c927e775b84014d5ab ] When configured for default synchronisation (Rx syncs to Tx) and the SAI operates in consumer mode (clocks provided externally to Tx), a synchronisation error occurs on Tx on the first attempt after device initialisation when the playback stream is started while a capture stream is already active. This results in channel shift/swap on the playback stream. Subsequent streams (ie after that first failing one) always work correctly, no matter the order, with or without the other stream active. This issue was observed (and fix tested) on an i.MX6UL board connected to an ADAU1761 codec, where the codec provides both frame and bit clock (connected to TX pins). To fix this, always initialize the 'other' xCR4 and xCR5 registers when we're starting a stream which is synced to the opposite one, irregardless of the producer/consumer status. Fixes: 51659ca069ce ("ASoC: fsl-sai: set xCR4/xCR5/xMR for SAI master mode") Signed-off-by: Maarten Zanders Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20251024135716.584265-1-maarten@zanders.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8fe39c8387d848d7ab1f7251e61bada81bfddb1c Author: Petr Oros Date: Fri Oct 24 20:55:12 2025 +0200 dpll: spec: add missing module-name and clock-id to pin-get reply [ Upstream commit 520ad9e96937e825a117e9f00dd35a3e199d67b5 ] The dpll.yaml spec incorrectly omitted module-name and clock-id from the pin-get operation reply specification, even though the kernel DPLL implementation has always included these attributes in pin-get responses since the initial implementation. This spec inconsistency caused issues with the C YNL code generator. The generated dpll_pin_get_rsp structure was missing these fields. Fix the spec by adding module-name and clock-id to the pin-attrs reply specification to match the actual kernel behavior. Fixes: 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML") Signed-off-by: Petr Oros Reviewed-by: Ivan Vecera Link: https://patch.msgid.link/20251024185512.363376-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97b34c9765cbb0a6f746e892aa4bcbd16670d95d Author: Abdun Nihaal Date: Thu Oct 23 19:48:42 2025 +0530 sfc: fix potential memory leak in efx_mae_process_mport() [ Upstream commit 46a499aaf8c27476fd05e800f3e947bfd71aa724 ] In efx_mae_enumerate_mports(), memory allocated for mae_mport_desc is passed as a argument to efx_mae_process_mport(), but when the error path in efx_mae_process_mport() gets executed, the memory allocated for desc gets leaked. Fix that by freeing the memory allocation before returning error. Fixes: a6a15aca4207 ("sfc: enumerate mports in ef100") Acked-by: Edward Cree Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20251023141844.25847-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 95f1e4ecf7df10e31eed2f64172e0a0ce339051e Author: Jijie Shao Date: Thu Oct 23 21:13:37 2025 +0800 net: hns3: return error code when function fails [ Upstream commit 03ca7c8c42be913529eb9f188278114430c6abbd ] Currently, in hclge_mii_ioctl(), the operation to read the PHY register (SIOCGMIIREG) always returns 0. This patch changes the return type of hclge_read_phy_reg(), returning an error code when the function fails. Fixes: 024712f51e57 ("net: hns3: add ioctl support for imp-controlled PHYs") Signed-off-by: Jijie Shao Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20251023131338.2642520-2-shaojijie@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6294e03caef26f3f32e10e1c6a92177bfbd132fb Author: Petr Oros Date: Fri Oct 24 15:24:38 2025 +0200 tools: ynl: fix string attribute length to include null terminator [ Upstream commit 65f9c4c5888913c2cf5d2fc9454c83f9930d537d ] The ynl_attr_put_str() function was not including the null terminator in the attribute length calculation. This caused kernel to reject CTRL_CMD_GETFAMILY requests with EINVAL: "Attribute failed policy validation". For a 4-character family name like "dpll": - Sent: nla_len=8 (4 byte header + 4 byte string without null) - Expected: nla_len=9 (4 byte header + 5 byte string with null) The bug was introduced in commit 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") when refactoring from stpcpy() to strlen(). The original code correctly included the null terminator: end = stpcpy(ynl_attr_data(attr), str); attr->nla_len = NLA_HDRLEN + NLA_ALIGN(end - (char *)ynl_attr_data(attr)); Since stpcpy() returns a pointer past the null terminator, the length included it. The refactored version using strlen() omitted the +1. The fix also removes NLA_ALIGN() from nla_len calculation, since nla_len should contain actual attribute length, not aligned length. Alignment is only for calculating next attribute position. This makes the code consistent with ynl_attr_put(). CTRL_ATTR_FAMILY_NAME uses NLA_NUL_STRING policy which requires null terminator. Kernel validates with memchr() and rejects if not found. Fixes: 15d2540e0d62 ("tools: ynl: check for overflow of constructed messages") Signed-off-by: Petr Oros Tested-by: Ivan Vecera Reviewed-by: Ivan Vecera Link: https://lore.kernel.org/20251018151737.365485-3-zahari.doychev@linux.com Link: https://patch.msgid.link/20251024132438.351290-1-poros@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8fe83fad4bb66e8909f03ef41e9dd9ba85c20774 Author: Tomeu Vizoso Date: Tue Oct 21 11:37:23 2025 +0200 drm/etnaviv: fix flush sequence logic [ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ] The current logic uses the flush sequence from the current address space. This is harmless when deducing the flush requirements for the current submit, as either the incoming address space is the same one as the currently active one or we switch context, in which case the flush is unconditional. However, this sequence is also stored as the current flush sequence of the GPU. If we switch context the stored flush sequence will no longer belong to the currently active address space. This incoherency can then cause missed flushes, resulting in translation errors. Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling") Signed-off-by: Tomeu Vizoso Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin commit 20897a8fa66c1a28848ada896594340f7ff6e718 Author: Luiz Augusto von Dentz Date: Wed Oct 22 16:03:19 2025 -0400 Bluetooth: hci_core: Fix tracking of periodic advertisement [ Upstream commit 751463ceefc3397566d03c8b64ef4a77f5fd88ac ] Periodic advertising enabled flag cannot be tracked by the enabled flag since advertising and periodic advertising each can be enabled/disabled separately from one another causing the states to be inconsistent when for example an advertising set is disabled its enabled flag is set to false which is then used for periodic which has not being disabled. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b10f8ff2231c3be38044af7d98bb71d44378e1c4 Author: Luiz Augusto von Dentz Date: Tue Oct 7 13:29:15 2025 -0400 Bluetooth: ISO: Fix another instance of dst_type handling [ Upstream commit c403da5e98b04a2aec9cfb25cbeeb28d7ce29975 ] Socket dst_type cannot be directly assigned to hci_conn->type since there domain is different which may lead to the wrong address type being used. Fixes: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3a9dfe641913b37899dff61b469e5956274cc7f6 Author: Luiz Augusto von Dentz Date: Wed Oct 1 10:55:58 2025 -0400 Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00 [ Upstream commit 0d92808024b4e9868cef68d16f121d509843e80e ] This fixes the state tracking of advertisement set/instance 0x00 which is considered a legacy instance and is not tracked individually by adv_instances list, previously it was assumed that hci_dev itself would track it via HCI_LE_ADV but that is a global state not specifc to instance 0x00, so to fix it a new flag is introduced that only tracks the state of instance 0x00. Fixes: 1488af7b8b5f ("Bluetooth: hci_sync: Fix hci_resume_advertising_sync") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cd7a128032973f5de2675b0b4daba2d002a514fb Author: Chris Lu Date: Tue Sep 30 13:39:33 2025 +0800 Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during reset [ Upstream commit 77343b8b4f87560f8f03e77b98a81ff3a147b262 ] This patch adds logic to handle power management control when the Bluetooth function is closed during the SDIO reset sequence. Specifically, if BT is closed before reset, the driver enables the SDIO function and sets driver pmctrl. After reset, if BT remains closed, the driver sets firmware pmctrl and disables the SDIO function. These changes ensure proper power management and device state consistency across the reset flow. Fixes: 8fafe702253d ("Bluetooth: mt7921s: support bluetooth reset mechanism") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit fd25c5bb96b3149b7de7b9b994fbae590be21e32 Author: Luiz Augusto von Dentz Date: Fri Sep 26 11:48:50 2025 -0400 Bluetooth: ISO: Fix BIS connection dst_type handling [ Upstream commit f0c200a4a537f8f374584a974518b0ce69eda76c ] Socket dst_type cannot be directly assigned to hci_conn->type since there domain is different which may lead to the wrong address type being used. Fixes: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 825ce373fd709abeda79bd6ff5211536f41922cf Author: Iulia Tanasescu Date: Fri Nov 1 10:23:39 2024 +0200 Bluetooth: ISO: Update hci_conn_hash_lookup_big for Broadcast slave [ Upstream commit 83d328a72eff3268ea4c19deb0a6cf4c7da15746 ] Currently, hci_conn_hash_lookup_big only checks for BIS master connections, by filtering out connections with the destination address set. This commit updates this function to also consider BIS slave connections, since it is also used for a Broadcast Receiver to set an available BIG handle before issuing the LE BIG Create Sync command. Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: f0c200a4a537 ("Bluetooth: ISO: Fix BIS connection dst_type handling") Signed-off-by: Sasha Levin commit ae76cf6c2c842944c6514c57df54d728f1916553 Author: Cen Zhang Date: Mon Sep 29 05:30:17 2025 +0000 Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once [ Upstream commit 09b0cd1297b4dbfe736aeaa0ceeab2265f47f772 ] hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently. Fixes: 505ea2b29592 ("Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue") Reported-by: Cen Zhang Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 2ce1de32e05445d77fc056f6ff8339cfb78a5f84 Author: Lizhi Xu Date: Wed Oct 22 10:40:07 2025 +0800 usbnet: Prevents free active kevent [ Upstream commit 420c84c330d1688b8c764479e5738bbdbf0a33de ] The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev(). Fixes: a69e617e533e ("usbnet: Fix linkwatch use-after-free on disconnect") Reported-by: Sam Sun Closes: https://syzkaller.appspot.com/bug?extid=8bfd7bcc98f7300afb84 Signed-off-by: Lizhi Xu Link: https://patch.msgid.link/20251022024007.1831898-1-lizhi.xu@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 10e2d2d16ab4802e35b4c8d7147aea715428fed9 Author: Andrii Nakryiko Date: Mon Oct 20 13:36:43 2025 -0700 libbpf: Fix powerpc's stack register definition in bpf_tracing.h [ Upstream commit 7221b9caf84b3294688228a19273d74ea19a2ee4 ] retsnoop's build on powerpc (ppc64le) architecture ([0]) failed due to wrong definition of PT_REGS_SP() macro. Looking at powerpc's implementation of stack unwinding in perf_callchain_user_64() clearly shows that stack pointer register is gpr[1]. Fix libbpf's definition of __PT_SP_REG for powerpc to fix all this. [0] https://kojipkgs.fedoraproject.org/work/tasks/1544/137921544/build.log Fixes: 138d6153a139 ("samples/bpf: Enable powerpc support") Signed-off-by: Andrii Nakryiko Reviewed-by: Naveen N Rao (AMD) Link: https://lore.kernel.org/r/20251020203643.989467-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 9c52bf5819c4a8682ff2168736c27b5239862815 Author: Shengjiu Wang Date: Thu Oct 23 14:45:37 2025 +0800 ASoC: fsl_sai: fix bit order for DSD format [ Upstream commit d9fbe5b0bf7e2d1e20d53e4e2274f9f61bdcca98 ] The DSD little endian format requires the msb first, because oldest bit is in msb. found this issue by testing with pipewire. Fixes: c111c2ddb3fd ("ASoC: fsl_sai: Add PDM daifmt support") Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20251023064538.368850-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca6d2b7aca778afbf8c0c4b330d10cb228c14052 Author: Cezary Rojewski Date: Thu Oct 23 11:23:47 2025 +0200 ASoC: Intel: avs: Disable periods-elapsed work when closing PCM [ Upstream commit 845f716dc5f354c719f6fda35048b6c2eca99331 ] avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors. Fixes: 0dbb186c3510 ("ASoC: Intel: avs: Update stream status in a separate thread") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20251023092348.3119313-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 25a4d105a9bd0a7df5c0c9862b6effc619a37105 Author: Cezary Rojewski Date: Thu Oct 23 11:23:46 2025 +0200 ASoC: Intel: avs: Unprepare a stream when XRUN occurs [ Upstream commit cfca1637bc2b6b1e4f191d2f0b25f12402fbbb26 ] The pcm->prepare() function may be called multiple times in a row by the userspace, as mentioned in the documentation. The driver shall take that into account and prevent redundancy. However, the exact same function is called during XRUNs and in such case, the particular stream shall be reset and setup anew. Fixes: 9114700b496c ("ASoC: Intel: avs: Generic PCM FE operations") Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20251023092348.3119313-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29d0504077044a7e1ffbd09a6118018d5954a6e5 Author: Haotian Zhang Date: Mon Oct 20 18:11:09 2025 +0800 crypto: aspeed - fix double free caused by devm [ Upstream commit 3c9bf72cc1ced1297b235f9422d62b613a3fdae9 ] The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove(). Fixes: 2f1cf4e50c95 ("crypto: aspeed - Add ACRY RSA driver") Signed-off-by: Haotian Zhang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8df22e4bb6d8861bd094b77d2e0d6a7c50d1a464 Author: Ondrej Mosnacek Date: Tue Oct 21 14:27:58 2025 +0200 bpf: Do not audit capability check in do_jit() [ Upstream commit 881a9c9cb7856b24e390fad9f59acfd73b98b3b2 ] The failure of this check only results in a security mitigation being applied, slightly affecting performance of the compiled BPF program. It doesn't result in a failed syscall, an thus auditing a failed LSM permission check for it is unwanted. For example with SELinux, it causes a denial to be reported for confined processes running as root, which tends to be flagged as a problem to be fixed in the policy. Yet dontauditing or allowing CAP_SYS_ADMIN to the domain may not be desirable, as it would allow/silence also other checks - either going against the principle of least privilege or making debugging potentially harder. Fix it by changing it from capable() to ns_capable_noaudit(), which instructs the LSMs to not audit the resulting denials. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2369326 Fixes: d4e89d212d40 ("x86/bpf: Call branch history clearing sequence on exit") Signed-off-by: Ondrej Mosnacek Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20251021122758.2659513-1-omosnace@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 0efcafd48d25222ac58d8e44f50b8d8e20c5ecd3 Author: Yonghong Song Date: Tue Nov 12 08:39:17 2024 -0800 bpf, x86: Avoid repeated usage of bpf_prog->aux->stack_depth [ Upstream commit f4b21ed0b9d6c9fe155451a1fb3531fb44b0afa8 ] Refactor the code to avoid repeated usage of bpf_prog->aux->stack_depth in do_jit() func. If the private stack is used, the stack_depth will be 0 for that prog. Refactoring make it easy to adjust stack_depth. Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20241112163917.2224189-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Stable-dep-of: 881a9c9cb785 ("bpf: Do not audit capability check in do_jit()") Signed-off-by: Sasha Levin commit 40f5c9fc6689493b6a4d31b26a026784c801fa62 Author: Yonghong Song Date: Tue Nov 12 08:39:07 2024 -0800 bpf: Find eligible subprogs for private stack support [ Upstream commit a76ab5731e32d50ff5b1ae97e9dc4b23f41c23f5 ] Private stack will be allocated with percpu allocator in jit time. To avoid complexity at runtime, only one copy of private stack is available per cpu per prog. So runtime recursion check is necessary to avoid stack corruption. Current private stack only supports kprobe/perf_event/tp/raw_tp which has recursion check in the kernel, and prog types that use bpf trampoline recursion check. For trampoline related prog types, currently only tracing progs have recursion checking. To avoid complexity, all async_cb subprogs use normal kernel stack including those subprogs used by both main prog subtree and async_cb subtree. Any prog having tail call also uses kernel stack. To avoid jit penalty with private stack support, a subprog stack size threshold is set such that only if the stack size is no less than the threshold, private stack is supported. The current threshold is 64 bytes. This avoids jit penality if the stack usage is small. A useless 'continue' is also removed from a loop in func check_max_stack_depth(). Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20241112163907.2223839-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Stable-dep-of: 881a9c9cb785 ("bpf: Do not audit capability check in do_jit()") Signed-off-by: Sasha Levin commit 55a01a4777a01ba067485b6b6a22710099560fe4 Author: Wonkon Kim Date: Mon Oct 20 15:15:38 2025 +0900 scsi: ufs: core: Initialize value of an attribute returned by uic cmd [ Upstream commit 6fe4c679dde3075cb481beb3945269bb2ef8b19a ] If ufshcd_send_cmd() fails, *mib_val may have a garbage value. It can get an unintended value of an attribute. Make ufshcd_dme_get_attr() always initialize *mib_val. Fixes: 12b4fdb4f6bc ("[SCSI] ufs: add dme configuration primitives") Signed-off-by: Wonkon Kim Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20251020061539.28661-2-wkon.kim@samsung.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 10ca3b2eec384628bc9f5d8190aed9427ad2dde6 Author: Noorain Eqbal Date: Mon Oct 20 23:33:01 2025 +0530 bpf: Sync pending IRQ work before freeing ring buffer [ Upstream commit 4e9077638301816a7d73fa1e1b4c1db4a7e3b59c ] Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2617fc732430968b45d2 Tested-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com Signed-off-by: Noorain Eqbal Link: https://lore.kernel.org/r/20251020180301.103366-1-nooraineqbal@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 22aa7d1631e8a7acbd921aee707576ae8c579edd Author: Florian Schmaus Date: Fri Oct 17 11:28:14 2025 +0200 kunit: test_dev_action: Correctly cast 'priv' pointer to long* [ Upstream commit 2551a1eedc09f5a86f94b038dc1bb16855c256f1 ] The previous implementation incorrectly assumed the original type of 'priv' was void**, leading to an unnecessary and misleading cast. Correct the cast of the 'priv' pointer in test_dev_action() to its actual type, long*, removing an unnecessary cast. As an additional benefit, this fixes an out-of-bounds CHERI fault on hardware with architectural capabilities. The original implementation tried to store a capability-sized pointer using the priv pointer. However, the priv pointer's capability only granted access to the memory region of its original long type, leading to a bounds violation since the size of a long is smaller than the size of a capability. This change ensures that the pointer usage respects the capabilities' bounds. Link: https://lore.kernel.org/r/20251017092814.80022-1-florian.schmaus@codasip.com Fixes: d03c720e03bd ("kunit: Add APIs for managing devices") Reviewed-by: David Gow Signed-off-by: Florian Schmaus Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 5596a90c8952bd6425e4ec850a3ce4251cfdc99b Author: Johannes Berg Date: Sun Oct 19 11:54:27 2025 +0300 wifi: mac80211: fix key tailroom accounting leak [ Upstream commit ed6a47346ec69e7f1659e0a1a3558293f60d5dd7 ] For keys added by ieee80211_gtk_rekey_add(), we assume that they're already present in the hardware and set the flag KEY_FLAG_UPLOADED_TO_HARDWARE. However, setting this flag needs to be paired with decrementing the tailroom needed, which was missed. Fixes: f52a0b408ed1 ("wifi: mac80211: mark keys as uploaded when added by the driver") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20251019115358.c88eafb4083e.I69e9d4d78a756a133668c55b5570cf15a4b0e6a4@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 23b8682f05ec545619711eb3572acd9484157bd8 Author: Miri Korenblit Date: Wed Jul 9 23:38:00 2025 +0300 wifi: mac80211: don't mark keys for inactive links as uploaded [ Upstream commit 63df3956903748c5f374a0dfe7a89490714a4625 ] During resume, the driver can call ieee80211_add_gtk_rekey for keys that are not programmed into the device, e.g. keys of inactive links. Don't mark such a key as uploaded to avoid removing it later from the driver/device. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20250709233537.655094412b0b.Iacae31af3ba2a705da0a9baea976c2f799d65dc4@changeid Signed-off-by: Johannes Berg Stable-dep-of: ed6a47346ec6 ("wifi: mac80211: fix key tailroom accounting leak") Signed-off-by: Sasha Levin commit c06a402459b15803fac2154587fd35040622689a Author: Richard Fitzgerald Date: Thu Oct 16 10:48:44 2025 +0100 ASoC: cs-amp-lib-test: Fix missing include of kunit/test-bug.h [ Upstream commit ec20584f25233bfe292c8e18f9a429dfaff58a49 ] cs-amp-lib-test uses functions from kunit/test-bug.h but wasn't including it. This error was found by smatch. Fixes: 177862317a98 ("ASoC: cs-amp-lib: Add KUnit test for calibration helpers") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20251016094844.92796-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c903a5848d814779c65a3bbd8d34fade3fee8bec Author: Roy Vegard Ovesen Date: Sat Oct 18 19:18:22 2025 +0200 ALSA: usb-audio: fix control pipe direction [ Upstream commit 7963891f7c9c6f759cc9ab7da71406b4234f3dd6 ] Since the requesttype has USB_DIR_OUT the pipe should be constructed with usb_sndctrlpipe(). Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Signed-off-by: Roy Vegard Ovesen Link: https://patch.msgid.link/aPPL3tBFE_oU-JHv@ark Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 411b8b9c9cf816e1d29eea22eb781e2b09c4a889 Author: Akhil P Oommen Date: Thu Sep 11 02:14:05 2025 +0530 drm/msm/a6xx: Fix GMU firmware parser [ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ] Current parser logic for GMU firmware assumes a dword aligned payload size for every block. This is not true for all GMU firmwares. So, fix this by using correct 'size' value in the calculation for the offset for the next block's header. Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path") Signed-off-by: Akhil P Oommen Acked-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/674040/ Message-ID: <20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com> Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e3373f10c6a6c92aaf415b07171c6710c9d86a3f Author: Rameshkumar Sundaram Date: Fri Oct 3 14:51:58 2025 +0530 wifi: ath11k: avoid bit operation on key flags [ Upstream commit 9c78e747dd4fee6c36fcc926212e20032055cf9d ] Bitwise operations with WMI_KEY_PAIRWISE (defined as 0) are ineffective and misleading. This results in pairwise key validations added in commit 97acb0259cc9 ("wifi: ath11k: fix group data packet drops during rekey") to always evaluate false and clear key commands for pairwise keys are not honored. Since firmware supports overwriting the new key without explicitly clearing the previous one, there is no visible impact currently. However, to restore consistency with the previous behavior and improve clarity, replace bitwise operations with direct assignments and comparisons for key flags. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1 Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-wireless/aLlaetkalDvWcB7b@stanley.mountain Fixes: 97acb0259cc9 ("wifi: ath11k: fix group data packet drops during rekey") Signed-off-by: Rameshkumar Sundaram Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20251003092158.1080637-1-rameshkumar.sundaram@oss.qualcomm.com [update copyright per current guidance] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 50f50dd024b4d9279e5a9eaedb24b5962f72f801 Author: Yu Zhang(Yuriy) Date: Fri Jan 24 14:13:43 2025 +0800 wifi: ath11k: add support for MU EDCA [ Upstream commit b78c02f7c7104f1e77ade12ebde267e6fb388ca9 ] The current code does not have the MU EDCA feature, so it cannot support the use of EDCA by STA in specific UL MU HE TB PPDU transmissions. Refer to IEEE Std 802.11ax-2021 "9.4.2.251 MU EDCA Parameter Set element", "26.2.7 EDCA operation using MU EDCA parameters". Add ath11k_mac_op_conf_tx_mu_edca() to construct the MU EDCA parameters received from mac80211 into WMI WMM parameters，and send to the firmware according to the different WMM type flags. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04523-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Signed-off-by: Yu Zhang (Yuriy) Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20250124061343.2263467-1-quic_yuzha@quicinc.com Signed-off-by: Jeff Johnson Stable-dep-of: 9c78e747dd4f ("wifi: ath11k: avoid bit operation on key flags") Signed-off-by: Sasha Levin commit 2a6cd5951ba8e5ddaebf8c507c655e6f31fc8f91 Author: Karthik M Date: Tue Sep 23 15:03:16 2025 -0700 wifi: ath12k: free skb during idr cleanup callback [ Upstream commit 92282074e1d2e7b6da5c05fe38a7cc974187fe14 ] ath12k just like ath11k [1] did not handle skb cleanup during idr cleanup callback. Both ath12k_mac_vif_txmgmt_idr_remove() and ath12k_mac_tx_mgmt_pending_free() performed idr cleanup and DMA unmapping for skb but only ath12k_mac_tx_mgmt_pending_free() freed skb. As a result, during vdev deletion a memory leak occurs. Refactor all clean up steps into a new function. New function ath12k_mac_tx_mgmt_free() creates a centralized area where idr cleanup, DMA unmapping for skb and freeing skb is performed. Utilize skb pointer given by idr_remove(), instead of passed as a function argument because IDR will be protected by locking. This will prevent concurrent modification of the same IDR. Now ath12k_mac_tx_mgmt_pending_free() and ath12k_mac_vif_txmgmt_idr_remove() call ath12k_mac_tx_mgmt_free(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Link: https://lore.kernel.org/r/1637832614-13831-1-git-send-email-quic_srirrama@quicinc.com > # [1] Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Karthik M Signed-off-by: Muna Sinada Reviewed-by: Vasanthakumar Thiagarajan Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250923220316.1595758-1-muna.sinada@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 775e37df2acc36ceb8c7bb82147ea6e2251dae5b Author: Mark Pearson Date: Mon Sep 29 15:21:35 2025 -0400 wifi: ath11k: Add missing platform IDs for quirk table [ Upstream commit 0eb002c93c3b47f88244cecb1e356eaeab61a6bf ] Lenovo platforms can come with one of two different IDs. The pm_quirk table was missing the second ID for each platform. Add missing ID and some extra platform identification comments. Reported on https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: P14s G4 AMD. Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model") Signed-off-by: Mark Pearson Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219196 Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250929192146.1789648-1-mpearson-lenovo@squebb.ca Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit c4840991ee4cc9e70a01197bfd53e4c69988dbb9 Author: Loic Poulain Date: Fri Sep 26 21:56:56 2025 +0200 wifi: ath10k: Fix memory leak on unsupported WMI command [ Upstream commit 2e9c1da4ee9d0acfca2e0a3d78f3d8cb5802da1b ] ath10k_wmi_cmd_send takes ownership of the passed buffer (skb) and has the responsibility to release it in case of error. This patch fixes missing free in case of early error due to unhandled WMI command ID. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Fixes: 553215592f14 ("ath10k: warn if give WMI command is not supported") Suggested-by: Jeff Johnson Signed-off-by: Loic Poulain Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20250926195656.187970-1-loic.poulain@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 5b2619b488f1d08b960c43c6468dd0759e8b3035 Author: Chang S. Bae Date: Mon Jun 9 17:16:59 2025 -0700 x86/fpu: Ensure XFD state on signal delivery commit 388eff894d6bc5f921e9bfff0e4b0ab2684a96e9 upstream. Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson Signed-off-by: Chang S. Bae Signed-off-by: Dave Hansen Reviewed-by: Chao Gao Tested-by: Chao Gao Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com Signed-off-by: Greg Kroah-Hartman commit 327f89c21601ebb7889f8c97754b76f08ce95a0c Author: Henrique Carvalho Date: Mon Oct 27 18:29:19 2025 -0300 smb: client: fix potential cfid UAF in smb2_query_info_compound commit 5c76f9961c170552c1d07c830b5e145475151600 upstream. When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80 Cc: stable@kernel.org Fixes: 4f1fffa237692 ("cifs: commands that are retried should have replay flag set") Reviewed-by: Paulo Alcantara (Red Hat) Acked-by: Shyam Prasad N Reviewed-by: Enzo Matsumiya Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d13fe1d330aa54efd275aac7cda69754cd032f08 Author: Farhan Ali Date: Wed Oct 22 09:47:26 2025 -0700 s390/pci: Restore IRQ unconditionally for the zPCI device commit b45873c3f09153d1ad9b3a7bf9e5c0b0387fd2ea upstream. Commit c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()"), introduced the zpci_set_irq() and zpci_clear_irq(), to be used while resetting a zPCI device. Commit da995d538d3a ("s390/pci: implement reset_slot for hotplug slot"), mentions zpci_clear_irq() being called in the path for zpci_hot_reset_device(). But that is not the case anymore and these functions are not called outside of this file. Instead zpci_hot_reset_device() relies on zpci_disable_device() also clearing the IRQs, but misses to reset the zdev->irqs_registered flag. However after a CLP disable/enable reset, the device's IRQ are unregistered, but the flag zdev->irq_registered does not get cleared. It creates an inconsistent state and so arch_restore_msi_irqs() doesn't correctly restore the device's IRQ. This becomes a problem when a PCI driver tries to restore the state of the device through pci_restore_state(). Restore IRQ unconditionally for the device and remove the irq_registered flag as its redundant. Fixes: c1e18c17bda6 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()") Cc: stable@vger.kernnel.org Reviewed-by: Niklas Schnelle Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit ae68e814f213c2f78dcb6b67f9e95c194245cc0d Author: Srinivas Kandagatla Date: Fri Oct 17 09:52:56 2025 +0100 ASoC: qdsp6: q6asm: do not sleep while atomic commit fdbb53d318aa94a094434e5f226617f0eb1e8f22 upstream. For some reason we ended up kfree between spinlock lock and unlock, which can sleep. move the kfree out of spinlock section. Fixes: a2a5d30218fd ("ASoC: qdsp6: q6asm: Add support to memory map and unmap") Cc: Stable@vger.kernel.org Signed-off-by: Srinivas Kandagatla Link: https://patch.msgid.link/20251017085307.4325-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0c4f121c0e87e125627c283abbd763381b2befe0 Author: Paolo Abeni Date: Tue Oct 28 09:16:54 2025 +0100 mptcp: restore window probe commit a824084b98d8a1dbd6e85d0842a8eb5e73467f59 upstream. Since commit 72377ab2d671 ("mptcp: more conservative check for zero probes") the MPTCP-level zero window probe check is always disabled, as the TCP-level write queue always contains at least the newly allocated skb. Refine the relevant check tacking in account that the above condition and that such skb can have zero length. Fixes: 72377ab2d671 ("mptcp: more conservative check for zero probes") Cc: stable@vger.kernel.org Reported-by: Geliang Tang Closes: https://lore.kernel.org/d0a814c364e744ca6b836ccd5b6e9146882e8d42.camel@kernel.org Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Tested-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251028-net-mptcp-send-timeout-v1-3-38ffff5a9ec8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0aee3dd83edece6c323a1efc37af38ac372338b2 Author: Paolo Abeni Date: Tue Oct 28 09:16:52 2025 +0100 mptcp: drop bogus optimization in __mptcp_check_push() commit 27b0e701d3872ba59c5b579a9e8a02ea49ad3d3b upstream. Accessing the transmit queue without owning the msk socket lock is inherently racy, hence __mptcp_check_push() could actually quit early even when there is pending data. That in turn could cause unexpected tx lock and timeout. Dropping the early check avoids the race, implicitly relaying on later tests under the relevant lock. With such change, all the other mptcp_send_head() call sites are now under the msk socket lock and we can additionally drop the now unneeded annotation on the transmit head pointer accesses. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Geliang Tang Tested-by: Geliang Tang Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251028-net-mptcp-send-timeout-v1-1-38ffff5a9ec8@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3ea7b3a6971c1c5916819d506a11a22631acb6a5 Author: Miaoqian Lin Date: Mon Oct 27 16:43:37 2025 +0800 fbdev: valkyriefb: Fix reference count leak in valkyriefb_init commit eb53368f8d6e2dfba84c8a94d245719bcf9ae270 upstream. The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Found via static analysis. Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit a22bcb7f104aaf89f9ab5deef41c1be3f8328b8c Author: Florian Fuchs Date: Sun Oct 26 00:38:50 2025 +0200 fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS commit 5f566c0ac51cd2474e47da68dbe719d3acf7d999 upstream. Commit e24cca19babe ("sh: Kill off MAX_DMA_ADDRESS leftovers.") removed the define ONCHIP_NR_DMA_CHANNELS. So that the leftover reference needs to be replaced by CONFIG_NR_ONCHIP_DMA_CHANNELS to compile successfully with CONFIG_PVR2_DMA enabled. Signed-off-by: Florian Fuchs Reviewed-by: John Paul Adrian Glaubitz Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a6eed58249e7d60f856900e682992300f770f64b Author: Gokul Sivakumar Date: Mon Oct 13 15:58:19 2025 +0530 wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream. Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. Cc: stable@vger.kernel.org Fixes: 18e2f61db3b7 ("brcmfmac: P2P action frame tx") Signed-off-by: Gokul Sivakumar Acked-by: Arend van Spriel Link: https://patch.msgid.link/20251013102819.9727-1-gokulkumar.sivakumar@infineon.com [Cc stable] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2fc54844566307cd9f430f3711681cde45506406 Author: Johan Hovold Date: Thu Oct 23 14:05:30 2025 +0200 Bluetooth: rfcomm: fix modem control handling commit 91d35ec9b3956d6b3cf789c1593467e58855b03a upstream. The RFCOMM driver confuses the local and remote modem control signals, which specifically means that the reported DTR and RTS state will instead reflect the remote end (i.e. DSR and CTS). This issue dates back to the original driver (and a follow-on update) merged in 2002, which resulted in a non-standard implementation of TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by mapping them to the RI and DCD input flags, while TIOCMGET failed to return the actual state of DTR and RTS. Note that the bogus control of input signals in tiocmset() is just dead code as those flags will have been masked out by the tty layer since 2003. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 901f44227072be60812fe8083e83e1533c04eed1 Author: Junjie Cao Date: Mon Oct 20 21:47:01 2025 +0800 fbdev: bitblit: bound-check glyph index in bit_putcs* commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream. bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot. Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2 Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com Signed-off-by: Junjie Cao Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e16d5c139ad96fcb4bc1914db04d3c8d2689d147 Author: Bui Quang Minh Date: Wed Oct 22 22:56:30 2025 +0700 virtio-net: drop the multi-buffer XDP packet in zerocopy commit 1ab665817448c31f4758dce43c455bd4c5e460aa upstream. In virtio-net, we have not yet supported multi-buffer XDP packet in zerocopy mode when there is a binding XDP program. However, in that case, when receiving multi-buffer XDP packet, we skip the XDP program and return XDP_PASS. As a result, the packet is passed to normal network stack which is an incorrect behavior (e.g. a XDP program for packet count is installed, multi-buffer XDP packet arrives and does go through XDP program. As a result, the packet count does not increase but the packet is still received from network stack).This commit instead returns XDP_ABORTED in that case. Fixes: 99c861b44eb1 ("virtio_net: xsk: rx: support recv merge mode") Cc: stable@vger.kernel.org Acked-by: Jason Wang Reviewed-by: Xuan Zhuo Signed-off-by: Bui Quang Minh Link: https://patch.msgid.link/20251022155630.49272-1-minhquangbui99@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6fb16571a6d5cde9d013e2a338ef7f6323a4528b Author: Kaushlendra Kumar Date: Mon Oct 6 14:17:06 2025 +0530 ACPI: button: Call input_free_device() on failing input device registration commit 20594cd104abaaabb676c7a2915b150ae5ff093d upstream. Make acpi_button_add() call input_free_device() when input_register_device() fails as required according to the documentation of the latter. Fixes: 0d51157dfaac ("ACPI: button: Eliminate the driver notify callback") Signed-off-by: Kaushlendra Kumar Cc: 6.5+ # 6.5+ [ rjw: Subject and changelog rewrite, Fixes: tag ] Link: https://patch.msgid.link/20251006084706.971855-1-kaushlendra.kumar@intel.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit de5fc93275a4a459fe2f7cb746984f2ab3e8292a Author: Yuhao Jiang Date: Wed Oct 22 15:07:04 2025 -0500 ACPI: video: Fix use-after-free in acpi_video_switch_brightness() commit 8f067aa59430266386b83c18b983ca583faa6a11 upstream. The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress") Cc: All applicable Signed-off-by: Yuhao Jiang Reviewed-by: Hans de Goede [ rjw: Changelog edit ] Link: https://patch.msgid.link/20251022200704.2655507-1-danisjiang@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9280286e048e0fe553da5fbdf0b31d26de7936db Author: Daniel Palmer Date: Fri Oct 24 18:37:15 2025 +0900 fbdev: atyfb: Check if pll_ops->init_pll failed commit 7073c7fc8d8ba47194e5fc58fcafc0efe7586e9b upstream. Actually check the return value from pll_ops->init_pll() as it can return an error. If the card's BIOS didn't run because it's not the primary VGA card the fact that the xclk source is unsupported is printed as shown below but the driver continues on regardless and on my machine causes a hard lock up. [ 61.470088] atyfb 0000:03:05.0: enabling device (0080 -> 0083) [ 61.476191] atyfb: using auxiliary register aperture [ 61.481239] atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27] [ 61.487569] atyfb: 512K SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK [ 61.496112] atyfb: Unsupported xclk source: 5. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Daniel Palmer Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c079d42f70109512eee49123a843be91d8fa133f Author: Quanmin Yan Date: Fri Oct 10 16:16:59 2025 +0800 fbcon: Set fb_display[i]->mode to NULL when the mode is released commit a1f3058930745d2b938b6b4f5bd9630dc74b26b7 upstream. Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL. Signed-off-by: Quanmin Yan Reviewed-by: Thomas Zimmermann Signed-off-by: Helge Deller Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 67051ecfce0500bea306ff0a7a3771702be40935 Author: Miaoqian Lin Date: Mon Oct 27 00:43:16 2025 +0800 net: usb: asix_devices: Check return value of usbnet_get_endpoints commit dc89548c6926d68dfdda11bebc1a5258bc41d887 upstream. The code did not check the return value of usbnet_get_endpoints. Add checks and return the error if it fails to transfer the error. Found via static anlaysis and this is similar to commit 07161b2416f7 ("sr9800: Add check for usbnet_get_endpoints"). Fixes: 933a27d39e0e ("USB: asix - Add AX88178 support and many other changes") Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin Link: https://patch.msgid.link/20251026164318.57624-1-linmq006@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a4948875ed0599c037dc438c11891c9012721b1d Author: Chuck Lever Date: Tue Sep 30 10:05:20 2025 -0400 NFSD: Fix crash in nfsd4_read_release() commit abb1f08a2121dd270193746e43b2a9373db9ad84 upstream. When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test. Fixes: 15a8b55dbb1b ("nfsd: call op_release, even when op_func returns an error") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman