linux-dev/arch/arm/mm/Kconfig, branch master

ARM: 9212/1: domain: Modify Kconfig help text

2022-07-06T21:44:49Z

After the removal of set_fs() the reference to set_fs() is stale. Alter the helptext to reflect what the config option really does. Fixes: 8ac6f5d7f84b ("ARM: 9113/1: uaccess: remove set_fs() implementation") Acked-by: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle)

ARM: rework endianess selection

2022-04-08T15:20:54Z

Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago. The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them. This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx. As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment. For the ARMv6/v7 platforms, there are two ways this could be handled a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point. b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work. Out of these, I picked b) because it seemed slighly more logical to me. Signed-off-by: Arnd Bergmann

Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm

2022-03-24T00:35:57Z

Pull ARM updates from Russell King: "Updates for IRQ stacks and virtually mapped stack support, and ftrace: - Support for IRQ and vmap'ed stacks This covers all the work related to implementing IRQ stacks and vmap'ed stacks for all 32-bit ARM systems that are currently supported by the Linux kernel, including RiscPC and Footbridge. It has been submitted for review in four different waves: - IRQ stacks support for v7 SMP systems [0] - vmap'ed stacks support for v7 SMP systems[1] - extending support for both IRQ stacks and vmap'ed stacks for all remaining configurations, including v6/v7 SMP multiplatform kernels and uniprocessor configurations including v7-M [2] - fixes and updates in [3] - ftrace fixes and cleanups Make all flavors of ftrace available on all builds, regardless of ISA choice, unwinder choice or compiler [4]: - use ADD not POP where possible - fix a couple of Thumb2 related issues - enable HAVE_FUNCTION_GRAPH_FP_TEST for robustness - enable the graph tracer with the EABI unwinder - avoid clobbering frame pointer registers to make Clang happy - Fixes for the above" [0] https://lore.kernel.org/linux-arm-kernel/20211115084732.3704393-1-ardb@kernel.org/ [1] https://lore.kernel.org/linux-arm-kernel/20211122092816.2865873-1-ardb@kernel.org/ [2] https://lore.kernel.org/linux-arm-kernel/20211206164659.1495084-1-ardb@kernel.org/ [3] https://lore.kernel.org/linux-arm-kernel/20220124174744.1054712-1-ardb@kernel.org/ [4] https://lore.kernel.org/linux-arm-kernel/20220203082204.1176734-1-ardb@kernel.org/ * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: (62 commits) ARM: fix building NOMMU ARMv4/v5 kernels ARM: unwind: only permit stack switch when unwinding call_with_stack() ARM: Revert "unwind: dump exception stack from calling frame" ARM: entry: fix unwinder problems caused by IRQ stacks ARM: unwind: set frame.pc correctly for current-thread unwinding ARM: 9184/1: return_address: disable again for CONFIG_ARM_UNWIND=y ARM: 9183/1: unwind: avoid spurious warnings on bogus code addresses Revert "ARM: 9144/1: forbid ftrace with clang and thumb2_kernel" ARM: mach-bcm: disable ftrace in SMC invocation routines ARM: cacheflush: avoid clobbering the frame pointer ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds ARM: ftrace: enable the graph tracer with the EABI unwinder ARM: unwind: track location of LR value in stack frame ARM: ftrace: enable HAVE_FUNCTION_GRAPH_FP_TEST ARM: ftrace: avoid unnecessary literal loads ARM: ftrace: avoid redundant loads or clobbering IP ARM: ftrace: use trampolines to keep .init.text in branching range ARM: ftrace: use ADD not POP to counter PUSH at entry ARM: ftrace: ensure that ADR takes the Thumb bit into account ARM: make get_current() and __my_cpu_offset() __always_inline ...

ARM: Spectre-BHB workaround

2022-03-05T10:42:07Z

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as well to be safe, which is affected by Spectre V2 in the same ways as Cortex-A15. Reviewed-by: Catalin Marinas Signed-off-by: Russell King (Oracle)

ARM: report Spectre v2 status through sysfs

2022-03-05T10:41:22Z

As per other architectures, add support for reporting the Spectre vulnerability status via sysfs CPU. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle)

ARM: percpu: add SMP_ON_UP support

2021-12-06T11:49:17Z

Permit the use of the TPIDRPRW system register for carrying the per-CPU offset in generic SMP configurations that also target non-SMP capable ARMv6 cores. This uses the SMP_ON_UP code patching framework to turn all TPIDRPRW accesses into reads/writes of entry #0 in the __per_cpu_offset array. While at it, switch over some existing direct TPIDRPRW accesses in asm code to invocations of a new helper that is patched in the same way when necessary. Note that CPU_V6+SMP without SMP_ON_UP results in a kernel that does not boot on v6 CPUs without SMP extensions, so add this dependency to Kconfig as well. Acked-by: Linus Walleij Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Tested-by: Marc Zyngier Tested-by: Vladimir Murzin # ARMv7M

ARM: 9137/1: disallow CONFIG_THUMB with ARMv4

2021-10-25T12:12:33Z

We can currently build a multi-cpu enabled kernel that allows both ARMv4 and ARMv5 CPUs, and also supports THUMB mode in user space. However, returning to user space in this configuration with the usr_ret macro requires the use of the 'bx' instruction, which is refused by the assembler: arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:937: Error: selected processor does not support `bx lr' in ARM mode arch/arm/kernel/entry-armv.S:960: Error: selected processor does not support `bx lr' in ARM mode arch/arm/kernel/entry-armv.S:1003: Error: selected processor does not support `bx lr' in ARM mode :2:2: note: instruction requires: armv4t bx lr While it would be possible to handle this correctly in principle, doing so seems to not be worth it, if we can simply avoid the problem by enforcing that a kernel supporting both ARMv4 and a later CPU architecture cannot run THUMB binaries. This turned up while build-testing with clang; for some reason, gcc never triggered the problem. Reviewed-by: Nick Desaulniers Reviewed-by: Ard Biesheuvel Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle)

ARM: 9136/1: ARMv7-M uses BE-8, not BE-32

2021-10-25T12:12:33Z

When configuring the kernel for big-endian, we set either BE-8 or BE-32 based on the CPU architecture level. Until linux-4.4, we did not have any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid is in that category, adn we get a build error because of this: arch/arm/kernel/module-plts.c: In function 'get_module_plt': arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration] This comes down to picking the wrong default, ARMv7-M uses BE8 like ARMv7-A does. Changing the default gets the kernel to compile and presumably works. https://lore.kernel.org/all/1455804123-2526139-2-git-send-email-arnd@arndb.de/ Tested-by: Vladimir Murzin Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle)

ARM: 9091/1: Revert "mm: qsd8x50: Fix incorrect permission faults"

2021-06-13T17:16:43Z

This reverts commit e220ba60223a9d63e70217e5b112160df8c21cea. The VERIFY_PERMISSION_FAULT is introduced since 2009 but no one use it, just revert it and clean unused comment. Signed-off-by: Kefeng Wang Signed-off-by: Russell King

ARM: drop efm32 platform

2021-01-15T16:42:10Z

I didn't touch this code since it served as a platform to introduce ARMv7-M support to Linux. The only known machine that runs Linux has only 4 MiB of RAM (that originally only exists to hold the display's framebuffer). There are no known users and no further use foreseeable, so drop the code. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210115155130.185010-2-u.kleine-koenig@pengutronix.de' Signed-off-by: Arnd Bergmann