[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f723d490-c228-42d5-9f9f-158df54a092d@linaro.org>
Date: Mon, 16 Jun 2025 14:23:37 +0100
From: James Clark <james.clark@...aro.org>
To: Christoph Hellwig <hch@....de>
Cc: Mark Brown <broonie@...nel.org>, olteanv@...il.com,
oe-kbuild-all@...ts.linux.dev, arnd@...db.de, larisa.grigore@....com,
Frank.li@....com, linux-spi@...r.kernel.org, imx@...ts.linux.dev,
linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Robin Murphy <robin.murphy@....com>, iommu@...ts.linux.dev
Subject: Re: [PATCH] dma-mapping: Stub out dma_{alloc,free,map}_pages() API
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.
Powered by blists - more mailing lists