[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250616131346.GB29838@lst.de>
Date: Mon, 16 Jun 2025 15:13:46 +0200
From: Christoph Hellwig <hch@....de>
To: James Clark <james.clark@...aro.org>
Cc: Christoph Hellwig <hch@....de>, 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 Mon, Jun 16, 2025 at 02:10:40PM +0100, James Clark wrote:
> The change introduces consistency with the existing declarations in
> dma-mapping.h. Surely there is value in consistency and it doesn't do any
> harm to define new ones with stubs the same as the other ones. That way
> when you change an existing device that has DMA stuff to use a new part of
> the API you don't have to predict that it will behave differently to
> another part of the API.
Well, redoing the rest would definitively be nice, but so far no one
has signed up to that.
> I suppose it is possible to #ifdef out the DMA stuff in this driver, but
> IMO it would be quite messy, and I don't think randomly not stubbing out
> some functions is the right way to move towards fixing all the dependencies
> in all drivers. We should continue with the stubs for now and fix whole
> drivers one by one as a proper effort.
Does the driver even work at all without DMA support?
Powered by blists - more mailing lists