From: Conor Dooley <conor@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: conor@kernel.org, Conor Dooley <conor.dooley@microchip.com>,
Randy Dunlap <rdunlap@infradead.org>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
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 [thread overview]
Message-ID: <20251119-zippy-distinct-1e2a7da7b69b@spud> (raw)
From: Conor Dooley <conor.dooley@microchip.com>
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 <rdunlap@infradead.org>
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
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 <catalin.marinas@arm.com>
CC: Will Deacon <will@kernel.org>
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
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
config ARCH_HAS_MEMREMAP_COMPAT_ALIGN
bool
--
2.51.0
next reply other threads:[~2025-11-19 19:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 19:08 Conor Dooley [this message]
2025-11-19 21:22 ` [PATCH v1] arm64, lib: make ARM64 select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION not GENERIC_CPU_CACHE_MAINTENANCE Randy Dunlap
2025-11-20 17:30 ` Catalin Marinas
2025-11-20 19:29 ` Conor Dooley
2025-11-20 20:13 ` Randy Dunlap
2025-11-20 21:40 ` Catalin Marinas
2025-11-20 23:25 ` Randy Dunlap
2025-11-21 10:48 ` Jonathan Cameron
2025-11-21 18:44 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251119-zippy-distinct-1e2a7da7b69b@spud \
--to=conor@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=conor.dooley@microchip.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox