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

New patch I think, since you say Catalin specifically asked for the
current setup.

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