[PATCH v6 3/7] lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION

[Jonathan Cameron]

On Wed, 19 Nov 2025 18:44:43 +0000
Conor Dooley <conor at kernel.org> wrote:

> On Wed, Nov 19, 2025 at 09:42:55AM +0000, Jonathan Cameron wrote:
> > On Tue, 18 Nov 2025 17:18:31 -0800
> > Randy Dunlap <rdunlap at infradead.org> wrote:
> >   
> > > On 11/18/25 1:30 AM, Jonathan Cameron wrote:  
> > > > 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.    
> > > 
> > > I do much prefer this alternative.
> > >   
> > > > Thanks for your help with this.    
> > > 
> > > Thanks for listening.  
> > 
> > Conor,
> > 
> > Given it is your proposed solution, I'm guessing you'll either spin a patch
> > on top or squash it into original.  If you spin a patch for this.
> > 
> > Acked-by: Jonathan Cameron <jonathan.cameron at huawei.com>  
> 
> New patch I think, since you say Catalin specifically asked for the
> current setup.

Whilst Catalin proposed the form used, the basis was about having two
entrees for effectively the same thing in arm64/Kconfig and this
still has the single entry property so should be fine.

Jonathan

> 
> > 
> > Thanks again!
> > 
> > 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.    
> > > 
> > >   
> >   
>