Re: [PATCH v2] dma/contiguous: Fix broken build

[Marek Szyprowski]

On 31.03.2026 09:40, Maxime Ripard wrote:
> On Mon, Mar 30, 2026 at 07:49:26PM +0200, Marek Szyprowski wrote:
>> On 30.03.2026 17:40, Maxime Ripard wrote:
>>> Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic
>>> around") didn't remove one last call to dma_heap_cma_register_heap()
>>> that it removed, thus breaking the build.
>>>
>>> That last call is in dma_contiguous_reserve(), to handle the
>>> registration of the default CMA region heap instance.
>>>
>>> The default CMA region instance is already somewhat handled by
>>> retrieving it through the dev_get_cma_area() call in the CMA heap
>>> driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give
>>> default CMA heap a fixed name"), we will create two heap instances for
>>> the CMA default region.
>>>
>>> The first one is always called "default_cma_region", and is the one
>>> handled by the call to dev_get_cma_area() mentioned earlier. The second
>>> one is the name it used to have prior to that last commit for backward
>>> compatibility.
>>>
>>> In the case where the default CMA region is defined in the DT, then that
>>> region is registered through rmem_cma_setup() and that region is added
>>> to the list of CMA regions to create a CMA heap instance for.
>>>
>>> In the case where the default CMA region is not defined in the DT
>>> though used to be the case covered by the now removed
>>> dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only
>>> remove the call to dma_heap_cma_register_heap(), then the legacy name of
>>> the CMA heap will not be registered anymore. We thus need to replace
>>> that call with a call to rmem_cma_insert_area() to make sure we queue
>>> this instance, if created, to create a heap instance.
>>>
>>> Once that call to dma_heap_cma_register_heap() replaced, we can also
>>> remove the now unused function definition, its now empty header, and all
>>> includes of this header.
>>>
>>> Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around")
>>> Reported-by: Mark Brown <broonie@xxxxxxxxxx>
>>> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@xxxxxxxxxxxx/
>>> Signed-off-by: Maxime Ripard <mripard@xxxxxxxxxx>
>>> ---
>>> Changes in v2:
>>> - Fix creation of the CMA heap instance with the legacy name when not
>>>   declared in the DT. 
>>> - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@xxxxxxxxxx
>>> ---
>>>  drivers/dma-buf/heaps/cma_heap.c  |  1 -
>>>  include/linux/dma-buf/heaps/cma.h | 16 ----------------
>>>  kernel/dma/contiguous.c           | 14 +++++++++++---
>>>  3 files changed, 11 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
>>> index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644
>>> --- a/drivers/dma-buf/heaps/cma_heap.c
>>> +++ b/drivers/dma-buf/heaps/cma_heap.c
>>> @@ -12,11 +12,10 @@
>>>  
>>>  #define pr_fmt(fmt) "cma_heap: " fmt
>>>  
>>>  #include <linux/cma.h>
>>>  #include <linux/dma-buf.h>
>>> -#include <linux/dma-buf/heaps/cma.h>
>>>  #include <linux/dma-heap.h>
>>>  #include <linux/dma-map-ops.h>
>>>  #include <linux/err.h>
>>>  #include <linux/highmem.h>
>>>  #include <linux/io.h>
>>> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h
>>> deleted file mode 100644
>>> index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000
>>> --- a/include/linux/dma-buf/heaps/cma.h
>>> +++ /dev/null
>>> @@ -1,16 +0,0 @@
>>> -/* SPDX-License-Identifier: GPL-2.0 */
>>> -#ifndef DMA_BUF_HEAP_CMA_H_
>>> -#define DMA_BUF_HEAP_CMA_H_
>>> -
>>> -struct cma;
>>> -
>>> -#ifdef CONFIG_DMABUF_HEAPS_CMA
>>> -int dma_heap_cma_register_heap(struct cma *cma);
>>> -#else
>>> -static inline int dma_heap_cma_register_heap(struct cma *cma)
>>> -{
>>> -	return 0;
>>> -}
>>> -#endif // CONFIG_DMABUF_HEAPS_CMA
>>> -
>>> -#endif // DMA_BUF_HEAP_CMA_H_
>>> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
>>> index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644
>>> --- a/kernel/dma/contiguous.c
>>> +++ b/kernel/dma/contiguous.c
>>> @@ -40,11 +40,10 @@
>>>  #include <asm/page.h>
>>>  
>>>  #include <linux/memblock.h>
>>>  #include <linux/err.h>
>>>  #include <linux/sizes.h>
>>> -#include <linux/dma-buf/heaps/cma.h>
>>>  #include <linux/dma-map-ops.h>
>>>  #include <linux/cma.h>
>>>  #include <linux/nospec.h>
>>>  
>>>  #ifdef CONFIG_CMA_SIZE_MBYTES
>>> @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void)
>>>  static inline void __init dma_numa_cma_reserve(void)
>>>  {
>>>  }
>>>  #endif
>>>  
>>> +#ifdef CONFIG_OF_RESERVED_MEM
>>> +static int rmem_cma_insert_area(struct cma *cma);
>>> +#else
>>> +static inline int rmem_cma_insert_area(struct cma *cma)
>>> +{
>>> +	return 0;
>>> +}
>>> +#endif
>>> +
>>>  /**
>>>   * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
>>>   * @limit: End address of the reserved memory (optional, 0 for any).
>>>   *
>>>   * This function reserves memory from early allocator. It should be
>>> @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
>>>  						  &dma_contiguous_default_area,
>>>  						  fixed);
>>>  		if (ret)
>>>  			return;
>>>  
>>> -		ret = dma_heap_cma_register_heap(dma_contiguous_default_area);
>>> +		ret = rmem_cma_insert_area(dma_contiguous_default_area);
>>>  		if (ret)
>>> -			pr_warn("Couldn't register default CMA heap.");
>>> +			pr_warn("Couldn't queue default CMA region for heap creation.");
>>>  	}
>>>  }
>>>  
>>>  void __weak
>>>  dma_contiguous_early_fixup(phys_addr_t base, unsigned long size)
>>>
>>> ---
>> Huh, this is still not the correct fix to restore the old behavior.
>> When !CONFIG_OF_RESERVED_MEM the default cma area should be still
>> registered as the default cma dma-buf heap.
> You're right, but it feels that it's a fundamental flaw in the original
> patch rather than a quick fix for the build now. Can you drop the
> patches you applied entirely? If so, I'll send a new version of that
> series.

I've dropped the whole branch already.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland