[PATCH v5 0/6] Cache coherency management subsystem

[Jonathan Cameron]

On Fri, 14 Nov 2025 15:07:33 +0100
"Arnd Bergmann" <arnd at arndb.de> wrote:

> On Fri, Nov 14, 2025, at 13:52, Conor Dooley wrote:
> > On Fri, Nov 14, 2025 at 12:49:58PM +0000, Jonathan Cameron wrote:  
> >> On Sat, 8 Nov 2025 20:02:52 +0000 Conor Dooley <conor at kernel.org> wrote:  
> >> > 
> >> > On Fri, Oct 31, 2025 at 11:17:03AM +0000, Jonathan Cameron wrote:  
> >> > > Support system level interfaces for cache maintenance as found on some
> >> > > ARM64 systems. It is expected that systems using other CPU architectures
> >> > > (such as RiscV) that support CXL memory and allow for native OS flows
> >> > > will also use this. This is needed for correct functionality during
> >> > > various forms of memory hotplug (e.g. CXL). Typical hardware has MMIO
> >> > > interface found via ACPI DSDT. A system will often contain multiple
> >> > > hardware instances.
> >> > > 
> >> > > Includes parameter changes to cpu_cache_invalidate_memregion() but no
> >> > > functional changes for architectures that already support this call.
> >> > > 
> >> > > How to merge?
> >> > > - Current suggestion would be via Conor's drivers/cache tree which routes
> >> > >   through the SoC tree.    
> >> > 
> >> > I was gonna put this in linux-next, but I'm not really sure that Arnd
> >> > was satisfied with the discussion on the previous version about
> >> > suitability of the directory: https://lore.kernel.org/all/20251028114348.000006ed@huawei.com/
> >> > 
> >> > Arnd, did that response satisfy you, or nah?  
> >> 
> >> Seems Arnd is busy.  Conor, if you are happy doing so, maybe push it to a tree
> >> linux-next picks up, but hold off on the pull request until Arnd has had a chance
> >> to reply?  
> >
> > Yeah, I did step one of that last night and will put it in linux-next
> > from Monday. Ultimately the PR goes to Arnd, so he can judge it there
> > anyway.  
> 
> Sorry about the delay on my side. I've read up on it again and understand
> better where we are with this now.
> 
> I think the implementation is fine, and placing it in drivers/cache/
> is also ok, given that we don't have a better place for it.
> 
> However, this does feel sufficiently different from the three existing
> drivers in drivers/cache that I think we should have separate
> submenus in Kconfig and describe them differently:
> 
> - the arch/riscv drivers are specifically for managing coherency
>   between the CPU and any device driver using the linux/dma-mapping.h
>   interfaces to manage coherency using CPU specific interfaces.
> 
> - the new driver does not interface with linux/dma-mapping.h
>   or a CPU specific register set, and as I understand that would
>   make no sense here. The only similarities are that it manages
>   coherency between multiple entities that access the same memory
>   and have private caches for that.
> 
> If we can come up with better names for the two things, I'd
> like them to have distinct submenus. Something like the draft
> below for the existing drivers would work, in addition to
> a new menu that only contains the one driver for now. I've
> moved the 'depends on RISCV' into the 'menu' here, since that
> is the only thing using it today (32-bit arm has the same thing
> in arch/arm/mm/cache-*.S with a different interface, most others
> only have an architected interface).

Hi Arnd,

Thanks for taking another look.

Agreed splitting the menus reduces chance of confusion, so makes
sense to me as well.

Implementation wise I think we have to use menuconfig + bool if we want
to have help and dependencies and then an if block under that.
The syntax for Kconfig always leaves me finding an example to copy
rather than finding it intuitive

menuconfig CACHEMAINT_FOR_DMA
	bool "Cache management for noncoherent DMA"
	depends on RISCV
	help
	  These drivers implement support for noncoherent DMA master devices
	  on platforms that lack the standard CPU interfaces for this.

if CACHEMAINT_FOR_DMA
... drivers here...

endif #CACHEMAINT_FOR_DMA

menuconfig CACHEMAINT_FOR_HOTPLUG
	bool "Cache management for hotplug like operations"
	depends on GENERIC_CPU_CACHE_MAINTENANCE
	help
	   These drivers implement support for cache management flows
	   as required for action such as memory hotplug on platforms
	   where this is done by platform specific interfaces.

if CACHEMAINT_FOR_HOTPLUG
... drivers here

endif #CACHEMAINT_FOR_HOTPLUG

Alternative would be to hope the short text is enough and use

menu "Cache management for noncoherent DMA"
	visible if RISCV

endmenu

I'm not sure if the 'hotplug like' is close enough to all the cases
for device drivers that provide the services needed to implement
ARCH_HAS_CPU_CACHE_INVALIDATE_MEMEGION

Alternative might be to phrase around pushing beyond the point of
coherence, but that seems to be an ARM specific term and would
seem to incorporate fine grained sharing where this interface might
work but isn't a good solution.

Thanks,

Jonathan

> 
>     Arnd
> 
> ---
> diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> index db51386c663a..8a49086eb8af 100644
> --- a/drivers/cache/Kconfig
> +++ b/drivers/cache/Kconfig
> @@ -1,9 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0
> -menu "Cache Drivers"
> +menu "Cache management for noncoherent DMA"
> +       depends on RISCV
> +       help
> +         These drivers implement support for noncoherent DMA master devices
> +         on platforms that lack the standard CPU interfaces for this.

>  
>  config AX45MP_L2_CACHE
>         bool "Andes Technology AX45MP L2 Cache controller"
> -       depends on RISCV
>         select RISCV_NONSTANDARD_CACHE_OPS
>         help
>           Support for the L2 cache controller on Andes Technology AX45MP platforms.
> @@ -16,7 +19,6 @@ config SIFIVE_CCACHE
>  
>  config STARFIVE_STARLINK_CACHE
>         bool "StarFive StarLink Cache controller"
> -       depends on RISCV
>         depends on ARCH_STARFIVE
>         depends on 64BIT
>         select RISCV_DMA_NONCOHERENT