From nobody Tue Dec 2 02:19:02 2025 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 6ADAD315D24 for ; Wed, 19 Nov 2025 19:09:30 +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=1763579370; cv=none; b=XurR3BJA4bpDtU3cJ3hk6Jvb1+jpJ6HQ2rOWffaiEHMvkYQUB2bSwqh3vNd5BC8x4pqHy1AXtVSxyw+5QZD9eDOcZBsYq1hC4mJOsaIcp7/VA1c404ZBDEECU++ckxLLTYQT1LMNbobM4JZE4JiNfJwx01F5/ZCnNeeoH/Um5jc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763579370; c=relaxed/simple; bh=m/iEeMo6XQiw9/Dx9eONf5PKKCUoFowTGyoe2SjIzd4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=KzQMfAxmr6qV4Cno45U502zio7DRU95IHf5jihTtIxYSw+5nGx2NKX1BLyGFMgC5312qDLSewo4TA4WeJNg1rWuxb/Cdo3G7toYuKXlotudnwteGicFBdwmbQK9v270FXA2hf7ZBu8lyqjR8w4G4o/kcE3+1phG+jPAY5RMh6uM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P5am+x7g; 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="P5am+x7g" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97564C4CEF5; Wed, 19 Nov 2025 19:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763579369; bh=m/iEeMo6XQiw9/Dx9eONf5PKKCUoFowTGyoe2SjIzd4=; h=From:To:Cc:Subject:Date:From; b=P5am+x7g9L2pCMnLeMn5JjMvCZrQReRu6Y6E4L3Tx1hurLH9I7mKdNuQSRHr9peBE mjlM2TX2rm5pGraV8ocafSLZwFHsUv/yYAHNhr6hmTJk7ukpmU9KAX4bXWGhkm13oB DWVBPuiH9ydL7bKkp+/y9E+riJgOPAjHXLuB8exofl2cCkwTZLEO72BEP9DpH2Ew/l okqzcJ+KbYy9QHlYbg4foP1b1W5ur53q/uS63gvkqglgRa1QrKOo43DXssf96/5fo0 BkDBgdU6sZq8HiVUyspWEfg06YPa0lPEwGuO09vPi3FVQnnu/CHvrVRSLnPdmqvvFt MzT0zthjNxmHA== From: Conor Dooley To: linux-arm-kernel@lists.infradead.org Cc: conor@kernel.org, Conor Dooley , Randy Dunlap , Jonathan Cameron , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org Subject: [PATCH v1] arm64, lib: make ARM64 select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION not GENERIC_CPU_CACHE_MAINTENANCE Date: Wed, 19 Nov 2025 19:08:27 +0000 Message-ID: <20251119-zippy-distinct-1e2a7da7b69b@spud> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3012; i=conor.dooley@microchip.com; h=from:subject:message-id; bh=YAGnfvTEuxQMcQ2392J834Z3DvqWo8GwePPM6woMlH0=; b=owGbwMvMwCVWscWwfUFT0iXG02pJDJlyoqsmuZ9KDPNhq83Pnxff9XHJr5wtql++hWZ9vKjWE daoNFG4o5SFQYyLQVZMkSXxdl+L1Po/Ljuce97CzGFlAhnCwMUpABPZUMjIMNNAtmiDeWbZzSeN Gw5eEgm6zFs+5+4KL6u/18W884/tDGdkuM4mdC377u2CNpElnNVF2bHnLx07cXPOqQMCfKc3+6z qYwQA X-Developer-Key: i=conor.dooley@microchip.com; a=openpgp; fpr=F9ECA03CF54F12CD01F1655722E2C55B37CF380C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Conor Dooley Randy pointed out that the newly added GENERIC_CPU_CACHE_MAINTENANCE was unusual, in that it selected an ARCH_HAS_... option, unlikely anything else in lib/Kconfig. Switch things around, so that arm64 selects ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION and then GENERIC_CPU_CACHE_MAINENANCE will in turn be automatically enabled. Suggested-by: Randy Dunlap Acked-by: Jonathan Cameron Signed-off-by: Conor Dooley Acked-by: Randy Dunlap --- Catalin, you voiced a take on this already apparently that lead to the current implementation so I'd like an ack from you or Will here. My comment on the original thread, in response to Randy saying it was backwards, that accompanied the diff was: Maybe it is backwards, but I feel like this way is more logical. ARM64 has memregion invalidation only because this generic approach is enabled, so the arch selects what it needs to get the support. Alternatively, something like (diff was here) implies (to me at least) that arm64 has memregion invalidation as an architectural feature and that the GENERIC_CPU_CACHE_MAINTENANCE option is a just common cross-arch code, like generic entry etc, rather than being the option gating the drivers that provide the feature in the first place. Ultimately, the .config produced is the same either way, just depends on what impression you want to give in the arch Kconfig, which might not really be a big deal, just semantics. Either way, I'd like an ack :) Cheers, Conor. CC: Catalin Marinas CC: Will Deacon CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org --- arch/arm64/Kconfig | 2 +- lib/Kconfig | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 5f7f63d24931..75b2507f7eb2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -21,6 +21,7 @@ config ARM64 select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE select ARCH_HAS_CACHE_LINE_SIZE select ARCH_HAS_CC_PLATFORM + select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION select ARCH_HAS_CURRENT_STACK_POINTER select ARCH_HAS_DEBUG_VIRTUAL select ARCH_HAS_DEBUG_VM_PGTABLE @@ -146,7 +147,6 @@ config ARM64 select GENERIC_ARCH_TOPOLOGY select GENERIC_CLOCKEVENTS_BROADCAST select GENERIC_CPU_AUTOPROBE - select GENERIC_CPU_CACHE_MAINTENANCE select GENERIC_CPU_DEVICES select GENERIC_CPU_VULNERABILITIES select GENERIC_EARLY_IOREMAP diff --git a/lib/Kconfig b/lib/Kconfig index 09aec4a1e13f..ac223e627bc5 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -544,8 +544,9 @@ config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION bool =20 config GENERIC_CPU_CACHE_MAINTENANCE - bool - select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION + def_bool y + depends on ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION + depends on ARM64 =20 config ARCH_HAS_MEMREMAP_COMPAT_ALIGN bool --=20 2.51.0