kernel/linux.git/Makefile, branch v6.1.132

Linux 6.1.132

2025-03-28T20:59:02+00:00

Link: https://lore.kernel.org/r/20250325122156.633329074@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250326154349.272647840@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20250328074420.301061796@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Frank Scheiner Signed-off-by: Greg Kroah-Hartman

scripts: `make rust-analyzer` for out-of-tree modules

2025-03-28T20:58:57+00:00

[ Upstream commit 49a9ef76740206d52e7393f6fe25fc764de8df32 ] Adds support for out-of-tree rust modules to use the `rust-analyzer` make target to generate the rust-project.json file. The change involves adding an optional parameter `external_src` to the `generate_rust_analyzer.py` which expects the path to the out-of-tree module's source directory. When this parameter is passed, I have chosen not to add the non-core modules (samples and drivers) into the result since these are not expected to be used in third party modules. Related changes are also made to the Makefile and rust/Makefile allowing the `rust-analyzer` target to be used for out-of-tree modules as well. Link: https://github.com/Rust-for-Linux/linux/pull/914 Link: https://github.com/Rust-for-Linux/rust-out-of-tree-module/pull/2 Signed-off-by: Vinay Varma Link: https://lore.kernel.org/r/20230411091714.130525-1-varmavinaym@gmail.com Signed-off-by: Miguel Ojeda Stable-dep-of: 2e0f91aba507 ("scripts: generate_rust_analyzer: add missing macros deps") Signed-off-by: Sasha Levin

Linux 6.1.131

2025-03-13T11:53:26+00:00

Link: https://lore.kernel.org/r/20250310170427.529761261@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman

kbuild: userprogs: use correct lld when linking through clang

2025-03-13T11:53:26+00:00

commit dfc1b168a8c4b376fa222b27b97c2c4ad4b786e1 upstream. The userprog infrastructure links objects files through $(CC). Either explicitly by manually calling $(CC) on multiple object files or implicitly by directly compiling a source file to an executable. The documentation at Documentation/kbuild/llvm.rst indicates that ld.lld would be used for linking if LLVM=1 is specified. However clang instead will use either a globally installed cross linker from $PATH called ${target}-ld or fall back to the system linker, which probably does not support crosslinking. For the normal kernel build this is not an issue because the linker is always executed directly, without the compiler being involved. Explicitly pass --ld-path to clang so $(LD) is respected. As clang 13.0.1 is required to build the kernel, this option is available. Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs") Cc: stable@vger.kernel.org # needs wrapping in $(cc-option) for < 6.9 Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada [nathan: use cc-option for 6.6 and older, as those trees support back to clang-11] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

Linux 6.1.130

2025-03-07T15:56:52+00:00

Link: https://lore.kernel.org/r/20250305174505.437358097@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: SeongJae Park Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20250306151414.484343862@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

Linux 6.1.129

2025-02-21T12:50:12+00:00

Link: https://lore.kernel.org/r/20250219082652.891560343@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Peter Schneider Tested-by: Hardik Garg Tested-by: Slade Watkins Tested-by: Ron Economos Reviewed-by: Mark Brown Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20250220104545.805660879@linuxfoundation.org Tested-by: Mark Brown Tested-by: Hardik Garg Tested-by: Pavel Machek (CIP) Tested-by: Slade Watkins Tested-by: Peter Schneider Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

kbuild: switch from lz4c to lz4 for compression

2025-02-21T12:49:25+00:00

commit e397a603e49cc7c7c113fad9f55a09637f290c34 upstream. Replace lz4c with lz4 for kernel image compression. Although lz4 and lz4c are functionally similar, lz4c has been deprecated upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4 and lz4c have been packaged together, making it safe to update the requirement from lz4c to lz4. Consequently, some distributions and build systems, such as OpenEmbedded, have fully transitioned to using lz4. OpenEmbedded core adopted this change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of lz4c"), causing compatibility issues when building the mainline kernel in the latest OpenEmbedded environment, as seen in the errors below. This change also updates the LZ4 compression commands to make it backward compatible by replacing stdin and stdout with the '-' option, due to some unclear reason, the stdout keyword does not work for lz4 and '-' works for both. In addition, this modifies the legacy '-c1' with '-9' which is also compatible with both. This fixes the mainline kernel build failures with the latest master OpenEmbedded builds associated with the mentioned compatibility issues. LZ4 arch/arm/boot/compressed/piggy_data /bin/sh: 1: lz4c: not found ... ... ERROR: oe_runmake failed Link: https://github.com/lz4/lz4/pull/553 Suggested-by: Francesco Dolcini Signed-off-by: Parth Pancholi Signed-off-by: Masahiro Yamada Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman

Linux 6.1.128

2025-02-01T17:30:12+00:00

Link: https://lore.kernel.org/r/20250130140133.825446496@linuxfoundation.org Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: kernelci.org bot Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman

Linux 6.1.127

2025-01-23T16:17:18+00:00

Link: https://lore.kernel.org/r/20250121174521.568417761@linuxfoundation.org Tested-by: Shuah Khan Tested-by: SeongJae Park Link: https://lore.kernel.org/r/20250122073827.056636718@linuxfoundation.org Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Linux Kernel Functional Testing Tested-by: kernelci.org bot Signed-off-by: Greg Kroah-Hartman

Linux 6.1.126

2025-01-19T08:01:16+00:00

Signed-off-by: Greg Kroah-Hartman