summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-12crash: let architecture decide crash memory export to iomem_resourceSourabh Jain
With the generic crashkernel reservation, the kernel emits the following warning on powerpc: WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/mem.c:341 add_system_ram_resources+0xfc/0x180 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-auto-12607-g5472d60c129f #1 VOLUNTARY Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.01 (NH1110_069) hv:phyp pSeries NIP: c00000000201de3c LR: c00000000201de34 CTR: 0000000000000000 REGS: c000000127cef8a0 TRAP: 0700 Not tainted (6.17.0-auto-12607-g5472d60c129f) MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 84000840 XER: 20040010 CFAR: c00000000017eed0 IRQMASK: 0 GPR00: c00000000201de34 c000000127cefb40 c0000000016a8100 0000000000000001 GPR04: c00000012005aa00 0000000020000000 c000000002b705c8 0000000000000000 GPR08: 000000007fffffff fffffffffffffff0 c000000002db8100 000000011fffffff GPR12: c00000000201dd40 c000000002ff0000 c0000000000112bc 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000015a3808 GPR24: c00000000200468c c000000001699888 0000000000000106 c0000000020d1950 GPR28: c0000000014683f8 0000000081000200 c0000000015c1868 c000000002b9f710 NIP [c00000000201de3c] add_system_ram_resources+0xfc/0x180 LR [c00000000201de34] add_system_ram_resources+0xf4/0x180 Call Trace: add_system_ram_resources+0xf4/0x180 (unreliable) do_one_initcall+0x60/0x36c do_initcalls+0x120/0x220 kernel_init_freeable+0x23c/0x390 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c This warning occurs due to a conflict between crashkernel and System RAM iomem resources. The generic crashkernel reservation adds the crashkernel memory range to /proc/iomem during early initialization. Later, all memblock ranges are added to /proc/iomem as System RAM. If the crashkernel region overlaps with any memblock range, it causes a conflict while adding those memblock regions as iomem resources, triggering the above warning. The conflicting memblock regions are then omitted from /proc/iomem. For example, if the following crashkernel region is added to /proc/iomem: 20000000-11fffffff : Crash kernel then the following memblock regions System RAM regions fail to be inserted: 00000000-7fffffff : System RAM 80000000-257fffffff : System RAM Fix this by not adding the crashkernel memory to /proc/iomem on powerpc. Introduce an architecture hook to let each architecture decide whether to export the crashkernel region to /proc/iomem. For more info checkout commit c40dd2f766440 ("powerpc: Add System RAM to /proc/iomem") and commit bce074bdbc36 ("powerpc: insert System RAM resource to prevent crashkernel conflict") Note: Before switching to the generic crashkernel reservation, powerpc never exported the crashkernel region to /proc/iomem. Link: https://lkml.kernel.org/r/20251016142831.144515-1-sourabhjain@linux.ibm.com Fixes: e3185ee438c2 ("powerpc/crash: use generic crashkernel reservation"). Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Closes: https://lore.kernel.org/all/90937fe0-2e76-4c82-b27e-7b8a7fe3ac69@linux.ibm.com/ Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Cc: Baoquan he <bhe@redhat.com> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12.mailmap: add entry for WangYuliWangYuli
Map my old, obsolete work email address to my current email address. My current work email may not be ideal for timely communication, as it requires a secure network environment for access due to security policies. Therefore, associate both my previous and current work email addresses with an email address provided to me by AOSC Linux community. During work hours, my commits will likely still be authored using my company email address. Link: https://lkml.kernel.org/r/20251014050747.527357-1-wangyuli@aosc.io Signed-off-by: WangYuli <wangyl5933@chinaunicom.cn> Signed-off-by: WangYuli <wangyuli@aosc.io> Cc: Carlos Bilbao <carlos.bilbao@kernel.org> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Shannon Nelson <sln@onemain.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12lib/xz: remove dead IA-64 (Itanium) support codeAnkan Biswas
Support for the IA-64 (Itanium) architecture was removed in commit cf8e8658100d ("arch: Remove Itanium (IA-64) architecture"). This patch drops the IA-64 specific decompression code from lib/xz, which was conditionally compiled with the now-obsolete CONFIG_XZ_DEC_IA64 option. Link: https://lkml.kernel.org/r/20251014052738.31185-1-spyjetfayed@gmail.com Signed-off-by: Ankan Biswas <spyjetfayed@gmail.com> Reviewed-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Khalid Aziz <khalid@kernel.org> Acked-by: Lasse Collin <lasse.collin@tukaani.org> Cc: David Hunter <david.hunter.linux@gmail.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12hung_task: panic when there are more than N hung tasks at the same timeLi RongQing
The hung_task_panic sysctl is currently a blunt instrument: it's all or nothing. Panicking on a single hung task can be an overreaction to a transient glitch. A more reliable indicator of a systemic problem is when multiple tasks hang simultaneously. Extend hung_task_panic to accept an integer threshold, allowing the kernel to panic only when N hung tasks are detected in a single scan. This provides finer control to distinguish between isolated incidents and system-wide failures. The accepted values are: - 0: Don't panic (unchanged) - 1: Panic on the first hung task (unchanged) - N > 1: Panic after N hung tasks are detected in a single scan The original behavior is preserved for values 0 and 1, maintaining full backward compatibility. [lance.yang@linux.dev: new changelog] Link: https://lkml.kernel.org/r/20251015063615.2632-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Tested-by: Lance Yang <lance.yang@linux.dev> Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> [aspeed_g5_defconfig] Cc: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Hildenbrand <david@redhat.com> Cc: Florian Wesphal <fw@strlen.de> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: Joel Granados <joel.granados@kernel.org> Cc: Joel Stanley <joel@jms.id.au> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kees Cook <kees@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Paul E . McKenney" <paulmck@kernel.org> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Phil Auld <pauld@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Shuah Khan <shuah@kernel.org> Cc: Simon Horman <horms@kernel.org> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12compiler.h: remove ARCH_SEL()Thomas Weißschuh
Its last user was removed in commit 8ea815399c3f ("compiler: remove __ADDRESSABLE_ASM{_STR,}() again"). Link: https://lkml.kernel.org/r/20251013-arch-sel-v1-1-7eef9b22ceb0@linutronix.de Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12ocfs2: add extra consistency check to ocfs2_dx_dir_lookup_rec()Dmitry Antipov
In 'ocfs2_dx_dir_lookup_rec()', check whether an extent list length of the directory indexing block matches the one configured via the superblock parameters established at mount, thus preventing an out-of-bounds accesses while iterating over the extent records below. Link: https://lkml.kernel.org/r/20251007094626.196143-1-dmantipov@yandex.ru Reported-by: syzbot+30b53487d00b4f7f0922@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=30b53487d00b4f7f0922 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Reviewed-by: Heming Zhao <heming.zhao@suse.com>> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12ocfs2: annotate flexible array members with __counted_by_le()Dmitry Antipov
Annotate flexible array members of 'struct ocfs2_extent_list', 'struct ocfs2_chain_list', 'struct ocfs2_truncate_log', 'struct ocfs2_dx_entry_list', 'ocfs2_refcount_list' and 'struct ocfs2_xattr_header' with '__counted_by_le()' attribute to improve array bounds checking when CONFIG_UBSAN_BOUNDS is enabled. [dmantipov@yandex.ru: fix __counted_by_le() usage in ocfs2_expand_inline_dx_root()] Link: https://lkml.kernel.org/r/20251014070324.130313-1-dmantipov@yandex.ru Link: https://lkml.kernel.org/r/20251007123526.213150-1-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Reviewed-by: Heming Zhao <heming.zhao@suse.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12treewide: drop outdated compiler version remarks in Kconfig help textsLukas Bulwahn
As of writing, Documentation/Changes states the minimal versions of GNU C being 8.1, Clang being 15.0.0 and binutils being 2.30. A few Kconfig help texts are pointing out that specific GCC and Clang versions are needed, but by now, those pointers to versions, such later than 4.0, later than 4.4, or clang later than 5.0, are obsolete and unlikely to be found by users configuring their kernel builds anyway. Drop these outdated remarks in Kconfig help texts referring to older compiler and binutils versions. No functional change. Link: https://lkml.kernel.org/r/20251010082138.185752-1-lukas.bulwahn@redhat.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Cc: Bill Wendling <morbo@google.com> Cc: Justin Stitt <justinstitt@google.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Russel King <linux@armlinux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12MAINTAINERS: apply name and email address changes for MartinMartin Kepplinger-Novaković
Update to new surname addition and currently used email address. Link: https://lkml.kernel.org/r/20251011155903.7442-2-martink@posteo.de Signed-off-by: Martin Kepplinger-Novaković <martink@posteo.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12CREDITS: update Martin's informationMartin Kepplinger-Novaković
Surname, address, email and the description changed. Apply these updates. Link: https://lkml.kernel.org/r/20251011155903.7442-3-martink@posteo.de Signed-off-by: Martin Kepplinger-Novaković <martink@posteo.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12mailmap: update name and email addressesMartin Kepplinger-Novaković
Apply my new surname, remove unused and update to currently used email addresses. Link: https://lkml.kernel.org/r/20251011155903.7442-1-martink@posteo.de Signed-off-by: Martin Kepplinger-Novaković <martink@posteo.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12scs: fix a wrong parameter in __scs_magicZhichi Lin
__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is given. 'task_scs(tsk)' is the starting address of the task's shadow call stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's shadow call stack. Here should be '__scs_magic(task_scs(tsk))'. The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE is enabled, the shadow call stack usage checking function (scs_check_usage) would scan an incorrect memory range. This could lead to: 1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg. 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses). However, since this is purely a debugging feature (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled. Link: https://lkml.kernel.org/r/20251011082222.12965-1-zhichi.lin@vivo.com Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging") Signed-off-by: Jiyuan Xie <xiejiyuan@vivo.com> Signed-off-by: Zhichi Lin <zhichi.lin@vivo.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Will Deacon <will@kernel.org> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Marco Elver <elver@google.com> Cc: Will Deacon <will@kernel.org> Cc: Yee Lee <yee.lee@mediatek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12kexec_core: remove superfluous page offset handling in segment loadingJustinien Bouron
During kexec_segment loading, when copying the content of the segment (i.e. kexec_segment::kbuf or kexec_segment::buf) to its associated pages, kimage_load_{cma,normal,crash}_segment handle the case where the physical address of the segment is not page aligned, e.g. in kimage_load_normal_segment: page = kimage_alloc_page(image, GFP_HIGHUSER, maddr); // ... ptr = kmap_local_page(page); // ... ptr += maddr & ~PAGE_MASK; mchunk = min_t(size_t, mbytes, PAGE_SIZE - (maddr & ~PAGE_MASK)); // ^^^^ Non page-aligned segments handled here ^^^ // ... if (image->file_mode) memcpy(ptr, kbuf, uchunk); else result = copy_from_user(ptr, buf, uchunk); (similar logic is present in kimage_load_{cma,crash}_segment). This is actually not needed because, prior to their loading, all kexec_segments first go through a vetting step in `sanity_check_segment_list`, which rejects any segment that is not page-aligned: for (i = 0; i < nr_segments; i++) { unsigned long mstart, mend; mstart = image->segment[i].mem; mend = mstart + image->segment[i].memsz; // ... if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK)) return -EADDRNOTAVAIL; // ... } In case `sanity_check_segment_list` finds a non-page aligned the whole kexec load is aborted and no segment is loaded. This means that `kimage_load_{cma,normal,crash}_segment` never actually have to handle non page-aligned segments and `(maddr & ~PAGE_MASK) == 0` is always true no matter if the segment is coming from a file (i.e. `kexec_file_load` syscall), from a user-space buffer (i.e. `kexec_load` syscall) or created by the kernel through `kexec_add_buffer`. In the latter case, `kexec_add_buffer` actually enforces the page alignment: /* Ensure minimum alignment needed for segments. */ kbuf->memsz = ALIGN(kbuf->memsz, PAGE_SIZE); kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE); [jbouron@amazon.com: v3] Link: https://lkml.kernel.org/r/20251024155009.39502-1-jbouron@amazon.com Link: https://lkml.kernel.org/r/20250929160220.47616-1-jbouron@amazon.com Signed-off-by: Justinien Bouron <jbouron@amazon.com> Reviewed-by: Gunnar Kudrjavets <gunnarku@amazon.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: Alexander Graf <graf@amazon.com> Cc: Marcos Paulo de Souza <mpdesouza@suse.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()Dmitry Antipov
In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption. Fixes: 8f603e567aa7 ("Ocfs2/move_extents: move a range of extent.") Link: https://lkml.kernel.org/r/20251009102349.181126-2-dmantipov@yandex.ru Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Closes: https://syzkaller.appspot.com/bug?extid=727d161855d11d81e411 Reported-by: syzbot+727d161855d11d81e411@syzkaller.appspotmail.com Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-11-12lib/crypto: arm/blake2b: Move to scoped ksimd APIArd Biesheuvel
Even though ARM's versions of kernel_neon_begin()/_end() are not being changed, update the newly migrated ARM blake2b to the scoped ksimd API so that all ARM and arm64 in lib/crypto remains consistent in this manner. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-12Merge tag 'scoped-ksimd-for-arm-arm64' into libcrypto-fpsimd-on-stackEric Biggers
Pull scoped ksimd API for ARM and arm64 from Ard Biesheuvel: "Introduce a more strict replacement API for kernel_neon_begin()/kernel_neon_end() on both ARM and arm64, and replace occurrences of the latter pair appearing in lib/crypto" Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-11-12drm/nouveau: fully define nvfw_hs_load_header_v2Timur Tabi
Add the missing fields of the nvfw_hs_load_header_v2 struct, so that the struct matches the actual contents of the firmware images. nvfw_hs_load_header_v2 is a struct that defines a header for some firmware images used by Nouveau. The current structure definition is incomplete; it omits the last two fields because they are unused. To maintain consistency between Nouveau, OpenRM, and Nova, and to make it easier to support possible future images, we should fully define the struct. Also add a __counted_by tag for the flex array. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251010223957.1078525-1-ttabi@nvidia.com
2025-11-12Merge tag 'wireless-next-2025-11-12' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== More -next material, notably: - split ieee80211.h file, it's way too big - mac80211: initial chanctx work towards NAN - mac80211: MU-MIMO sniffer improvements - ath12k: statistics improvements * tag 'wireless-next-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (26 commits) wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper() wifi: mac80211: make monitor link info check more specific wifi: mac80211: track MU-MIMO configuration on disabled interfaces wifi: cfg80211/mac80211: Add fallback mechanism for INDOOR_SP connection wifi: cfg80211/mac80211: clean up duplicate ap_power handling wifi: cfg80211: use a C99 initializer in wiphy_register wifi: cfg80211: fix doc of struct key_params wifi: mac80211: remove unnecessary vlan NULL check wifi: mac80211: pass frame type to element parsing wifi: mac80211: remove "disabling VHT" message wifi: mac80211: add and use chanctx usage iteration wifi: mac80211: simplify ieee80211_recalc_chanctx_min_def() API wifi: mac80211: remove chanctx to link back-references wifi: mac80211: make link iteration safe for 'break' wifi: mac80211: fix EHT typo wifi: cfg80211: fix EHT typo wifi: ieee80211: split NAN definitions out wifi: ieee80211: split P2P definitions out wifi: ieee80211: split S1G definitions out wifi: ieee80211: split EHT definitions out ... ==================== Link: https://patch.msgid.link/20251112115126.16223-4-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12Merge tag 'wireless-2025-11-12' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Couple more fixes: - mwl8k: work around FW expecting a DSSS element in beacons - ath11k: report correct TX status - iwlwifi: avoid toggling links due to wrong element use - iwlwifi: fix beacon template rate on older devices - iwlwifi: fix loop iterator being used after loop - mac80211: disallow address changes while using the address - mac80211: avoid bad rate warning in monitor/sniffer mode - hwsim: fix potential NULL deref (on monitor injection) * tag 'wireless-2025-11-12' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: iwlwifi: mld: always take beacon ies in link grading wifi: iwlwifi: mvm: fix beacon template/fixed rate wifi: iwlwifi: fix aux ROC time event iterator usage wifi: mwl8k: inject DSSS Parameter Set element into beacons if missing wifi: mac80211_hwsim: Fix possible NULL dereference wifi: mac80211: skip rate verification for not captured PSDUs wifi: mac80211: reject address change while connecting wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp() ==================== Link: https://patch.msgid.link/20251112114621.15716-5-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12drm/nouveau/drm: Bump the driver version to 1.4.1 to report new featuresMohamed Ahmed
The HW can only do compression on large and huge pages, and enabling it on 4K pages leads to a MMU fault. Compression also needs kernel support for handling the compressed kinds and managing the compression tags. This increments the nouveau version number which allows NVK to enable it only when the kernel actually supports both features and avoid breaking the system if a newer mesa version is paired with an older kernel version. For the associated userspace MR, please see !36450: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36450 Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-5-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/tu102: Add support for compressed kindsBen Skeggs
Allow compressed PTE kinds to be written into PTEs when GSP-RM is present, rather than reverting to their non-compressed versions. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-4-83b05475f57c@mary.zone
2025-11-12drm/nouveau/mmu/gp100: Remove unused/broken support for compressionBen Skeggs
From GP100 onwards it's not possible to initialise comptag RAM without PMU firmware, which nouveau has no support for. As such, this code is essentially a no-op and will always revert to the equivalent non-compressed kind due to comptag allocation failure. It's also broken for the needs of VM_BIND/Vulkan. Remove the code entirely to make way for supporting compression on GPUs that support GSM-RM. Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-3-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Allow larger pagesMary Guillemard
Now that everything in UVMM knows about the variable page shift, we can select larger values. The proposed approach relies on nouveau_bo::page unless if it would cause alignment issues (in which case we fall back to searching for an appropriate shift) Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-2-83b05475f57c@mary.zone
2025-11-12drm/nouveau/uvmm: Prepare for larger pagesMary Guillemard
Currently memory allocated by VM_BIND uAPI can only have a granuality matching PAGE_SIZE (4KiB in common case) To have a better memory management and to allow big (64KiB) and huge (2MiB) pages later in the series, we are now passing the page shift all around the internals of UVMM. Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-1-83b05475f57c@mary.zone
2025-11-12net: stmmac: improve ndev->max_mtu setup readabilityRussell King (Oracle)
Improve the readibility of the code setting ndev->max_mtu. This depends on the hardware specific maximum defined by the MAC core, and also a platform provided maximum. The code was originally checking that the platform specific maximum was between ndev->min_mtu..MAC core maximum before reducing ndev->max_mtu, otherwise if the platform specific maximum was less than ndev->min_mtu, issuing a warning. Re-order the code to handle the case where the platform specific max is below ndev->min_mtu, which then means that the subsequent test is simply reducing ndev->max_mtu. Update the comment, and add a few blank lines to separate the blocks of code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1vImWA-0000000DrIl-1HZY@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12drm/xe/pf: Allow to lockdown the PF using custom guardMichal Wajdeczko
Some driver components, like eudebug or ccs-mode, can't be used when VFs are enabled. Add functions to allow those components to block the PF from enabling VFs for the requested duration. Introduce trivial counter to allow lockdown or exclusive access that can be used in the scenarios where we can't follow the strict owner semantics as required by the rw_semaphore implementation. Before enabling VFs, the PF will try to arm the "vfs_enabling" guard for the exclusive access. This will fail if there are some lockdown requests already initiated by the other components. For testing purposes, add debugfs file which will call these new functions from the file's open/close hooks. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Christoph Manszewski <christoph.manszewski@intel.com> Reviewed-by: Christoph Manszewski <christoph.manszewski@intel.com> Link: https://patch.msgid.link/20251109162451.4779-1-michal.wajdeczko@intel.com
2025-11-12r8169: add support for RTL8125Kjaven
This adds support for chip RTL8125K. Its XID is 0x68a. It is basically based on the one with XID 0x688, but with different firmware file. Signed-off-by: javen <javen_xu@realsil.com.cn> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/20251111092851.3371-1-javen_xu@realsil.com.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-12arm64: Fix double word in commentsBo Liu
Remove the repeated word "the" in comments. Signed-off-by: Bo Liu <liubo03@inspur.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-12riscv: defconfig: Enable Anlogic SoCJunhui Liu
Enable Anlogic SoC config in defconfig to allow the default upstream kernel booting on Milianke MLKPAI-FS01 board. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: dts: anlogic: Add Milianke MLKPAI FS01 boardJunhui Liu
Add support for the Milianke MLKPAI FS01 board based on the Anlogic DR1V90 SoC. The board features 512MB of onboard memory, USB-C UART, 1GbE RJ45 Ethernet, USB-A 2.0 port, TF card slot, and 256Mbit Quad-SPI flash. Currently, the board can boot to a console via UART1, which is connected to the onboard serial chip and routed to the Type-C interface. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: dts: Add initial Anlogic DR1V90 SoC device treeJunhui Liu
DR1V90 is a FPSoC from Anlogic, which features a RISC-V core as the PS part and 94,464 LUTs for the PL part. The PS part integrates a Nuclei UX900 RISC-V core with 32KB L1 icache and 32KB L1 dcache. It also provides two "snps,dw-apb-uart" compatible UART controllers. Some basic information of the processor can be obtained by running a simple application from nuclei-sdk [1]: -----Nuclei RISC-V CPU Configuration Information----- MARCHID: 0xc900 MIMPID: 0x20300 ISA: RV64 A B C D F I M P S U MCFG: TEE ECC ECLIC PLIC PPI ILM DLM ICACHE DCACHE IREGION No-Safety-Mechanism DLEN=VLEN/2 ILM: 256 KB has-ecc DLM: 256 KB has-ecc ICACHE: 32 KB(set=256,way=2,lsize=64,ecc=1) DCACHE: 32 KB(set=256,way=2,lsize=64,ecc=1) TLB: MainTLB(set=32,way=2,entry=1,ecc=1) ITLB(entry=8) DTLB(entry=8) IREGION: 0x68000000 128 MB Unit Size Address INFO 64KB 0x68000000 DEBUG 64KB 0x68010000 ECLIC 64KB 0x68020000 TIMER 64KB 0x68030000 PLIC 64MB 0x6c000000 INFO-Detail: mpasize : 0 PPI: 0xf8000000 128 MB -----End of Nuclei CPU INFO----- Link: https://github.com/Nuclei-Software/nuclei-sdk/blob/master/application/baremetal/cpuinfo/main.c [1] Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12riscv: Add Anlogic SoC famly Kconfig supportJunhui Liu
The first SoC in the Anlogic series is DR1V90, which contains a RISC-V core from Nuclei. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12dt-bindings: serial: snps-dw-apb-uart: Add Anlogic DR1V90 uartJunhui Liu
The Anlogic DR1V90 SoC integrates a UART controller compatible with snps,dw-apb-uart, operating at a 50 MHz clock. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12dt-bindings: timer: Add Anlogic DR1V90 ACLINT MTIMERJunhui Liu
Add MTIMER support for Anlogic DR1V90 SoC, which uses Nuclei UX900 with a TIMER unit compliant with the ACLINT specification. Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12dt-bindings: riscv: Add Anlogic DR1V90Junhui Liu
Add Anlogic DR1V90 FPSoC, featuring a UX900 RISC-V core as the processing system (PS) and 94,464 LUTs programmable logic (PL). It is used by the Milianke MLKPAI-FS01 board, a SBC equipped with 512MB DDR3 memory, USB-C UART, 1GbE RJ45 Ethernet, USB-A 2.0 port, TF card slot, and 256Mbit Quad-SPI flash. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12dt-bindings: riscv: Add Nuclei UX900 compatiblesJunhui Liu
The UX900 is a RISC-V core from Nuclei, used in the Anlogic DR1V90 SoC. It features a 64-bit architecture and dual-issue, 9-stage pipeline, with lots of optional extensions including V, K, Zc, and more. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12dt-bindings: vendor-prefixes: Add Anlogic, Milianke and NucleiJunhui Liu
Add vendor prefixes for "anlogic", "milianke" and "nuclei". These are required for describing the Milianke MLKPAI-FS01 board with DR1V90 SoC from Anlogic, which uses a processor core designed by Nuclei. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-12arm64: Fix typos and spelling errors in commentsmrigendrachaubey
This patch corrects several minor typographical and spelling errors in comments across multiple arm64 source files. No functional changes. Signed-off-by: mrigendrachaubey <mrigendra.chaubey@gmail.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-11-12null_blk: fix zone read length beyond write pointerKeith Busch
Fix up the divisor calculating the number of zone sectors being read and handle a read that straddles the zone write pointer. The length is rounded up a sector boundary, so be sure to truncate any excess bytes off to avoid copying past the data segment. Fixes: 3451cf34f51bb70 ("null_blk: allow byte aligned memory offsets") Signed-off-by: Keith Busch <kbusch@kernel.org> Tested-by: Bart van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-11-12cpufreq: intel_pstate: Check IDA only before MSR_IA32_PERF_CTL writesSrinivas Pandruvada
Commit ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") introduced a check for feature X86_FEATURE_IDA to verify turbo mode support. Although this is the correct way to check for turbo mode support, it causes issues on some platforms that disable turbo during OS boot, but enable it later [1]. Before adding this feature check, users were able to get turbo mode frequencies by writing 0 to /sys/devices/system/cpu/intel_pstate/no_turbo post-boot. To restore the old behavior on the affected systems while still addressing the unchecked MSR issue on some Skylake-X systems, check X86_FEATURE_IDA only immediately before updates of MSR_IA32_PERF_CTL that may involve setting the Turbo Engage Bit (bit 32). Fixes: ac4e04d9e378 ("cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode") Reported-by: Aaron Rainbolt <arainbolt@kfocus.org> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122531 [1] Tested-by: Aaron Rainbolt <arainbolt@kfocus.org> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20251111010840.141490-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-11-12drm/xe/pcode: Rework error mappingLucas De Marchi
The sparse array used for error decoding from is unnecessarily big. It should be better handled by a switch statement that will also allow us to more easily improve this code. Add a CASE_ERR() macro to keep the table compact and use it instead of the 256-entries array, which saves some space: $ bloat-o-meter xe_pcode.o.old xe_pcode.o add/remove: 0/1 grow/shrink: 2/0 up/down: 190/-4096 (-3906) Function old new delta __pcode_mailbox_rw 363 465 +102 __pcode_mailbox_rw.cold 58 146 +88 err_decode 4096 - -4096 Total: Before=7890, After=3984, chg -49.51% Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://patch.msgid.link/20251110-pcode-errmap-v2-1-cb18c8f54238@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-12rust: debugfs: Replace the usage of Rust native atomicsBoqun Feng
Rust native atomics are not allowed to use in kernel due to the mismatch of memory model with Linux kernel memory model, hence remove the usage of Rust native atomics in debufs. Reviewed-by: Matthew Maurer <mmaurer@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Tested-by: David Gow <davidgow@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251022035324.70785-4-boqun.feng@gmail.com
2025-11-12rust: sync: atomic: Implement Debug for Atomic<Debug>Boqun Feng
If `Atomic<T>` is `Debug` then it's a `debugfs::Writer`, therefore make it so since 1) debugfs needs to support `Atomic<T>` and 2) it's rather trivial to implement `Debug` for `Atomic<Debug>`. Tested-by: David Gow <davidgow@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251022035324.70785-3-boqun.feng@gmail.com
2025-11-12rust: sync: atomic: Make Atomic*Ops pub(crate)Boqun Feng
In order to write code over a generate Atomic<T> we need to make Atomic*Ops public so that functions like `.load()` and `.store()` are available. Make these pub(crate) at the beginning so the usage in kernel crate is supported. Tested-by: David Gow <davidgow@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251022035324.70785-2-boqun.feng@gmail.com
2025-11-12coresight: etm4x: Remove the state_needs_restore flagLeo Yan
When the restore flow is invoked, it means no error occurred during the save phase. Otherwise, if any errors happened while saving the context, the function would return an error and abort the suspend sequence. Therefore, the state_needs_restore flag is unnecessary. The save and restore functions are changed to check two conditions: 1) The global flag pm_save_enable is SELF_HOSTED mode; 2) The device is in active mode (non DISABLED). Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Mike Leach <mike.leach@linaro.org> Tested-by: James Clark <james.clark@linaro.org> Signed-off-by: Leo Yan <leo.yan@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20251111-arm_coresight_power_management_fix-v6-8-f55553b6c8b3@arm.com
2025-11-12sched_ext: Implement load balancer for bypass modeTejun Heo
In bypass mode, tasks are queued on per-CPU bypass DSQs. While this works well in most cases, there is a failure mode where a BPF scheduler can skew task placement severely before triggering bypass in highly over-saturated systems. If most tasks end up concentrated on a few CPUs, those CPUs can accumulate queues that are too long to drain in a reasonable time, leading to RCU stalls and hung tasks. Implement a simple timer-based load balancer that redistributes tasks across CPUs within each NUMA node. The balancer runs periodically (default 500ms, tunable via bypass_lb_intv_us module parameter) and moves tasks from overloaded CPUs to underloaded ones. When moving tasks between bypass DSQs, the load balancer holds nested DSQ locks to avoid dropping and reacquiring the donor DSQ lock on each iteration, as donor DSQs can be very long and highly contended. Add the SCX_ENQ_NESTED flag and use raw_spin_lock_nested() in dispatch_enqueue() to support this. The load balancer timer function reads scx_bypass_depth locklessly to check whether bypass mode is active. Use WRITE_ONCE() when updating scx_bypass_depth to pair with the READ_ONCE() in the timer function. This has been tested on a 192 CPU dual socket AMD EPYC machine with ~20k runnable tasks running scx_cpu0. As scx_cpu0 queues all tasks to CPU0, almost all tasks end up on CPU0 creating severe imbalance. Without the load balancer, disabling the scheduler can lead to RCU stalls and hung tasks, taking a very long time to complete. With the load balancer, disable completes in about a second. The load balancing operation can be monitored using the sched_ext_bypass_lb tracepoint and disabled by setting bypass_lb_intv_us to 0. v2: Lock both rq and DSQ in bypass_lb_cpu() and use dispatch_dequeue_locked() to prevent races with dispatch_dequeue() (Andrea Righi). Cc: Andrea Righi <arighi@nvidia.com> Cc: Dan Schatzberg <schatzberg.dan@gmail.com> Cc: Emil Tsalapatis <etsal@meta.com> Reviewed_by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-11-12sched_ext: Factor out abbreviated dispatch dequeue into ↵Tejun Heo
dispatch_dequeue_locked() move_task_between_dsqs() contains open-coded abbreviated dequeue logic when moving tasks between non-local DSQs. Factor this out into dispatch_dequeue_locked() which can be used when both the task's rq and dsq locks are already held. Add lockdep assertions to both dispatch_dequeue() and the new helper to verify locking requirements. This prepares for the load balancer which will need the same abbreviated dequeue pattern. Cc: Andrea Righi <arighi@nvidia.com> Cc: Dan Schatzberg <schatzberg.dan@gmail.com> Cc: Emil Tsalapatis <etsal@meta.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-11-12sched_ext: Factor out scx_dsq_list_node cursor initialization into ↵Tejun Heo
INIT_DSQ_LIST_CURSOR Factor out scx_dsq_list_node cursor initialization into INIT_DSQ_LIST_CURSOR macro in preparation for additional users. Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Cc: Dan Schatzberg <schatzberg.dan@gmail.com> Acked-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-11-12sched_ext: Add scx_cpu0 example schedulerTejun Heo
Add scx_cpu0, a simple scheduler that queues all tasks to a single DSQ and only dispatches them from CPU0 in FIFO order. This is useful for testing bypass behavior when many tasks are concentrated on a single CPU. If the load balancer doesn't work, bypass mode can trigger task hangs or RCU stalls as the queue is long and there's only one CPU working on it. v2: Check whether task is on CPU0 at enqueue using scx_bpf_task_cpu() instead of nr_cpus_allowed (Andrea Righi). Cc: Dan Schatzberg <schatzberg.dan@gmail.com> Cc: Emil Tsalapatis <etsal@meta.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-11-12sched_ext: Hook up hardlockup detectorTejun Heo
A poorly behaving BPF scheduler can trigger hard lockup. For example, on a large system with many tasks pinned to different subsets of CPUs, if the BPF scheduler puts all tasks in a single DSQ and lets all CPUs at it, the DSQ lock can be contended to the point where hardlockup triggers. Unfortunately, hardlockup can be the first signal out of such situations, thus requiring hardlockup handling. Hook scx_hardlockup() into the hardlockup detector to try kicking out the current scheduler in an attempt to recover the system to a good state. The handling strategy can delay watchdog taking its own action by one polling period; however, given that the only remediation for hardlockup is crash, this is likely an acceptable trade-off. v2: Add missing dummy scx_hardlockup() definition for !CONFIG_SCHED_CLASS_EXT (kernel test bot). Reported-by: Dan Schatzberg <schatzberg.dan@gmail.com> Cc: Emil Tsalapatis <etsal@meta.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-11 12:52:59 +0000