[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99dc91c9-59fd-47c5-b1d9-157bda86ad59@samsung.com>
Date: Thu, 18 Dec 2025 10:55:38 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Rob Herring <robh@...nel.org>, Oreoluwa Babatunde
<oreoluwa.babatunde@....qualcomm.com>
Cc: ye.li@....nxp.com, kernel@....qualcomm.com, saravanak@...gle.com,
akpm@...ux-foundation.org, david@...hat.com, lorenzo.stoakes@...cle.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com,
mhocko@...e.com, robin.murphy@....com, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, iommu@...ts.linux.dev,
quic_c_gdjako@...cinc.com
Subject: Re: [PATCH] of: reserved_mem: Allow reserved_mem framework detect
"cma=" kernel param
On 10.12.2025 15:07, Rob Herring wrote:
> On Tue, Dec 9, 2025 at 6:20 PM Oreoluwa Babatunde
> <oreoluwa.babatunde@....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()").
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/
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?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists