On Mon, Mar 30, 2026 at 02:51:34PM +0200, Marek Szyprowski wrote: > On 30.03.2026 13:41, Maxime Ripard wrote: > > 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? > > The default CMA area is also optional for DT platforms.  > > If DT doesn't provide such, it will be created based on the kernel > cmdline cma= parameter or the default configuration defined in the > kernel .config (this is also true for the non-dt platforms). I know > that for most Android GKI systems the default CMA area will be defined > in DT, but I see no reason to disable dma-buf heap support for the > default CMA area if it has been instantiated from kernel cmdline or > .config. I think I see what you mean now, thanks! Sending a v2. Maxime