[PATCH v6 3/7] lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION

[Randy Dunlap]

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.


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


-- 
~Randy