Re: [PATCH v5 0/6] Cache coherency management subsystem

["Arnd Bergmann" <arnd@arndb.de>]

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

    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