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

[Christoph Hellwig <hch@lst.de>]

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.

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