On Wed, Jan 07, 2026 at 11:07:03PM +0100, Arnd Bergmann wrote:

On Wed, Jan 7, 2026, at 16:58, Will Deacon wrote:

quoted

On Tue, Jan 06, 2026 at 01:54:39PM +0000, Marc Zyngier wrote:

quoted

On Mon, 05 Jan 2026 20:50:41 +0000, Will Deacon [off-list ref] wrote:
Subject: [PATCH] arm64: Unconditionally enable LSE support

LSE atomics have been in the architecture since ARMv8.1 (released in
2014), and are hopefully supported by all modern toolchains.

Drop the optional nature of LSE support in the kernel, and always
compile the support in, as this really is very little code. LL/SC
still is the default, and the switch to LSE is done dynamically.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/Kconfig             | 16 ----------------
 arch/arm64/include/asm/insn.h  | 23 -----------------------
 arch/arm64/include/asm/lse.h   |  9 ---------
 arch/arm64/kernel/cpufeature.c |  2 --
 arch/arm64/kvm/at.c            |  7 -------
 arch/arm64/lib/insn.c          |  2 --
 arch/arm64/net/bpf_jit_comp.c  |  7 -------
 7 files changed, 66 deletions(-)

I think we should go ahead with this.

Initially, I thought we'd need some surgery to cpufeature.c so that
cpus_have_final_cap() could take the _likely_ path for LSE but it looks
like that's only relevant for KVM's AT handling and the common atomic_t
APIs use alternative_has_cap_likely() already.

I'm not entirely convinced by the direction. Removing compile-time
options and complexity from #ifdef blocks is clearly an advantage,
but I'm a bit worried about at least the ARM64_USE_LSE_ATOMICS 
option still being valuable.

The boot-time patching for all atomics adds complexity as well, and
being able to configure it out can be helpful in a number of
scenarios:

- I've seen several scenarios where code size is extremely important,
  and being able to compile out any runtime-detected features 
  saves some space. In a defconfig kernel, this is about 1.1% of .text.
  Being able to select just the LSE version without the patching
  may be even more valuable these days, but almost
  all embedded systems I see are still ARMv8.0 (Cortex-A53 and
  Cortex-A35) without LSE.
- We have an experimental patch set for CONFIG_XIP_KERNEL on arm64,
  which inherently requires not patching at all, and requires
  the opposite patches for other features and errata workarounds.
- The amount of nested macros and inline functions for the arm64
  atomics is large enough to slow down compilation, #including
  linux/spinlock.h shouldn't really result in >1MB of preprocessed
  source code. (this is a much harder problem to solve)

In the absence of a concerted and persistent upstream effort to solve
some of these problems, I think retaining ARM64_USE_LSE_ATOMICS is
a tiny drop in the ocean and yet its presence does lead to build
breakages and additional testing burden today, which we could avoid.

So I'm inclined to merge Marc's changes and if folks aggressively want
to optimise the kernel's memory footprint in future, perhaps they can
try to implement some of your suggestions above (such as forcing the
LSE atomics into the compiled Image).

Will