kernel/linux.git/arch/arm/Makefile, branch v6.12.80

ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS

2025-08-01T08:48:47+00:00

[ Upstream commit 87c4e1459e80bf65066f864c762ef4dc932fad4b ] After commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target"), which updated as-instr to use the 'assembler-with-cpp' language option, the Kbuild version of as-instr always fails internally for arch/arm with : fatal error: asm/unified.h: No such file or directory compilation terminated. because '-include' flags are now taken into account by the compiler driver and as-instr does not have '$(LINUXINCLUDE)', so unified.h is not found. This went unnoticed at the time of the Kbuild change because the last use of as-instr in Kbuild that arch/arm could reach was removed in 5.7 by commit 541ad0150ca4 ("arm: Remove 32bit KVM host support") but a stable backport of the Kbuild change to before that point exposed this potential issue if one were to be reintroduced. Follow the general pattern of '-include' paths throughout the tree and make unified.h absolute using '$(srctree)' to ensure KBUILD_AFLAGS can be used independently. Closes: https://lore.kernel.org/CACo-S-1qbCX4WAVFA63dWfHtrRHZBTyyr2js8Lx=Az03XHTTHg@mail.gmail.com/ Cc: stable@vger.kernel.org Fixes: d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target") Reported-by: KernelCI bot Reviewed-by: Masahiro Yamada Signed-off-by: Nathan Chancellor Signed-off-by: Russell King (Oracle) [ No KBUILD_RUSTFLAGS in 6.12 ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ARM: ep93xx: DT for the Cirrus ep93xx SoC platforms

2024-09-12T14:33:11+00:00

Add compulsory device tree support to the Cirrus ep93xx ARMv4 platform. - select PINCTRL_EP93xx - select COMMON_CLK_EP93XX, as clock driver moved out of platform code - select ARCH_HAS_RESET_CONTROLLER Select ARM_ATAG_DTB_COMPAT to update device tree with information about memory passed from bootloader. We have to leave all MACH options as they are used for board checking before decomp, to turn off watchdog and ethernet DMA. Tested-by: Alexander Sverdlin Signed-off-by: Nikita Shubin Tested-by: Michael Peters Reviewed-by: Andy Shevchenko Reviewed-by: Krzysztof Kozlowski Reviewed-by: Guenter Roeck Reviewed-by: Mark Brown Reviewed-by: Andy Shevchenko Reviewed-by: Linus Walleij Reviewed-by: Kris Bahnsen Reviewed-by: Andrew Lunn Reviewed-by: Sergey Shtylyov Acked-by: Miquel Raynal Acked-by: Alexander Sverdlin Acked-by: Uwe Kleine-König Acked-by: Damien Le Moal Acked-by: Sebastian Reichel Acked-by: Vinod Koul Signed-off-by: Arnd Bergmann

ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORT

2024-05-19T21:36:17+00:00

ARM provides an equivalent to the common kernel-mode FPU API, but in a different header and using different function names. Add a wrapper header, and export CFLAGS adjustments as found in lib/raid6/Makefile. [samuel.holland@sifive.com: ARM: do not select ARCH_HAS_KERNEL_FPU_SUPPORT] Link: https://lkml.kernel.org/r/20240509013727.648600-1-samuel.holland@sifive.com Link: https://lkml.kernel.org/r/20240329072441.591471-3-samuel.holland@sifive.com Signed-off-by: Samuel Holland Reviewed-by: Christoph Hellwig Acked-by: Christian König Cc: Alex Deucher Cc: Borislav Petkov (AMD) Cc: Catalin Marinas Cc: Dave Hansen Cc: Huacai Chen Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Masahiro Yamada Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Palmer Dabbelt Cc: Russell King Cc: Thomas Gleixner Cc: WANG Xuerui Cc: Will Deacon Cc: Thiago Jung Bauermann Cc: Ard Biesheuvel Signed-off-by: Andrew Morton

ARM: qcom: merge remaining subplatforms into sensible Kconfig entry

2024-02-06T21:00:02+00:00

Three remaining Qualcomm platforms have special handling of the TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs"). This is required for older platforms like IPQ40xx, MSM8x60, MSM8960 and APQ8064 and is compatible with other 32-bit Qualcomm platforms. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20231216162700.863456-4-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson

ARM: mach-nspire: Rework support and directory structure

2023-12-22T14:23:30+00:00

Having a platform need a mach-* directory should be seen as a negative, it means the platform needs special non-standard handling. ARM64 support does not allow mach-* directories at all. While we may not get to that given all the non-standard architectures we support, we should still try to get as close as we can and reduce the number of mach directories. The mach-nspire/ directory and files, provides just one "feature": having the kernel print the machine name if the DTB does not also contain a "model" string (which they always do). To reduce the number of mach-* directories let's do without that feature and remove this directory. NOTE: The default l2c_aux_mask is now ~0 but these devices never have this type of cache controller so this is safe. Signed-off-by: Andrew Davis Signed-off-by: Arnd Bergmann

ARM: mach-sunplus: Rework support and directory structure

2023-12-22T14:12:28+00:00

Having a platform need a mach-* directory should be seen as a negative, it means the platform needs special non-standard handling. ARM64 support does not allow mach-* directories at all. While we may not get to that given all the non-standard architectures we support, we should still try to get as close as we can and reduce the number of mach directories. The mach-sunplus/ directory and files, provides just one "feature": having the kernel print the machine name if the DTB does not also contain a "model" string (which they always do). To reduce the number of mach-* directories let's do without that feature and remove this directory. NOTE: The default l2c_aux_mask is now ~0 but these devices never have this type of cache controller so this is safe. Signed-off-by: Andrew Davis Signed-off-by: Arnd Bergmann

ARM: mach-airoha: Rework support and directory structure

2023-12-22T14:12:28+00:00

Having a platform need a mach-* directory should be seen as a negative, it means the platform needs special non-standard handling. ARM64 support does not allow mach-* directories at all. While we may not get to that given all the non-standard architectures we support, we should still try to get as close as we can and reduce the number of mach directories. The mach-airoha/ directory, and files within, provide just one "feature": having the kernel print the machine name if the DTB does not also contain a "model" string (which they always do). To reduce the number of mach-* directories let's do without that feature and remove this directory. It also seems there was a copy/paste error and the "MEDIATEK_DT" name was re-used in the DT_MACHINE_START macro. This may have caused conflicts if this was built in a multi-arch configuration. NOTE: The default l2c_aux_mask is now ~0 but these devices never have this type of cache controller so this is safe. Signed-off-by: Andrew Davis Signed-off-by: Arnd Bergmann

ARM: mach-moxart: Move MOXA ART support into Kconfig.platforms

2023-12-22T14:12:28+00:00

This removes the need for a dedicated Kconfig and empty mach directory. Signed-off-by: Andrew Davis Signed-off-by: Arnd Bergmann

kbuild: unify vdso_install rules

2023-10-28T12:09:02+00:00

Currently, there is no standard implementation for vdso_install, leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32. To address these problems, this commit introduces a generic vdso_install rule. Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install. For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away. vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name. The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada Acked-by: Sven Schnelle # s390 Reviewed-by: Nicolas Schier Reviewed-by: Guo Ren Acked-by: Helge Deller # parisc Acked-by: Catalin Marinas Acked-by: Russell King (Oracle)

ARM: oxnas: remove OXNAS support

2023-04-04T14:32:37+00:00

Due to lack of maintainance and stall of development for a few years now, and since no new features will ever be added upstream, remove support for OX810 and OX820 ARM support. Acked-by: Linus Walleij Acked-by: Arnd Bergmann Acked-by: Daniel Golle Signed-off-by: Neil Armstrong Signed-off-by: Arnd Bergmann