Re: [PATCH] arm64: Kconfig: deprecate redundant ARM64_USE_LSE_ATOMICS

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Jan 7, 2026, at 16:58, Will Deacon wrote:
> On Tue, Jan 06, 2026 at 01:54:39PM +0000, Marc Zyngier wrote:
>> On Mon, 05 Jan 2026 20:50:41 +0000, Will Deacon <will@kernel.org> 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)

      Arnd