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.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506160036.t9VDxF6p-lkp@intel.com/
Signed-off-by: James Clark <james.clark@linaro.org>
---
 include/linux/dma-mapping.h | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 55c03e5fe8cb..766f28a0e11f 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -161,6 +161,12 @@ void *dma_vmap_noncontiguous(struct device *dev, size_t size,
 void dma_vunmap_noncontiguous(struct device *dev, void *vaddr);
 int dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
 		size_t size, struct sg_table *sgt);
+struct page *dma_alloc_pages(struct device *dev, size_t size,
+		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp);
+void dma_free_pages(struct device *dev, size_t size, struct page *page,
+		dma_addr_t dma_handle, enum dma_data_direction dir);
+int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
+		size_t size, struct page *page);
 #else /* CONFIG_HAS_DMA */
 static inline dma_addr_t dma_map_page_attrs(struct device *dev,
 		struct page *page, size_t offset, size_t size,
@@ -291,6 +297,21 @@ static inline int dma_mmap_noncontiguous(struct device *dev,
 {
 	return -EINVAL;
 }
+static inline struct page *dma_alloc_pages(struct device *dev, size_t size,
+		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
+{
+	return NULL;
+}
+static inline void dma_free_pages(struct device *dev, size_t size,
+		struct page *page, dma_addr_t dma_handle,
+		enum dma_data_direction dir)
+{
+}
+static inline int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
+				 size_t size, struct page *page)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_HAS_DMA */
 
 #ifdef CONFIG_IOMMU_DMA
@@ -438,13 +459,6 @@ static inline bool dma_need_unmap(struct device *dev)
 }
 #endif /* !CONFIG_HAS_DMA || !CONFIG_DMA_NEED_SYNC */
 
-struct page *dma_alloc_pages(struct device *dev, size_t size,
-		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp);
-void dma_free_pages(struct device *dev, size_t size, struct page *page,
-		dma_addr_t dma_handle, enum dma_data_direction dir);
-int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
-		size_t size, struct page *page);
-
 static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
 		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
 {
-- 
2.34.1

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.

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.

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.

On Mon, Jun 16, 2025 at 02:08:32PM +0200, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 01:06:00PM +0100, Mark Brown wrote:

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

Right, so you just end up with essentially every driver that isn't
already tied to a platform that needs DMA needing to add the dependency
which nobody is going to notice without doing build testing for
randconfigs or similar non-useful configs - it's not a productive use of
time.

On Mon, Jun 16, 2025 at 01:11:49PM +0100, Mark Brown wrote:
> already tied to a platform that needs DMA needing to add the dependency
> which nobody is going to notice without doing build testing for
> randconfigs or similar non-useful configs - it's not a productive use of
> time.

Stop your unproductive whining and just fix your dependencies.

On 16/06/2025 1:14 pm, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 01:11:49PM +0100, Mark Brown wrote:
>> already tied to a platform that needs DMA needing to add the dependency
>> which nobody is going to notice without doing build testing for
>> randconfigs or similar non-useful configs - it's not a productive use of
>> time.
> 
> Stop your unproductive whining and just fix your dependencies.

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.

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.

Thanks
James

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?

On 16/06/2025 2:13 pm, Christoph Hellwig wrote:
> 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?
> 

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.

On 16/06/2025 2:14 pm, James Clark wrote:
> 
> 
> On 16/06/2025 2:13 pm, Christoph Hellwig wrote:
>> 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?
>>
> 
> 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

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.

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.

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

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.

On Tue, Jun 17, 2025, at 06:48, Christoph Hellwig wrote:
> 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.

I checked again, and the actual number is 263 modules for a j2
allmodconfig with the DMA stubs removed, see
https://pastebin.com/raw/4PFcEe04

This is helped a lot by PCI being unavailable on all four
targets without DMA. If I force-enable PCI, I see 610 modules
in allmodconfig that link to one of the dma-mapping helper
functions but are missing a dependency on CONFIG_HAS_DMA.

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

The J2 Turtleboard has 256MB of RAM, which is not too
constrained either.

Between SH72xx/SH76xx, SUN3 and M68328, I believe the
supported machines are all limited to between 1MB and 32MB in
the maximum configuration, which is obviously extremely
tight. On the other hand, I really don't think anyone cares
any more: all three platforms are between 25 and 40 years
old, kernel support is very minimal and nobody has really
spent time improving them in at least 15 years. It also
appears that all three do support DMA in some form, so if
anyone was serious about using them, they would probably
want to use the dma-mapping interface for it as well,
like we do for similarly constrained nommu platforms
(coldfire, cortex-m3, xtensa)

      Arnd

On Tue, Jun 17, 2025, at 09:53, Arnd Bergmann wrote:

> Between SH72xx/SH76xx, SUN3 and M68328, I believe the
> supported machines are all limited to between 1MB and 32MB in
> the maximum configuration, which is obviously extremely
> tight.

I checked the exact numbers we're talking about here: enabling
CONFIG_HAS_DMA on rsk7269_defconfig adds 10KB of extra vmlinux
size, which doesn't seem too bad:

   text	   data	    bss	    dec	    hex	filename
3295084	1111396	 112264	4518744	 44f358	vmlinux-before
3302836	1113652	 112264	4528752	 451a70	vmlinux-after

      Arnd

On Tue, Jun 17, 2025 at 10:26:51AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 17, 2025, at 09:53, Arnd Bergmann wrote:
> 
> > Between SH72xx/SH76xx, SUN3 and M68328, I believe the
> > supported machines are all limited to between 1MB and 32MB in
> > the maximum configuration, which is obviously extremely
> > tight.
> 
> I checked the exact numbers we're talking about here: enabling
> CONFIG_HAS_DMA on rsk7269_defconfig adds 10KB of extra vmlinux
> size, which doesn't seem too bad:
> 
>    text	   data	    bss	    dec	    hex	filename
> 3295084	1111396	 112264	4518744	 44f358	vmlinux-before
> 3302836	1113652	 112264	4528752	 451a70	vmlinux-after

Long ago I ran some numbers for an ancient PPC system:

https://lore.kernel.org/all/20121119214922.GA5636@obsidianresearch.com/

The base smallest kernel was growing .text and a stripped down initrd
at a rate of 1MB evey 6 years.

Somehow I doubt that system (with 16MB ram I think it was) would even
fit a v6.x kernel. v3.6 was already challenging.

Even back then Greg was incredulous that an embedded system would run
a 6 year newer kernel. Here we are contemplating a 20 year newer
kernel?

I think you have the right direction, we just removed !SMP support,
removing !DMA also seems logical to me.

Jason

On Mon, Jun 16, 2025, at 15:48, Arnd Bergmann wrote:
> On Mon, Jun 16, 2025, at 15:23, James Clark wrote:
>> On 16/06/2025 2:19 pm, Christoph Hellwig wrote:
>
> 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.

I tried removing the stubs on sh/j2 allmodconfig and found this:

ERROR: modpost: "dma_unmap_page_attrs" [drivers/bus/mhi/host/mhi.ko] undefined!
ERROR: modpost: "dma_map_page_attrs" [drivers/bus/mhi/host/mhi.ko] undefined!
ERROR: modpost: "dma_alloc_attrs" [drivers/bus/mhi/host/mhi.ko] undefined!
ERROR: modpost: "dma_free_attrs" [drivers/bus/mhi/host/mhi.ko] undefined!
ERROR: modpost: "dma_unmap_page_attrs" [drivers/soc/mediatek/mtk-cmdq-helper.ko] undefined!
ERROR: modpost: "dma_map_page_attrs" [drivers/soc/mediatek/mtk-cmdq-helper.ko] undefined!
ERROR: modpost: "dma_unmap_page_attrs" [drivers/soc/qcom/qcom-geni-se.ko] undefined!
ERROR: modpost: "dma_map_page_attrs" [drivers/soc/qcom/qcom-geni-se.ko] undefined!
ERROR: modpost: "dma_set_coherent_mask" [drivers/soc/ti/pruss.ko] undefined!
ERROR: modpost: "dma_unmap_page_attrs" [drivers/virtio/virtio_ring.ko] undefined!
WARNING: modpost: suppressed 733 unresolved symbol warnings because there were too many)

Enabling HAS_DMA unconditionally all all the platforms builds:

--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -64,7 +64,6 @@ config SUPERH
        select LOCK_MM_AND_FIND_VMA
        select MODULES_USE_ELF_RELA
        select NEED_SG_DMA_LENGTH
-       select NO_DMA if !MMU && !DMA_COHERENT
        select NO_GENERIC_PCI_IOPORT_MAP if PCI
        select OLD_SIGACTION
        select OLD_SIGSUSPEND
@@ -134,7 +133,7 @@ config SWAP_IO_SPACE
        bool
 
 config DMA_COHERENT
-       bool
+       def_bool !MMU
 
 config DMA_NONCOHERENT
        def_bool !NO_DMA && !DMA_COHERENT
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -22,7 +22,6 @@ config UML
        select HAVE_DEBUG_KMEMLEAK
        select HAVE_DEBUG_BUGVERBOSE
        select HAVE_PAGE_SIZE_4KB
-       select NO_DMA if !UML_DMA_EMULATION
        select OF_EARLY_FLATTREE if OF
        select GENERIC_IRQ_SHOW
        select GENERIC_CPU_DEVICES
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -37,7 +37,6 @@ config M68K
        select MMU_GATHER_NO_RANGE if MMU
        select MODULES_USE_ELF_REL
        select MODULES_USE_ELF_RELA
-       select NO_DMA if !MMU && !COLDFIRE
        select OLD_SIGACTION
        select OLD_SIGSUSPEND3
        select UACCESS_MEMCPY if !MMU
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index c9a7e602d8a4..a1123e2fecdf 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -38,7 +38,6 @@ config SUN3
        depends on MMU
        select HAVE_ARCH_PFN_VALID
        select LEGACY_TIMER_TICK
-       select NO_DMA
        select M68020
        help
          This option enables support for the Sun 3 series of workstations
@@ -558,4 +557,4 @@ config COLDFIRE_COHERENT_DMA
 config M68K_NONCOHERENT_DMA
        bool
        default y
-       depends on HAS_DMA && !COLDFIRE_COHERENT_DMA
+       depends on HAS_DMA && !COLDFIRE_COHERENT_DMA && !SUN3
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -8,7 +8,7 @@
 #include <linux/kernel.h>
 #include <asm/cacheflush.h>
 
-#ifndef CONFIG_COLDFIRE
+#if !defined(CONFIG_COLDFIRE) && !defined(CONFIG_SUN3)
 void arch_dma_prep_coherent(struct page *page, size_t size)
 {
        cache_push(page_to_phys(page), size);

On Mon, Jun 16, 2025 at 02:14:44PM +0200, Christoph Hellwig wrote:
> On Mon, Jun 16, 2025 at 01:11:49PM +0100, Mark Brown wrote:
> > already tied to a platform that needs DMA needing to add the dependency
> > which nobody is going to notice without doing build testing for
> > randconfigs or similar non-useful configs - it's not a productive use of
> > time.

> Stop your unproductive whining and just fix your dependencies.

That is not a constructive way to talk to people, especially not when
misdirected.

On Mon, Jun 16, 2025 at 02:05:22PM +0100, Mark Brown wrote:
> On Mon, Jun 16, 2025 at 02:14:44PM +0200, Christoph Hellwig wrote:
> > On Mon, Jun 16, 2025 at 01:11:49PM +0100, Mark Brown wrote:
> > > already tied to a platform that needs DMA needing to add the dependency
> > > which nobody is going to notice without doing build testing for
> > > randconfigs or similar non-useful configs - it's not a productive use of
> > > time.
> 
> > Stop your unproductive whining and just fix your dependencies.
> 
> That is not a constructive way to talk to people, especially not when
> misdirected.

In case you didn't notice, I found your answer extremely unconstrutive
if not actively malicious to start with.

On Mon, Jun 16, 2025, at 13:17, 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.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202506160036.t9VDxF6p-lkp@intel.com/
> Signed-off-by: James Clark <james.clark@linaro.org>

Looks good to me

Acked-by: Arnd Bergmann <arnd@arndb.de>

It may be worth adding here that HAS_DMA is set on almost
all configurations, this only showed up as an error in
a randconfig build for m68k/dragonball, which is barely
supported at all.

The other two architectures without DMA support are sh-nommu
and uml.

     Arnd

On 16/06/2025 12:17 pm, 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.
> 

So the commit message makes it seem like this fixes an existing issue 
and it would need a fixes: tag. But I didn't add one because it seems 
like it would only hit new users like in the linked patchset. It might 
be better to add a tag but it was changed 5 years ago and nobody hit it 
until now so I'm not sure.

> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202506160036.t9VDxF6p-lkp@intel.com/
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
>   include/linux/dma-mapping.h | 28 +++++++++++++++++++++-------
>   1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 55c03e5fe8cb..766f28a0e11f 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -161,6 +161,12 @@ void *dma_vmap_noncontiguous(struct device *dev, size_t size,
>   void dma_vunmap_noncontiguous(struct device *dev, void *vaddr);
>   int dma_mmap_noncontiguous(struct device *dev, struct vm_area_struct *vma,
>   		size_t size, struct sg_table *sgt);
> +struct page *dma_alloc_pages(struct device *dev, size_t size,
> +		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp);
> +void dma_free_pages(struct device *dev, size_t size, struct page *page,
> +		dma_addr_t dma_handle, enum dma_data_direction dir);
> +int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
> +		size_t size, struct page *page);
>   #else /* CONFIG_HAS_DMA */
>   static inline dma_addr_t dma_map_page_attrs(struct device *dev,
>   		struct page *page, size_t offset, size_t size,
> @@ -291,6 +297,21 @@ static inline int dma_mmap_noncontiguous(struct device *dev,
>   {
>   	return -EINVAL;
>   }
> +static inline struct page *dma_alloc_pages(struct device *dev, size_t size,
> +		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
> +{
> +	return NULL;
> +}
> +static inline void dma_free_pages(struct device *dev, size_t size,
> +		struct page *page, dma_addr_t dma_handle,
> +		enum dma_data_direction dir)
> +{
> +}
> +static inline int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
> +				 size_t size, struct page *page)
> +{
> +	return -EINVAL;
> +}
>   #endif /* CONFIG_HAS_DMA */
>   
>   #ifdef CONFIG_IOMMU_DMA
> @@ -438,13 +459,6 @@ static inline bool dma_need_unmap(struct device *dev)
>   }
>   #endif /* !CONFIG_HAS_DMA || !CONFIG_DMA_NEED_SYNC */
>   
> -struct page *dma_alloc_pages(struct device *dev, size_t size,
> -		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp);
> -void dma_free_pages(struct device *dev, size_t size, struct page *page,
> -		dma_addr_t dma_handle, enum dma_data_direction dir);
> -int dma_mmap_pages(struct device *dev, struct vm_area_struct *vma,
> -		size_t size, struct page *page);
> -
>   static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
>   		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
>   {