user/sven/linux.git/Makefile, branch v6.6.81

Linux 6.6.81

2025-03-07T15:45:57Z

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

Linux 6.6.80

2025-02-27T12:10:54Z

Link: https://lore.kernel.org/r/20250224142602.998423469@linuxfoundation.org Tested-by: FLorian Fainelli Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

Linux 6.6.79

2025-02-21T12:57:28Z

Link: https://lore.kernel.org/r/20250219082550.014812078@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Hardik Garg Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Tested-by: Harshit Mogalapalli Tested-by: Shuah Khan Tested-by: Slade Watkins Signed-off-by: Greg Kroah-Hartman

kbuild: userprogs: fix bitsize and target detection on clang

2025-02-21T12:57:17Z

commit 1b71c2fb04e7a713abc6edde4a412416ff3158f2 upstream. scripts/Makefile.clang was changed in the linked commit to move --target from KBUILD_CFLAGS to KBUILD_CPPFLAGS, as that generally has a broader scope. However that variable is not inspected by the userprogs logic, breaking cross compilation on clang. Use both variables to detect bitsize and target arguments for userprogs. Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

tools: fix annoying "mkdir -p ..." logs when building tools in parallel

2025-02-21T12:57:09Z

[ Upstream commit d1d0963121769d8d16150b913fe886e48efefa51 ] When CONFIG_OBJTOOL=y or CONFIG_DEBUG_INFO_BTF=y, parallel builds show awkward "mkdir -p ..." logs. $ make -j16 [ snip ] mkdir -p /home/masahiro/ref/linux/tools/objtool && make O=/home/masahiro/ref/linux subdir=tools/objtool --no-print-directory -C objtool mkdir -p /home/masahiro/ref/linux/tools/bpf/resolve_btfids && make O=/home/masahiro/ref/linux subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids Defining MAKEFLAGS= on the command line wipes out command line switches from the resultant MAKEFLAGS definition, even though the command line switches are active. [1] MAKEFLAGS puts all single-letter options into the first word, and that word will be empty if no single-letter options were given. [2] However, this breaks if MAKEFLAGS= is given on the command line. The tools/ and tools/% targets set MAKEFLAGS= on the command line, which breaks the following code in tools/scripts/Makefile.include: short-opts := $(firstword -$(MAKEFLAGS)) If MAKEFLAGS really needs modification, it should be done through the environment variable, as follows: MAKEFLAGS= $(MAKE) ... That said, I question whether modifying MAKEFLAGS is necessary here. The only flag we might want to exclude is --no-print-directory, as the tools build system changes the working directory. However, people might find the "Entering/Leaving directory" logs annoying. I simply removed the offending MAKEFLAGS=. [1]: https://savannah.gnu.org/bugs/?62469 [2]: https://www.gnu.org/software/make/manual/make.html#Testing-Flags Fixes: ea01fa9f63ae ("tools: Connect to the kernel build system") Fixes: a50e43332756 ("perf tools: Honor parallel jobs") Signed-off-by: Masahiro Yamada Tested-by: Daniel Xu Signed-off-by: Sasha Levin

Linux 6.6.78

2025-02-17T08:40:43Z

Link: https://lore.kernel.org/r/20250213142407.354217048@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Hardik Garg Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Harshit Mogalapalli Tested-By: Achill Gilgenast Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

Linux 6.6.77

2025-02-11T08:37:33Z

Signed-off-by: Greg Kroah-Hartman

Linux 6.6.76

2025-02-08T08:52:39Z

Link: https://lore.kernel.org/r/20250205134420.279368572@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Hardik Garg Tested-by: Harshit Mogalapalli Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20250206155234.095034647@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman

kbuild: switch from lz4c to lz4 for compression

2025-02-08T08:52:35Z

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.6.75

2025-02-01T17:37:57Z

Link: https://lore.kernel.org/r/20250130133458.903274626@linuxfoundation.org Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: kernelci.org bot Tested-by: Hardik Garg Tested-by: Peter Schneider Signed-off-by: Greg Kroah-Hartman