On Mon, Mar 30, 2026 at 10:59:48AM +0200, Marek Szyprowski wrote: > On 30.03.2026 10: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 if it's declared in > > the device tree. > > > > However, the default CMA region instance is already handled by > > retrieving it through dev_get_cma_area() in the CMA heap driver, so the > > call to dma_heap_cma_register_heap() wasn't actually needed. > > > > Let's remove this call, 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 > > Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ > > Signed-off-by: Maxime Ripard > > --- > > drivers/dma-buf/heaps/cma_heap.c | 1 - > > include/linux/dma-buf/heaps/cma.h | 16 ---------------- > > kernel/dma/contiguous.c | 5 ----- > > 3 files changed, 22 deletions(-) > > > > diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c > > index f8a3d87f3ccee9630383ba28502eb40b10671cc2..cc517ac68a0bec0788abcb338c03f530d169013b 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 > > #include > > -#include > > #include > > #include > > #include > > #include > > #include > > 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..9fe001c712339f8388d3f40cca3dfff3f707fcbf 100644 > > --- a/kernel/dma/contiguous.c > > +++ b/kernel/dma/contiguous.c > > @@ -40,11 +40,10 @@ > > #include > > > > #include > > #include > > #include > > -#include > > #include > > #include > > #include > > > > #ifdef CONFIG_CMA_SIZE_MBYTES > > @@ -270,14 +269,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit) > > selected_limit, > > &dma_contiguous_default_area, > > fixed); > > if (ret) > > return; > > - > > - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); > > - if (ret) > > - pr_warn("Couldn't register default CMA heap."); > > After this change no dma-buf heap for the default CMA area is created if it has  > not been specified in device-tree. This might be especially a problem for the > non-dt systems. I don't think that's the case? My understanding is that dma_contiguous_reserve() is called by the arch code, and will create that region only if it hasn't be set by the DT (that excerpt above is run only if !dma_contiguous_default_area). However, for the DT case, dma_contiguous_default_area will be set by rmem_cma_setup() a bit below if linux,cma-default is set in the DT. dma_contiguous_reserved() is called (on arm64 at least) through bootmem_init(), called as part of setup_arch(). rmem_cma_setup() is called through RESERVEDMEM_OF_DECLARE, so through __reserved_mem_init_node(), so, if we consider only the public functions, through: * fdt_scan_reserved_mem_reg_nodes(), called by unflatten_device_tree(), called right before bootmem_init() in setup_arch(); * or fdt_scan_reserved_mem() and then early_init_fdt_scan_reserved_mem(), called in arm64_memblock_init(), itself called in setup_arch() earlier than both unflatten_device_tree(), and bootmem_init(). Thus, the DT case will run first and set dma_contiguous_default_area if relevant on that platform, and if it's not set, the non-DT case will set it up. Either way, dma_contiguous_default_area will be set. The CMA heap runs much later using a regular module_init. It will retrieve dma_contiguous_default_area through dev_get_cma_area(), and will create a heap instance for the default area. Am I misunderstanding something? Maxime