Re: [PATCH v6 3/7] lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Tue, 18 Nov 2025 17:18:31 -0800
Randy Dunlap <rdunlap@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@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@huawei.com>

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.  
> 
>