arm: update in-source documentation references

The Arm documentation has moved to Documentation/arch/arm; update
references within arch/arm to match.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Al

arm: update in-source documentation references

The Arm documentation has moved to Documentation/arch/arm; update
references within arch/arm to match.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

show more ...

ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations

ARMv8 is a superset of ARMv7, and all the ARMv8 features are
discoverable with a set of ID registers. It means that we can
use CPU_V7 to

ARM: Make CONFIG_CPU_V7 valid for 32bit ARMv8 implementations

ARMv8 is a superset of ARMv7, and all the ARMv8 features are
discoverable with a set of ID registers. It means that we can
use CPU_V7 to guard ARMv8 features at compile time.

This commit simply amends the CPU_V7 configuration symbol comment
to reflect that CPU_V7 also covers ARMv8.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Zaid Al-Bassam <zalbassam@google.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230317195027.3746949-7-zalbassam@google.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

ARM: 9288/1: Kconfigs: fix spelling & grammar

Fix spelling (reported by codespell) and grammar in Arm Kconfig files.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-arm-kernel@lists.i

ARM: 9288/1: Kconfigs: fix spelling & grammar

Fix spelling (reported by codespell) and grammar in Arm Kconfig files.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: patches@armlinux.org.uk
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

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

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: 9212/1: domain: Modify Kconfig help text

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 <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

ARM: rework endianess selection

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

ARM: rework endianess selection

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 <arnd@arndb.de>

show more ...

ARM: Spectre-BHB workaround

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 S

ARM: Spectre-BHB workaround

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 <catalin.marinas@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

ARM: report Spectre v2 status through sysfs

As per other architectures, add support for reporting the Spectre
vulnerability status via sysfs CPU.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

ARM: report Spectre v2 status through sysfs

As per other architectures, add support for reporting the Spectre
vulnerability status via sysfs CPU.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

ARM: percpu: add SMP_ON_UP support

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 use

ARM: percpu: add SMP_ON_UP support

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 <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M

show more ...

ARM: 9137/1: disallow CONFIG_THUMB with ARMv4

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

ARM: 9137/1: disallow CONFIG_THUMB with ARMv4

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
<instantiation>: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 <ndesaulniers@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

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

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 pl

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

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 <vladimir.murzin@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

show more ...

ARM: Spectre-BHB workaround

commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream.

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57,
Cortex-A72, Cortex-A73 and Cortex-A75. We also in

ARM: Spectre-BHB workaround

commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream.

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 <catalin.marinas@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
[changes due to lack of SYSTEM_FREEING_INITMEM - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

ARM: report Spectre v2 status through sysfs

commit 9dd78194a3722fa6712192cdd4f7032d45112a9a upstream.

As per other architectures, add support for reporting the Spectre
vulnerability status via sysf

ARM: report Spectre v2 status through sysfs

commit 9dd78194a3722fa6712192cdd4f7032d45112a9a upstream.

As per other architectures, add support for reporting the Spectre
vulnerability status via sysfs CPU.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

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

[ Upstream commit 345dac33f58894a56d17b92a41be10e16585ceff ]

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU archi

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

[ Upstream commit 345dac33f58894a56d17b92a41be10e16585ceff ]

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 <vladimir.murzin@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

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

This reverts commit e220ba60223a9d63e70217e5b112160df8c21cea.

The VERIFY_PERMISSION_FAULT is introduced since 2009 but no
one use

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

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 <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: drop efm32 platform

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 o

ARM: drop efm32 platform

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 <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20210115155130.185010-2-u.kleine-koenig@pengutronix.de'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD

LLD does not yet support any big endian architectures. Make this config
non-selectable when using LLD until LLD is fixed.

Link: https://gi

ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD

LLD does not yet support any big endian architectures. Make this config
non-selectable when using LLD until LLD is fixed.

Link: https://github.com/ClangBuiltLinux/linux/issues/965

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD

commit 28187dc8ebd938d574edfc6d9e0f9c51c21ff3f4 upstream.

LLD does not yet support any big endian architectures. Make this config
non-sele

ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD

commit 28187dc8ebd938d574edfc6d9e0f9c51c21ff3f4 upstream.

LLD does not yet support any big endian architectures. Make this config
non-selectable when using LLD until LLD is fixed.

Link: https://github.com/ClangBuiltLinux/linux/issues/965

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

lib/vdso: Cleanup clock mode storage leftovers

Now that all architectures are converted to use the generic storage the
helpers and conditionals can be removed.

Signed-off-by: Thomas Gleixner <tglx@

lib/vdso: Cleanup clock mode storage leftovers

Now that all architectures are converted to use the generic storage the
helpers and conditionals can be removed.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.470699892@linutronix.de

show more ...

ARM/arm64: vdso: Use common vdso clock mode storage

Convert ARM/ARM64 to the generic VDSO clock mode storage. This needs to
happen in one go as they share the clocksource driver.

Signed-off-by: Tho

ARM/arm64: vdso: Use common vdso clock mode storage

Convert ARM/ARM64 to the generic VDSO clock mode storage. This needs to
happen in one go as they share the clocksource driver.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Link: https://lkml.kernel.org/r/20200207124403.363235229@linutronix.de

show more ...

ARM: 8930/1: Add support for generic vDSO

The arm vDSO library requires some adaptations to take advantage of
the newly introduced generic vDSO library.

Introduce the following changes:
- Modifica

ARM: 8930/1: Add support for generic vDSO

The arm vDSO library requires some adaptations to take advantage of
the newly introduced generic vDSO library.

Introduce the following changes:
- Modification vdso.c to be compliant with the common vdso datapage
- Use of lib/vdso for gettimeofday
- Implementation of elf note

Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

show more ...

ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP

MMP3 has a PJ4B with a Tauros 3 cache controller that uses CACHE_L2X0
instead, while CACHE_TAUROS2 is present on PJ4 and PJ1 (Mohawk) based
platf

ARM: mmp: don't select CACHE_TAUROS2 on all ARCH_MMP

MMP3 has a PJ4B with a Tauros 3 cache controller that uses CACHE_L2X0
instead, while CACHE_TAUROS2 is present on PJ4 and PJ1 (Mohawk) based
platforms only.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>

show more ...

arm: select the dma-noncoherent symbols for all swiotlb builds

We need to provide the arch hooks for non-coherent dma-direct
and swiotlb for all swiotlb builds, not just when LPAS is enabled.
Withou

arm: select the dma-noncoherent symbols for all swiotlb builds

We need to provide the arch hooks for non-coherent dma-direct
and swiotlb for all swiotlb builds, not just when LPAS is enabled.
Without that the Xen build that selects SWIOTLB indirectly through
SWIOTLB_XEN fails to build.

Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs")
Reported-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Stefan Wahren <wahrenst@gmx.net>

show more ...

ARM: remove ks8695 platform

ks8695 is an older SoC originally made by Kendin, which was later acquired
by Micrel, and subsequently by Microchip.

The platform port was originally contributed by Andr

ARM: remove ks8695 platform

ks8695 is an older SoC originally made by Kendin, which was later acquired
by Micrel, and subsequently by Microchip.

The platform port was originally contributed by Andrew Victor and Ben
Dooks, and later maintained by Greg Ungerer.

When I recently submitted cleanups, but Greg noted that the platform no
longer boots and nobody is using it any more, we decided to remove it.

Link: https://lore.kernel.org/r/20190809202749.742267-2-arnd@arndb.de
Cc: Andrew Victor <linux@maxim.org.za>
Acked-by: Ben Dooks <ben-linux@fluff.org>
Link: https://wikidevi.com/wiki/Micrel
Link: https://lore.kernel.org/linux-arm-kernel/2bc41895-d4f9-896c-0726-0b2862fcbf25@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

arm: use swiotlb for bounce buffering on LPAE configs

The DMA API requires that 32-bit DMA masks are always supported, but on
arm LPAE configs they do not currently work when memory is present
above

arm: use swiotlb for bounce buffering on LPAE configs

The DMA API requires that 32-bit DMA masks are always supported, but on
arm LPAE configs they do not currently work when memory is present
above 4GB. Wire up the swiotlb code like for all other architectures
to provide the bounce buffering in that case.

Fixes: 21e07dba9fb11 ("scsi: reduce use of block bounce buffers").
Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Tested-by: Vignesh Raghavendra <vigneshr@ti.com>

show more ...

docs: arm: convert docs to ReST and rename to *.rst

Converts ARM the text files to ReST, preparing them to be an
architecture book.

The conversion is actually:
- add blank lines and identation in

docs: arm: convert docs to ReST and rename to *.rst

Converts ARM the text files to ReST, preparing them to be an
architecture book.

The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by Corentin Labbe <clabbe.montjoie@gmail.com> # For sun4i-ss

show more ...