[PATCH v5 0/6] Cache coherency management subsystem

[Arnd Bergmann]

On Fri, Nov 14, 2025, at 16:57, Jonathan Cameron wrote:
> On Fri, 14 Nov 2025 15:07:33 +0100 "Arnd Bergmann" <arnd at arndb.de> wrote:
> 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

Works for me.

> 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

The _FOR_HOTPLUG does feel a little more specific than it should be,
but I haven't come up with a better name for it yet. We'll
probably figure that out if we ever get a second driver here.

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

Agreed.

     Arnd