From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CFF049620; Wed, 7 Jan 2026 18:10:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767809413; cv=none; b=uSLXNowTrT/+lQkAqZ54JvGav071f9lEnlsWMFuUxGe86ghPXM6d2DD21zd4QkLvlPkwTxpowbdQpMEqDXVmpLmXBActZPI+f4341lzrlmfGCfIK8qKpOUcO4akfuCdL2YZAVrmM/+WTD8434T66qycCydnqN+6IVztvBjhD0fM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767809413; c=relaxed/simple; bh=PFsvF3uhSGjY1eiFSePwQw+5Hfbwu2S30URjOMhpGsE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=o2OsEbrV1fiMwRh3OMoLv9kgf7zb3AW89X/5/ZQcOsuvsexnxGqty+muS23gS7ojgOKLq/dde1MClNcw97xW/wZDqpC4XQCEyyKjUMXj2OiDWDtS6m4BKXg4CCXdt60Br3XX2ixIh9fqsUuM94+GTnB/fEqmefukGIpTLgEb6qU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dY0zi4Tf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dY0zi4Tf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BF3C1C4CEF1; Wed, 7 Jan 2026 18:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767809412; bh=PFsvF3uhSGjY1eiFSePwQw+5Hfbwu2S30URjOMhpGsE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dY0zi4TfG9yoBqj5WUxApBt37f1tTN5BXtN2X6Z/BNba0Busula53kHvnSWeyjrlN Qtqh6LUX7CidrZvbZu4ZR5WZzOndVn+Py7MwOaWO7u4rqwfmCwgLrjGQhsWcz6Ts81 mAgze10yov4ht+GNCEM5czqo//D72gkEYCvZ1YguC9dhAFqVveyUUHjojjjECnISbd psOPCqdunIsq+CaRHQONXLrnCV8JBs/XL8hCh9Hv8gJDamUs9lmQuGOP8kO1l8r48U PLllmQLS0y0b9dVUga37praImpd13A8tYh8HMcCr+Ml1MrOr8S3AbYQpXrpuolXQWM XcvZlVDOaEesw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vdXz0-00000000AIB-38GO; Wed, 07 Jan 2026 18:10:10 +0000 Date: Wed, 07 Jan 2026 18:10:10 +0000 Message-ID: <865x9dmgzh.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: Lukas Bulwahn , Catalin Marinas , linux-arm-kernel@lists.infradead.org, Mark Rutland , Arnd Bergmann , Vegard Nossum , Kees Cook , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Lukas Bulwahn Subject: Re: [PATCH] arm64: Kconfig: deprecate redundant ARM64_USE_LSE_ATOMICS In-Reply-To: References: <20251223110730.121239-1-lukas.bulwahn@redhat.com> <86h5syn8ww.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: will@kernel.org, lbulwahn@redhat.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, arnd@arndb.de, vegard.nossum@oracle.com, kees@kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, lukas.bulwahn@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 07 Jan 2026 15:58:28 +0000, 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 wrote: > > > > > > [+Marc] > > > > > > On Tue, Dec 23, 2025 at 12:07:30PM +0100, Lukas Bulwahn wrote: > > > > From: Lukas Bulwahn > > > > > > > > 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 > > 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 > > --- > > 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. Ack. Series posted at [1]. Thanks, M. [1] https://lore.kernel.org/r/20260107180701.2858276-1-maz@kernel.org -- Without deviation from the norm, progress is not possible.