Re: [PATCH] dma-mapping: Stub out dma_{alloc,free,map}_pages() API

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

On Tue, Jun 17, 2025, at 06:48, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 03:48:50PM +0200, Arnd Bergmann wrote:
>> As far as I can tell, the difference here is that the
>> dma_alloc_coherent()/dma_free_coherent() calls all get stubbed
>> out, so the 827 drivers using those can all build cleanly on
>> mk68knommu, shnommu and UML, while dma_alloc_noncoherent()/
>> dma_free_noncoherent() are only used on 15 files that are all
>> guarded by some other Kconfig dependency at the moment and won't
>> build on the those platforms.
>
> Yes, dma_alloc_coherent is from a time where stubbing out was
> still very common.
>
>> I agree that it would be best to treat the coherent/noncoherent
>> cases the same, and I also think the existing stubs are a bit
>> silly, but just removing them would likely require fixing
>> hundreds of drivers with added Kconfig or IS_ENABLED() checks.
>
> I doubt it's that many, as most drivers and even subsystems simply
> depend on DMA.  There's probably at most a few dozen drivers
> supporting DMA but not requiring it.

I checked again, and the actual number is 263 modules for a j2
allmodconfig with the DMA stubs removed, see
https://pastebin.com/raw/4PFcEe04

This is helped a lot by PCI being unavailable on all four
targets without DMA. If I force-enable PCI, I see 610 modules
in allmodconfig that link to one of the dma-mapping helper
functions but are missing a dependency on CONFIG_HAS_DMA.

>> Maybe we can actually remove CONFIG_NO_DMA/CONFIG_HAS_DMA
>> entirely and remove all the checks for CONFIG_HAS_DMA? 
>> My guess is that this would only lead to a small code size
>> increase on the affected targets, but since they are not
>> actually trying to do DMA, and they all have a very limited
>> set of drivers they actually use, it won't break existing
>> code.
>
> Except for uml, the CONFIG_NO_DMA configs are usually very resource
> constraint, so I don't think that's a good idea.

The J2 Turtleboard has 256MB of RAM, which is not too
constrained either.

Between SH72xx/SH76xx, SUN3 and M68328, I believe the
supported machines are all limited to between 1MB and 32MB in
the maximum configuration, which is obviously extremely
tight. On the other hand, I really don't think anyone cares
any more: all three platforms are between 25 and 40 years
old, kernel support is very minimal and nobody has really
spent time improving them in at least 15 years. It also
appears that all three do support DMA in some form, so if
anyone was serious about using them, they would probably
want to use the dma-mapping interface for it as well,
like we do for similarly constrained nommu platforms
(coldfire, cortex-m3, xtensa)

      Arnd