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

On Mon, 05 Jan 2026 20:50:41 +0000,
Will Deacon [off-list ref] wrote:

quoted

[+Marc]

On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote:

quoted

From: Lukas Bulwahn <redacted>

Currently, the config options ARM64_USE_LSE_ATOMICS and ARM64_LSE_ATOMICS
are equivalent, i.e., ARM64_LSE_ATOMICS is true if and only if
ARM64_USE_LSE_ATOMICS is true.

Prior to commit 395af861377d ("arm64: Move the LSE gas support detection to
Kconfig")---included in v5.6-rc1---only the config option ARM64_LSE_ATOMICS
was defined, and the check for gas support was done in the Makefile. This
mentioned commit then introduces the config option ARM64_USE_LSE_ATOMICS to
be the promptable option, and changes the semantics of ARM64_LSE_ATOMICS to
check for the gas support.

Note that there is then some minor refactoring in commit 2decad92f473
("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically"), putting this
gas support check into its own config option AS_HAS_LSE_ATOMICS, but the
logic remains the same. Since every binutils version defined suitable for
kernel compilation then eventually included the required support, the
config option AS_HAS_LSE_ATOMICS and the dependency was dropped with
commit 2555d4c68720 ("arm64: drop binutils version checks"). This then
makes ARM64_USE_LSE_ATOMICS and ARM64_LSE_ATOMICS equivalent. Hence, one
of the two config options can be dropped now.

Considerations for the decision which config option to drop:

  - ARM64_USE_LSE_ATOMICS is promptable by the user since its introduction
    in 2020. So there might be some Kconfig fragments that define this
    config option and expect that this then implies ARM64_LSE_ATOMICS to be
    set. However, within the kernel tree, there is no existing config file
    referring to that option. So, it is unlikely to be widely used.
  - ARM64_LSE_ATOMICS is used in nine places within the arm64 directory in
    the current kernel tree.
  - ARM64_USE_LSE_ATOMICS is the only config option that contains the infix
    string _USE_ to enable support and use of an arm64 architectural
    feature. However, there is not a very stringent and consistent naming
    convention for Kconfig options throughout the kernel tree anyway.
  - The use of the transitional attribute allows to simplify transitioning
    to a different Kconfig symbol name, but also adds some intermediate
    definition to be removed later eventually.

After thoughtful consideration, keep ARM_LSE_ATOMICS and remove
ARM64_USE_LSE_ATOMICS in a two-step approach, first deprecate
ARM64_USE_LSE_ATOMICS with the transitional attribute here and then plan
to completely remove it in two or three years with a further dedicated
commit then.

Marc was talking about removing ARM64_LSE_ATOMICS entirely the other day
after it bit him with a KVM change. If all supported assemblers understand
the LSE instructions, let's just do that?

That'd be my preferred option. Having config options for things that
we can detect and patch at runtime makes coverage a lot more difficult
than it should be. I'd also love to kill CONFIG_ARM64_PAN, for
example. In any case, here's my take on this, based on -rc4.

Thanks,

	M.

From 3ab18194eefd2017fb1cea6764adb0634f5946da Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz@kernel.org>
Date: Tue, 6 Jan 2026 13:44:14 +0000
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.

If we do something similar for PAN, then system_uses_hw_pan() probably
wants the polarity switching from unlikely to likely.

Will