Re: [PATCH] of: reserved_mem: Allow reserved_mem framework detect "cma=" kernel param

[Rob Herring <robh@kernel.org>]

On Thu, Dec 18, 2025 at 3:55 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 10.12.2025 15:07, Rob Herring wrote:
> > On Tue, Dec 9, 2025 at 6:20 PM Oreoluwa Babatunde
> > <oreoluwa.babatunde@oss.qualcomm.com> wrote:
> >> When initializing the default cma region, the "cma=" kernel parameter
> >> takes priority over a DT defined linux,cma-default region. Hence, give
> >> the reserved_mem framework the ability to detect this so that the DT
> >> defined cma region can skip initialization accordingly.
> > Please explain here why this is a new problem. Presumably the
> > RESERVEDMEM_OF_DECLARE hook after commit xxxx gets called before the
> > early_param hook. And why is it now earlier?
> >
> > I don't really like the state/ordering having to be worried about in 2 places.
>
> I also don't like this spaghetti, but it originates from
> commit 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
> memory regions are processed") and the first fixup for it: 2c223f7239f3
> ("of: reserved_mem: Restructure call site for
> dma_contiguous_early_fixup()").

Honestly, this code wasn't great before. Every time it is touched it
breaks someone.

> It looks that it is really hard to make reserved memory
> initialization fully dynamic assuming that the cma related fixups have
> to be known before populating kernel memory pages tables. I also advised
> in
> https://lore.kernel.org/all/be70bdc4-bddd-4afe-8574-7e0889fd381c@samsung.com/
> to simply increase the size of the static table to make it large enough for the sane use cases, but
> it turned out that this approach was already discussed and rejected:
> https://lore.kernel.org/all/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/

I guess the question is what's a sane limit? After 128, are we going
to accept 256? I really suspect we are just enabling some further
abuse of /reserved-memory downstream. For example, I could imagine
there's micromanaging the location of media/graphics buffers so they
end up in specific DRAM banks to optimize accesses. No one ever wants
to detail why they want/need more regions.

> Maybe it would make sense to revert the mentioned changes and get back
> to such simple approach - to make the size of the static table
> configurable in the Kconfig?

I'd rather not resort to a kconfig option.

We could go back to processing all the regions at the beginning
(growing the static size), and then just shrinking allocation. Or
maybe it could just be freed entirely. I don't think we really need to
keep the state around forever.

Rob