On Fri, Aug 07, 2026 at 06:16:06PM +0200, David Hildenbrand (Arm) wrote:
> On 8/7/26 17:54, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > There is no technical reason why there should be a limited number of CMA
> > regions, so extract some code into helpers and use them to create extra
> > functions (cma_create() and cma_free()) that allow creating and freeing,
> > respectively, CMA regions dynamically at runtime.
> > 
> > The static array of CMA areas cannot be replaced by dynamically created
> > areas because for many of them, allocation must not fail and some cases
> > may need to initialize them before the slab allocator is even available.
> > To account for this, keep these "early" areas in a separate list and
> > track the dynamic areas in a separate list.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> 
> Sorry that I didn't get to reply earlier to
> 
> 	https://lore.kernel.org/all/anS0nxAwCXGWZRl9@orome/
> 
> But I am still not convinced why we shouldn't just have a single array that
> grows dynamically.
> 
> "
> After replying to T.J. I think this static array is actually a nice
> feature in a way. It allows us to more easily make a distinction between
> the regular CMA regions created from reserved-memory regions that
> represent classic carveouts, and the more versatile CMA areas that could
> be used for any purpose.
> 
> Telling the two types apart could obviously also be solved using some
> kind of flag stored with the CMA area, but at this point I don't really
> see a reason why the two lists would need to be unified.
> "
> 
> Really, cma_for_each_early_area() + cma_for_each_area() is just nasty.
> 
> I'd strongly vote to unify unless there is a very good reason to do it
> separately.

Marek had an interesting suggestion to extend CMA with fixed address or
range allocations, in which case we would only need a single CMA area.
If that works and is acceptable, there's not much need any longer for
cma_create()/cma_free().

Thierry