Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-6.8.y 2023-12-07T12:34:38+00:00 2023-12-07T12:34:38+00:00 Michael Ellerman mpe@ellerman.id.au 2023-12-06T11:55:48+00:00 urn:sha1:402928b58ec62b42b11992a7b51ff2f56ed65a18 If no cross compiler is specified, try to auto detect one. Look for various combinations, matching: powerpc(64(le)?)?(-unknown)?-linux(-gnu)?- There are more possibilities, but the above is known to find a compiler on Fedora and Ubuntu (which use linux-gnu-), and also detects the kernel.org cross compilers (which use linux-). This allows cross compiling with simply: # Ubuntu $ sudo apt install gcc-powerpc-linux-gnu # Fedora $ sudo dnf install gcc-powerpc64-linux-gnu $ make ARCH=powerpc defconfig $ make ARCH=powerpc -j 4 Inspired by arch/parisc/Makefile. Acked-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-4-mpe@ellerman.id.au 2023-12-07T12:34:38+00:00 Michael Ellerman mpe@ellerman.id.au 2023-12-06T11:55:47+00:00 urn:sha1:22f17b02f88b48c01d3ac38d40d2b0b695ab2d10 If the kernel is being cross compiled, there is no information from uname on which defconfig is most appropriate, so the Makefile defaults to ppc64. However these days almost all distros that support powerpc are little endian, so it's more likely that defaulting to ppc64le_defconfig will produce something useful for a user. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-3-mpe@ellerman.id.au 2023-12-07T12:34:38+00:00 Michael Ellerman mpe@ellerman.id.au 2023-12-06T11:55:45+00:00 urn:sha1:dc420877b5bd92db5d80df6b117c7a0f987290af There's no need to use $(ARCH) for references to the arch directory in the source tree, it is always arch/powerpc. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231206115548.1466874-1-mpe@ellerman.id.au 2023-08-24T22:39:29+00:00 Michael Ellerman mpe@ellerman.id.au 2023-03-29T23:43:08+00:00 urn:sha1:50832720ec54c39ab189cd5e057aec1c514978ce Currently the -mtune options are set in the Makefile, depending on what the compiler supports. One downside of doing it that way is that the chosen -mtune option is not recorded in the .config. Another downside is that if there's ever a need to do more complicated logic to calculate the correct option, that gets messy in the Makefile. So move the determination of which -mtune option to use into Kconfig logic. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230329234308.2215833-1-mpe@ellerman.id.au 2023-08-21T14:09:06+00:00 Naveen N Rao naveen@kernel.org 2023-06-19T09:47:34+00:00 urn:sha1:0f71dcfb4aef6043da6cc509e7a7f6a3ae87c12d GCC v13.1 updated support for -fpatchable-function-entry on ppc64le to emit nops after the local entry point, rather than before it. This allows us to use this in the kernel for ftrace purposes. A new script is added under arch/powerpc/tools/ to help detect if nops are emitted after the function local entry point, or before the global entry point. With -fpatchable-function-entry, we no longer have the profiling instructions generated at function entry, so we only need to validate the presence of two nops at the ftrace location in ftrace_init_nop(). We patch the preceding instruction with 'mflr r0' to match the -mprofile-kernel ABI for subsequent ftrace use. This changes the profiling instructions used on ppc32. The default -pg option emits an additional 'stw' instruction after 'mflr r0' and before the branch to _mcount 'bl _mcount'. This is very similar to the original -mprofile-kernel implementation on ppc64le, where an additional 'std' instruction was used to save LR to its save location in the caller's stackframe. Subsequently, this additional store was removed in later compiler versions for performance reasons. The same reasons apply for ppc32 so we only patch in a 'mflr r0'. Signed-off-by: Naveen N Rao <naveen@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/68586d22981a2c3bb45f27a2b621173d10a7d092.1687166935.git.naveen@kernel.org 2023-06-27T06:59:29+00:00 Masahiro Yamada masahiroy@kernel.org 2023-01-19T08:22:50+00:00 urn:sha1:54a11654de163994e32b24e3aa90ef81f4a3184d Commit e4412739472b ("Documentation: raise minimum supported version of binutils to 2.25") allows us to remove the checks for old binutils. There is no more user for ld-ifversion. Remove it as well. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230119082250.151485-1-masahiroy@kernel.org 2023-06-27T06:19:06+00:00 Naveen N Rao naveen@kernel.org 2023-05-30T06:14:36+00:00 urn:sha1:25ea739ea1d4d3de41acc4f4eb2d1a97eee0eb75 binutils v2.37 drops unused section symbols, which prevents recordmcount from capturing mcount locations in sections that have no non-weak symbols. This results in a build failure with a message such as: Cannot find symbol for section 12: .text.perf_callchain_kernel. kernel/events/callchain.o: failed The change to binutils was reverted for v2.38, so this behavior is specific to binutils v2.37: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b Objtool is able to cope with such sections, so this issue is specific to recordmcount. Fail the build and print a warning if binutils v2.37 is detected and if we are using recordmcount. Cc: stable@vger.kernel.org Suggested-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Naveen N Rao <naveen@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230530061436.56925-1-naveen@kernel.org 2023-06-14T02:46:42+00:00 Nicholas Piggin npiggin@gmail.com 2023-06-06T06:48:30+00:00 urn:sha1:f5df87b855fd835ff0f4928575adbf4f5302bb40 x86 removed -pipe in commit 437e88ab8f9e2 ("x86/build: Remove -pipe from KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it, so that seems to be the way the world's going. Compile performance building defconfig on a POWER10 PowerNV system was in the noise after 10 builds each. No point in adding options unless they help something, so remove it. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230606064830.184083-1-npiggin@gmail.com 2023-04-21T06:16:25+00:00 Michael Ellerman mpe@ellerman.id.au 2023-04-14T13:24:15+00:00 urn:sha1:9ecda934f43b1502c420653b02d54d4ffd7ae4cb Rather than trying to keep multiple configs up to date, make pseries_defconfig an alias for ppc64le_guest_defconfig. NOTE, pseries_defconfig was a big endian config, but this commit switches it to little endian. Almost all distros are ppc64le these days, so little endian is much more likely to be what a user wants when they build for "pseries". For an actual big endian guest, use ppc64_guest_defconfig. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-32-mpe@ellerman.id.au 2023-04-21T06:16:25+00:00 Michael Ellerman mpe@ellerman.id.au 2023-04-14T13:24:14+00:00 urn:sha1:596ddea8be17b5f4e2f72a0c9af313444d51d177 Rather than trying to keep multiple configs up to date, make pseries_le_defconfig an alias for ppc64le_guest_defconfig. ppc64le_guest_defconfig should work in all cases that pseries_le_defconfig currently does, but if not we can update it. Move pseries_le_defconfig down in the Makefile, so it appears after ppc64le_guest_defconfig in the help output. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230414132415.821564-31-mpe@ellerman.id.au