[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250616120832.GA24959@lst.de>
Date: Mon, 16 Jun 2025 14:08:32 +0200
From: Christoph Hellwig <hch@....de>
To: Mark Brown <broonie@...nel.org>
Cc: Christoph Hellwig <hch@....de>, James Clark <james.clark@...aro.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 01:06:00PM +0100, Mark Brown wrote:
> On Mon, Jun 16, 2025 at 01:29:27PM +0200, Christoph Hellwig wrote:
> > On Mon, Jun 16, 2025 at 12:17:49PM +0100, James Clark wrote:
>
> > > The implementations are in mapping.c which requires HAS_DMA so stub them
> > > out if not present. This is required for some drivers to pass randconfig
> > > builds.
>
> > No. Just add the proper IS_ENABLED checks in the callers. While these
> > kinds of stubs used to be popular they are really nasty in that the
> > calls unexpectedly just fail without the right depends.
>
> The issue with HAS_DMA is that essentially all platforms have and rely
> on DMA. This ends up just being painful noise from the buildbots when
> they do randconfigs rather than something useful.
In most case the driver really does depend on DMA to work, so just
depend on HAS_DMA. If it can work without DMA, you can use IS_ENABLED.
Powered by blists - more mailing lists