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

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

On Mon, Jun 16, 2025, at 15:23, James Clark wrote:
> On 16/06/2025 2:19 pm, Christoph Hellwig wrote:
>> On Mon, Jun 16, 2025 at 02:15:56PM +0100, James Clark wrote:
>>>> Yes it does, it has a few modes that don't require it. Presumably we can't
>>>> just add a depends into the kconfig for all devices because they might not
>>>> be using DMA.
>>>
>>> *for all the different variants of spi-fsl-dpsi devices I mean
>> 
>> This is drivers/spi/spi-fsl-dspi.c?
>> 
>> Yes, looks like it is one of those rare devices supporting a DMA and
>> non-DMA mode.  But everything seems nicely guarded off using
>> "dspi->devtype_data->trans_mode == DSPI_DMA_MODE" checks there.  So
>> wrap them into a little helper using IS_ENABLED(CONFIG_HAS_DMA) and
>> everything should be sorted out.
>
> Sure, I don't mind doing it.
>
> But separately to that, I still think making the stubs consistent would 
> save people a lot of time diagnosing build failures if they switch 
> existing code to any of those 3 functions. Principle of Least 
> Astonishment and all that.

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.

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.

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.

    Arnd