linux.git/arch/arm/Makefile, branch v6.11 Linux kernel source tree ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORT 2024-05-19T21:36:17+00:00 Samuel Holland samuel.holland@sifive.com 2024-03-29T07:18:17+00:00 cb2b7b7de805cd649851fb8f2f36df3b8425682e 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 <samuel.holland@sifive.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Palmer Dabbelt <palmer@rivosinc.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: WANG Xuerui <git@xen0n.name> Cc: Will Deacon <will@kernel.org> Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 
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 <samuel.holland@sifive.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Christian König <christian.koenig@amd.com> 
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <nicolas@fjasle.eu>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: WANG Xuerui <git@xen0n.name>
Cc: Will Deacon <will@kernel.org>
Cc: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ARM: qcom: merge remaining subplatforms into sensible Kconfig entry 2024-02-06T21:00:02+00:00 Dmitry Baryshkov dmitry.baryshkov@linaro.org 2023-12-16T16:27:00+00:00 99497df59427a11222571034afebf2f0f7f9a3e2 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 <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20231216162700.863456-4-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
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 <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231216162700.863456-4-dmitry.baryshkov@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
ARM: mach-nspire: Rework support and directory structure 2023-12-22T14:23:30+00:00 Andrew Davis afd@ti.com 2023-11-13T14:43:59+00:00 671c08ec007b2f859d9075fc9bc0c06320c90cd4 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 <afd@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
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 <afd@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: mach-sunplus: Rework support and directory structure 2023-12-22T14:12:28+00:00 Andrew Davis afd@ti.com 2023-11-13T14:43:57+00:00 ae73dadb1285301967253c8f859116bf90b69b06 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 <afd@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
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 <afd@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: mach-airoha: Rework support and directory structure 2023-12-22T14:12:28+00:00 Andrew Davis afd@ti.com 2023-11-13T14:43:56+00:00 00e58c36d20aa011cb0e2f087d9422bf4c6da75d 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 <afd@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
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 <afd@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: mach-moxart: Move MOXA ART support into Kconfig.platforms 2023-12-22T14:12:28+00:00 Andrew Davis afd@ti.com 2023-11-13T14:43:55+00:00 dcfbe025c29b0df82cadd25cc0bbb89a5bda71fb This removes the need for a dedicated Kconfig and empty mach directory. Signed-off-by: Andrew Davis <afd@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
This removes the need for a dedicated Kconfig and empty mach directory.

Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
kbuild: unify vdso_install rules 2023-10-28T12:09:02+00:00 Masahiro Yamada masahiroy@kernel.org 2023-10-14T10:54:35+00:00 56769ba4b297a629148eb24d554aef72d1ddfd9e 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 <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> 
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 <masahiroy@kernel.org>
Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Guo Ren <guoren@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>  # parisc
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
ARM: oxnas: remove OXNAS support 2023-04-04T14:32:37+00:00 Neil Armstrong neil.armstrong@linaro.org 2023-04-03T07:42:19+00:00 5ca2653011a4f4217ebd16144ddd5c2dca177cc0 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 <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
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 <linus.walleij@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm 2023-02-21T23:21:29+00:00 Linus Torvalds torvalds@linux-foundation.org 2023-02-21T23:21:29+00:00 b327dfe05258e09c8db6e1e091c2e6d84dd426a6 Pull ARM udpates from Russell King: - Improve Kconfig help text for Cortex A8 and Cortex A9 errata - Kconfig spelling and grammar fixes - Allow kernel-mode VFP/Neon in softirq context - Use Neon in softirq context - Implement AES-CTR/GHASH version of GCM * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer ARM: 9288/1: Kconfigs: fix spelling & grammar ARM: 9286/1: crypto: Implement fused AES-CTR/GHASH version of GCM ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile ARM: 9283/1: permit non-nested kernel mode NEON in softirq context ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled ARM: 9281/1: improve Cortex A8/A9 errata help text 
Pull ARM udpates from Russell King:

 - Improve Kconfig help text for Cortex A8 and Cortex A9 errata

 - Kconfig spelling and grammar fixes

 - Allow kernel-mode VFP/Neon in softirq context

 - Use Neon in softirq context

 - Implement AES-CTR/GHASH version of GCM

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 9289/1: Allow pre-ARMv5 builds with ld.lld 16.0.0 and newer
  ARM: 9288/1: Kconfigs: fix spelling & grammar
  ARM: 9286/1: crypto: Implement fused AES-CTR/GHASH version of GCM
  ARM: 9285/1: remove meaningless arch/arm/mach-rda/Makefile
  ARM: 9283/1: permit non-nested kernel mode NEON in softirq context
  ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled
  ARM: 9281/1: improve Cortex A8/A9 errata help text
Merge tag 'soc-defconfig-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc 2023-02-20T23:43:36+00:00 Linus Torvalds torvalds@linux-foundation.org 2023-02-20T23:43:36+00:00 c72e04c26faefc6650709066a8f019a7fb4cbb84 Pull ARM defconfigs updates from Arnd Bergmann: "As usual, this contains all the patches to enable options for newly added device drivers in the 32-bit and 64-bit defconfig files. I have sorted the files according to the changes to Kconfig files, to make it easier to check what has changed compared to the 'make savedefconfig' output. The most notable change this time is a series from Mark Brown to add a 'virtconfig' target for arm64, which is for the moment the same as the 'defconfig' target but disables all the top-level SoC specific options in order to have a smaller and faster kernel build" * tag 'soc-defconfig-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (39 commits) arm64: defconfig: enable drivers required by the Qualcomm SA8775P platform arm64: defconfig: Enable DisplayPort on SC8280XP laptops arm64: configs: Add virtconfig kbuild: Provide a version of merge_into_defconfig without override warnings scripts: merge_config: Add option to suppress warning on overrides ARM: reorder defconfig files arm64: reorder defconfig arm64: defconfig: enable Qualcomm SDAM nvmem driver arm64: defconfig: enable SM8450 DISPCC clock driver ARM: defconfig: Add IOSCHED_BFQ to the default configs ARM: configs: multi_v7: enable NVMEM driver for STM32 ARM: Add wpcm450_defconfig for Nuvoton WPCM450 arm64: defconfig: Enable DMA_RESTRICTED_POOL arm64: defconfig: Enable missing configs for mt8192-asurada riscv: defconfig: Enable the Allwinner D1 platform and drivers ARM: imx_v6_v7_defconfig: Don't enable PROVE_LOCKING ARM: multi_v7_defconfig: Add GXP Fan and SPI support ARM: add multi_v7_lpae_defconfig kbuild: Add config fragment merge functionality ARM: multi_v7_defconfig: Add options to support TQMLS102xA series ... 
Pull ARM defconfigs updates from Arnd Bergmann:
 "As usual, this contains all the patches to enable options for newly
  added device drivers in the 32-bit and 64-bit defconfig files.

  I have sorted the files according to the changes to Kconfig files,
  to make it easier to check what has changed compared to the 'make
  savedefconfig' output.

  The most notable change this time is a series from Mark Brown to add
  a 'virtconfig' target for arm64, which is for the moment the same as
  the 'defconfig' target but disables all the top-level SoC specific
  options in order to have a smaller and faster kernel build"

* tag 'soc-defconfig-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (39 commits)
  arm64: defconfig: enable drivers required by the Qualcomm SA8775P platform
  arm64: defconfig: Enable DisplayPort on SC8280XP laptops
  arm64: configs: Add virtconfig
  kbuild: Provide a version of merge_into_defconfig without override warnings
  scripts: merge_config: Add option to suppress warning on overrides
  ARM: reorder defconfig files
  arm64: reorder defconfig
  arm64: defconfig: enable Qualcomm SDAM nvmem driver
  arm64: defconfig: enable SM8450 DISPCC clock driver
  ARM: defconfig: Add IOSCHED_BFQ to the default configs
  ARM: configs: multi_v7: enable NVMEM driver for STM32
  ARM: Add wpcm450_defconfig for Nuvoton WPCM450
  arm64: defconfig: Enable DMA_RESTRICTED_POOL
  arm64: defconfig: Enable missing configs for mt8192-asurada
  riscv: defconfig: Enable the Allwinner D1 platform and drivers
  ARM: imx_v6_v7_defconfig: Don't enable PROVE_LOCKING
  ARM: multi_v7_defconfig: Add GXP Fan and SPI support
  ARM: add multi_v7_lpae_defconfig
  kbuild: Add config fragment merge functionality
  ARM: multi_v7_defconfig: Add options to support TQMLS102xA series
  ...