On Thu, Jan 22, 2026 at 05:10:03PM +0100, Thierry Reding wrote: > From: Thierry Reding <[email protected]> > > 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 <[email protected]>
AFAIU, this won't create a new cma heap when registering. This goes against the recent work we did to create one for every cma region. I guess, since you have a driver that would explicitly handle that region, we should create some kind of opt-out mechanism, but by default, we should still create such a heap. That being said, it's not clear to me why the heap driver uses CMA in the first place. Maxime
signature.asc
Description: PGP signature
