wireguard-linux/scripts, branch devel

mcb: Add missing modpost build support

2025-12-27T19:48:01Z

mcb bus is not prepared to autoload client drivers with the data defined on the drivers' MODULE_DEVICE_TABLE. modpost cannot access to mcb_table_id inside MODULE_DEVICE_TABLE so the data declared inside is ignored. Add modpost build support for accessing to the mcb_table_id coded on device drivers' MODULE_DEVICE_TABLE. Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Reviewed-by: Jorge Sanjuan Garcia Signed-off-by: Jose Javier Rodriguez Barbarin Acked-by: Nathan Chancellor Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20251202084200.10410-1-dev-josejavier.rodriguez@duagon.com Signed-off-by: Nicolas Schier

kbuild: fix compilation of dtb specified on command-line without make rule

2025-12-27T19:48:01Z

Since commit e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs"), it is no longer possible to compile a device tree blob that is not specified in a make rule like: dtb-$(CONFIG_FOO) += foo.dtb Before the mentioned commit, one could copy a dts file to e.g. arch/arm64/boot/dts/ (or a new subdirectory) and then convert it to a dtb file using: make ARCH=arm64 foo.dtb In this scenario, both 'dtb-y' and 'dtb-' are empty, and the inclusion of scripts/Makefile.dtbs relies on 'targets' to contain the MAKECMDGOALS. The value of 'targets', however, is only final later in the code. Move the conditional include of scripts/Makefile.dtbs down to where the value of 'targets' is final. Since Makefile.dtbs updates 'always-y' which is used as a prerequisite in the build rule, the build rule also needs to move down. Fixes: e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs") Signed-off-by: Thomas De Schampheleire Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Acked-by: Rob Herring (Arm) Link: https://patch.msgid.link/20251126100017.1162330-1-thomas.de_schampheleire@nokia.com Signed-off-by: Nicolas Schier

Revert "scripts/clang-tools: Handle included .c files in gen_compile_commands"

2025-12-27T19:48:01Z

This reverts commit 9362d34acf91a706c543d919ade3e651b9bd2d6f. Dmitry Vyukov reported that commit 9362d34acf91 ("scripts/clang-tools: Handle included .c files in gen_compile_commands") generates false entries in some cases for C files that are included in other C files but not meant for standalone compilation. For properly supporting clangd, including .c files is discouraged. Reported-by: Dmitry Vyukov Closes: https://lore.kernel.org/r/CACT4Y+Z8aCz0XcoJx9XXPHZSZHxGF8Kx9iUbFarhpTSEPDhMfg@mail.gmail.com Acked-by: Nathan Chancellor Acked-by: Dmitry Vyukov Fixes: 9362d34acf91 ("scripts/clang-tools: Handle included .c files in gen_compile_commands") Link: https://patch.msgid.link/20251217-revert-scripts-clang-rools-handle-included-c-files-v1-1-def5651446da@kernel.org Signed-off-by: Nicolas Schier

Coccinelle: pm_runtime: Fix typo in report message

2025-12-21T20:04:52Z

s/Unecessary/Unnecessary/ Reviewed-by: Julia Lawall Signed-off-by: Thorsten Blum

scripts: coccicheck: filter *.cocci files by MODE

2025-12-21T20:04:45Z

Enhance the coccicheck script to filter *.cocci files based on the specified MODE (e.g., report, patch). This ensures that only compatible semantic patch files are executed, preventing errors such as: "virtual rule report not supported" This error occurs when a .cocci file does not define a 'virtual ' rule, yet is executed in that mode. For example: make coccicheck M=drivers/hwtracing/coresight/ MODE=report In this case, running "secs_to_jiffies.cocci" would trigger the error because it lacks support for 'report' mode. With this change, such files are skipped automatically, improving robustness and developer experience. Signed-off-by: Songwei Chai Reviewed-by: Julia Lawall

Merge tag 'mm-nonmm-stable-2025-12-11-11-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2025-12-13T08:55:12Z

Pull misc updates from Andrew Morton: "There are no significant series in this small merge. Please see the individual changelogs for details" [ Editor's note: it's mainly ocfs2 and a couple of random fixes ] * tag 'mm-nonmm-stable-2025-12-11-11-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm: memfd_luo: add CONFIG_SHMEM dependency mm: shmem: avoid build warning for CONFIG_SHMEM=n ocfs2: fix memory leak in ocfs2_merge_rec_left() ocfs2: invalidate inode if i_mode is zero after block read ocfs2: avoid -Wflex-array-member-not-at-end warning ocfs2: convert remaining read-only checks to ocfs2_emergency_state ocfs2: add ocfs2_emergency_state helper and apply to setattr checkpatch: add uninitialized pointer with __free attribute check args: fix documentation to reflect the correct numbers ocfs2: fix kernel BUG in ocfs2_find_victim_chain liveupdate: luo_core: fix redundant bound check in luo_ioctl() ocfs2: validate inline xattr size and entry count in ocfs2_xattr_ibody_list fs/fat: remove unnecessary wrapper fat_max_cache() ocfs2: replace deprecated strcpy with strscpy ocfs2: check tl_used after reading it from trancate log inode liveupdate: luo_file: don't use invalid list iterator

checkpatch: add uninitialized pointer with __free attribute check

2025-12-11T00:07:42Z

Uinitialized pointers with __free attribute can cause undefined behavior as the memory randomly assigned to the pointer is freed automatically when the pointer goes out of scope. add check in checkpatch to detect such issues. Link: https://lkml.kernel.org/r/20251203-aheev-checkpatch-uninitialized-free-v7-1-841e3b31d8f3@gmail.com Signed-off-by: Ally Heev Suggested-by: Dan Carpenter Link: https://lore.kernel.org/all/8a4c0b43-cf63-400d-b33d-d9c447b7e0b9@suswa.mountain/ Link: https://lore.kernel.org/all/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/ Acked-by: Dan Williams Reviewed-by: Krzysztof Kozlowski Acked-by: Joe Perches Cc: Andy Whitcroft Cc: David Hunter Cc: Dwaipayan Ray Cc: Geert Uytterhoeven Cc: James Bottomley Cc: Jonathan Corbet Cc: Lukas Bulwahn Cc: Menon, Nishanth Cc: Stephen Boyd Cc: Viresh Kumar Signed-off-by: Andrew Morton

Merge tag 'kbuild-6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2025-12-10T07:57:24Z

Pull Kbuild fix from Nathan Chancellor: - Fix install-extmod-build when ccache is used via CC * tag 'kbuild-6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kbuild: install-extmod-build: Properly fix CC expansion when ccache is used

Merge tag 'trace-v6.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2025-12-10T07:38:50Z

Pull tracing fixes from Steven Rostedt: - Fix unused tracepoint build for modules only using exported tracepoints The tracepoint-update.c code that looks for unused tracepoints expects if tracepoints are used then it will have tracepoints defined. If not, it errors out which fails the build. In most cases this the way things work. A tracepoint can't be used if it is not defined. There is one exception; If a module only uses tracepoints that are defined in other modules or the vmlinux proper, where the tracepoints are exported. In this case, the tracepoint-update.c code thinks tracepoints are used but not defined and errors out, failing the build. When tracepoint-update.c detects this case, if it is a module that is being processed, exit out normally as it is a legitimate case. - Add tracepoint-update.c to MAINTAINERS file The tracepoint-update.c file is specific to tracing so add it to the tracing subsystem in the MAINTAINERS file. * tag 'trace-v6.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: MAINTAINERS: Add tracepoint-update.c to TRACING section tracing: Fix unused tracepoints when module uses only exported ones

tracing: Fix unused tracepoints when module uses only exported ones

2025-12-10T02:16:07Z

Building the KVM intel module failed to build with UT=1: no __tracepoint_strings in file: arch/x86/kvm/kvm-intel.o make[3]: *** [/work/git/test-linux.git/scripts/Makefile.modfinal:62: arch/x86/kvm/kvm-intel.ko] Error 1 The reason is that the module only uses the tracepoints defined and exported by the main kvm module. The tracepoint-update.c code fails the build if a tracepoint is used, but there's no tracepoints defined. But this is acceptable in modules if the tracepoints are defined in the vmlinux proper or another module and exported. Do not fail to build if a tracepoint is used but no tracepoints are defined if the code is a module. This should still never happen for the vmlinux itself. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Masahiro Yamada Link: https://patch.msgid.link/20251209204023.76941824@fedora Fixes: e30f8e61e2518 ("tracing: Add a tracepoint verification check at build time") Signed-off-by: Steven Rostedt (Google)