[PATCH v6 3/7] lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION

[Jonathan Cameron]

On Tue, 18 Nov 2025 00:13:07 +0000
Conor Dooley <conor at kernel.org> wrote:

> On Mon, Nov 17, 2025 at 10:51:11AM -0800, Randy Dunlap wrote:
> > Hi,
> > 
> > On 11/17/25 2:47 AM, Jonathan Cameron wrote:  
> > > diff --git a/lib/Kconfig b/lib/Kconfig
> > > index e629449dd2a3..e11136d188ae 100644
> > > --- a/lib/Kconfig
> > > +++ b/lib/Kconfig
> > > @@ -542,6 +542,10 @@ config MEMREGION
> > >  config ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
> > >  	bool
> > >  
> > > +config GENERIC_CPU_CACHE_MAINTENANCE
> > > +	bool
> > > +	select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
> > > +
> > >  config ARCH_HAS_MEMREMAP_COMPAT_ALIGN
> > >  	bool  
> > 
> > Architectures and/or platforms select ARCH_HAS_*.
> > 
> > With this change above, it becomes the only entry in
> > lib/Kconfig that does "select ARCH_HAS_anytning".
> > 
> > so I think this is wrong, back*wards.  
> 
> 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.

Exactly this. Catalin requested this form in response to an earlier
version where arm64 Kconfig just had both selects for pretty much that
reason. This is expected to be used on a subset of architectures.
It is similar to things like GENERIC_ARCH_NUMA in this respect (though the
arch_numa_init() etc in there are called only from other arch code
so no ARCH_HAS_ symbols are associated with them).

> Alternatively, something like

I'm fine with this solution if Randy prefers it.

Thanks for your help with this.

Jonathan

> | 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
> 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.
> 
> I didn't really care which way it went, and was gonna post something to
> squash and avoid another revision, but I found the resultant Kconfig
> setup to be make less sense to me than what came before. If the switched
> around version is less likely to be problematic etc, then sure, but I
> amn't convinced by switching it at a first glance.
>