drivers/of/of_reserved_mem.c | 16 ++++++++++++---- include/linux/dma-map-ops.h | 3 +++ kernel/dma/contiguous.c | 2 -- 3 files changed, 15 insertions(+), 6 deletions(-)
Restructure the call site for dma_contiguous_early_fixup() to
where the reserved_mem nodes are being parsed from the DT so that
dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
Tested-by: William Zhang <william.zhang@broadcom.com>
---
v4: Introduce static inline funtion for dma_contiguous_early_fixup() in
dma-map-ops.h to avoid compilation issues when CONFIG_DMA_CMA is not
defined. This allows us to drop the #ifdef check introduced in v3.
v3: Wrap the call to dma_contiguous_early_fixup() with a check for
CONFIG_DMA_CMA to fix compile error seen on x86. The __weak function
definition introduced in v2 was not sufficient to prevent the issue,
so remove that as well.
Also add Tested-by tag from William Zhang.
v2: Add a check for the "reusable" property to narrow things down to
only cma regions.
Also add __weak function definition for dma_contiguous_early_fixup()
to avoid compile errors on architectures that do not define the
function.
drivers/of/of_reserved_mem.c | 16 ++++++++++++----
include/linux/dma-map-ops.h | 3 +++
kernel/dma/contiguous.c | 2 --
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 77016c0cc296..7350b23cb734 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -25,6 +25,7 @@
#include <linux/memblock.h>
#include <linux/kmemleak.h>
#include <linux/cma.h>
+#include <linux/dma-map-ops.h>
#include "of_private.h"
@@ -175,13 +176,17 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
base = dt_mem_next_cell(dt_root_addr_cells, &prop);
size = dt_mem_next_cell(dt_root_size_cells, &prop);
- if (size &&
- early_init_dt_reserve_memory(base, size, nomap) == 0)
+ if (size && early_init_dt_reserve_memory(base, size, nomap) == 0) {
+ /* Architecture specific contiguous memory fixup. */
+ if (of_flat_dt_is_compatible(node, "shared-dma-pool") &&
+ of_get_flat_dt_prop(node, "reusable", NULL))
+ dma_contiguous_early_fixup(base, size);
pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %lu MiB\n",
uname, &base, (unsigned long)(size / SZ_1M));
- else
+ } else {
pr_err("Reserved memory: failed to reserve memory for node '%s': base %pa, size %lu MiB\n",
uname, &base, (unsigned long)(size / SZ_1M));
+ }
len -= t_len;
}
@@ -472,7 +477,10 @@ static int __init __reserved_mem_alloc_size(unsigned long node, const char *unam
uname, (unsigned long)(size / SZ_1M));
return -ENOMEM;
}
-
+ /* Architecture specific contiguous memory fixup. */
+ if (of_flat_dt_is_compatible(node, "shared-dma-pool") &&
+ of_get_flat_dt_prop(node, "reusable", NULL))
+ dma_contiguous_early_fixup(base, size);
/* Save region in the reserved_mem array */
fdt_reserved_mem_save_node(node, uname, base, size);
return 0;
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index f48e5fb88bd5..332b80c42b6f 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -153,6 +153,9 @@ static inline void dma_free_contiguous(struct device *dev, struct page *page,
{
__free_pages(page, get_order(size));
}
+static inline void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size)
+{
+}
#endif /* CONFIG_DMA_CMA*/
#ifdef CONFIG_DMA_DECLARE_COHERENT
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 67af8a55185d..d9b9dcba6ff7 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -483,8 +483,6 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
pr_err("Reserved memory: unable to setup CMA region\n");
return err;
}
- /* Architecture specific contiguous memory fixup. */
- dma_contiguous_early_fixup(rmem->base, rmem->size);
if (default_cma)
dma_contiguous_default_area = cma;
--
2.34.1On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
> Restructure the call site for dma_contiguous_early_fixup() to
> where the reserved_mem nodes are being parsed from the DT so that
> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>
> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
> Tested-by: William Zhang <william.zhang@broadcom.com>
Thanks, applied to dma-mapping-fixes branch.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>> Restructure the call site for dma_contiguous_early_fixup() to
>> where the reserved_mem nodes are being parsed from the DT so that
>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>
>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>> Tested-by: William Zhang <william.zhang@broadcom.com>
>
> Thanks, applied to dma-mapping-fixes branch.
>
> Best regards
Hi Oreoluwa,
We observed this patch causing kernel boot hang on iMX6 (armv7)
platforms if using "cma=" kernel parameter. It only happens when the
size assigned in
"cma=" parameter is smaller than cma default size in dts.
For example, we use "cma=96M" in command line and below reserved memory
node (160M) in dts.
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
linux,cma {
compatible = "shared-dma-pool";
reusable;
size = <0xa000000>;
linux,cma-default;
};
};
The root cause is this patch moving the dma_contiguous_early_fixup from
rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can skip the
cma reserved memory if command line has cma parameter. However, the
__reserved_mem_alloc_size won't do it. So this leads to have two cma
regions added to dma_mmu_remap, one from dts, the other from command
line. But the reserved memory of memblock that only records the cma from
command line is inconsistent with dma_mmu_remap.
The dma_contiguous_remap clears the MMU paging for the region of
dma_mmu_remap firstly, then create a new mapping by iotable_init. For
the cma from dts, this causes incorrect memory mapping cleared. Then any
allocation from memblock in iotable_init hitting to the area will meet
MMU mapping issue.
From commit, I don't understand what issue does this patch fix. Can you
look into the regression and provide a fix patch.
Best regards,
Ye Li
On 26.11.2025 02:37, Ye Li wrote:
> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>> Restructure the call site for dma_contiguous_early_fixup() to
>>> where the reserved_mem nodes are being parsed from the DT so that
>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>
>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>> memory regions are processed")
>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>
>> Thanks, applied to dma-mapping-fixes branch.
>>
>> Best regards
>
> Hi Oreoluwa,
>
> We observed this patch causing kernel boot hang on iMX6 (armv7)
> platforms if using "cma=" kernel parameter. It only happens when the
> size assigned in
> "cma=" parameter is smaller than cma default size in dts.
>
> For example, we use "cma=96M" in command line and below reserved
> memory node (160M) in dts.
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> linux,cma {
> compatible = "shared-dma-pool";
> reusable;
> size = <0xa000000>;
> linux,cma-default;
> };
> };
>
> The root cause is this patch moving the dma_contiguous_early_fixup
> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
> skip the cma reserved memory if command line has cma parameter.
> However, the __reserved_mem_alloc_size won't do it. So this leads to
> have two cma regions added to dma_mmu_remap, one from dts, the other
> from command line. But the reserved memory of memblock that only
> records the cma from command line is inconsistent with dma_mmu_remap.
> The dma_contiguous_remap clears the MMU paging for the region of
> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
> the cma from dts, this causes incorrect memory mapping cleared. Then
> any allocation from memblock in iotable_init hitting to the area will
> meet MMU mapping issue.
>
> From commit, I don't understand what issue does this patch fix. Can
> you look into the regression and provide a fix patch.
I confirm that there is an issue with CMA area initialized from "cma="
kernel parameter. The $subject patch in turn fixed the issue observed on
ARM 32bit machines with cma regions initizalized from dt static qnode
(area described by the 'reg' property) introduced earlied by the commit
8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory
regions are processed").
I will check how to fix this case too.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 11/28/2025 4:43 AM, Marek Szyprowski wrote:
> On 26.11.2025 02:37, Ye Li wrote:
>> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>>> Restructure the call site for dma_contiguous_early_fixup() to
>>>> where the reserved_mem nodes are being parsed from the DT so that
>>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>
>>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>>> memory regions are processed")
>>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>>
>>> Thanks, applied to dma-mapping-fixes branch.
>>>
>>> Best regards
>>
>> Hi Oreoluwa,
>>
>> We observed this patch causing kernel boot hang on iMX6 (armv7)
>> platforms if using "cma=" kernel parameter. It only happens when the
>> size assigned in
>> "cma=" parameter is smaller than cma default size in dts.
>>
>> For example, we use "cma=96M" in command line and below reserved
>> memory node (160M) in dts.
>>
>> reserved-memory {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>>
>> linux,cma {
>> compatible = "shared-dma-pool";
>> reusable;
>> size = <0xa000000>;
>> linux,cma-default;
>> };
>> };
>>
>> The root cause is this patch moving the dma_contiguous_early_fixup
>> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
>> skip the cma reserved memory if command line has cma parameter.
>> However, the __reserved_mem_alloc_size won't do it. So this leads to
>> have two cma regions added to dma_mmu_remap, one from dts, the other
>> from command line. But the reserved memory of memblock that only
>> records the cma from command line is inconsistent with dma_mmu_remap.
>> The dma_contiguous_remap clears the MMU paging for the region of
>> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
>> the cma from dts, this causes incorrect memory mapping cleared. Then
>> any allocation from memblock in iotable_init hitting to the area will
>> meet MMU mapping issue.
>>
Hi Ye Li,
Thanks for pointing this out. From what I see in the code, if "cma="
kernel parameter is being used to configure the default cma region, then we
should skip adding the DT defined region to dma_mmu_remap array.
I will work on a fix which does this and share here when it is done.
>> From commit, I don't understand what issue does this patch fix. Can
>> you look into the regression and provide a fix patch.
Please see below conversation for details on the original issue this patch fixes:
https://lore.kernel.org/all/5aa94f41-c689-443b-8665-c6913ff5ba8f@broadcom.com/
Thanks,
Oreoluwa
On 01.12.2025 07:31, Oreoluwa Babatunde wrote:
> On 11/28/2025 4:43 AM, Marek Szyprowski wrote:
>> On 26.11.2025 02:37, Ye Li wrote:
>>> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>>>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>>>> Restructure the call site for dma_contiguous_early_fixup() to
>>>>> where the reserved_mem nodes are being parsed from the DT so that
>>>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>>
>>>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>>>> memory regions are processed")
>>>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>>> Thanks, applied to dma-mapping-fixes branch.
>>>>
>>>> Best regards
>>> Hi Oreoluwa,
>>>
>>> We observed this patch causing kernel boot hang on iMX6 (armv7)
>>> platforms if using "cma=" kernel parameter. It only happens when the
>>> size assigned in
>>> "cma=" parameter is smaller than cma default size in dts.
>>>
>>> For example, we use "cma=96M" in command line and below reserved
>>> memory node (160M) in dts.
>>>
>>> reserved-memory {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>>
>>> linux,cma {
>>> compatible = "shared-dma-pool";
>>> reusable;
>>> size = <0xa000000>;
>>> linux,cma-default;
>>> };
>>> };
>>>
>>> The root cause is this patch moving the dma_contiguous_early_fixup
>>> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
>>> skip the cma reserved memory if command line has cma parameter.
>>> However, the __reserved_mem_alloc_size won't do it. So this leads to
>>> have two cma regions added to dma_mmu_remap, one from dts, the other
>>> from command line. But the reserved memory of memblock that only
>>> records the cma from command line is inconsistent with dma_mmu_remap.
>>> The dma_contiguous_remap clears the MMU paging for the region of
>>> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
>>> the cma from dts, this causes incorrect memory mapping cleared. Then
>>> any allocation from memblock in iotable_init hitting to the area will
>>> meet MMU mapping issue.
>>>
> Hi Ye Li,
>
> Thanks for pointing this out. From what I see in the code, if "cma="
> kernel parameter is being used to configure the default cma region, then we
> should skip adding the DT defined region to dma_mmu_remap array.
>
> I will work on a fix which does this and share here when it is done.
I wonder how to avoid adding more such checks to
drivers/of/of_reserved_mem.c and making this code even more tangled and
spaghetti-like... I've briefly scanned that code and it is already quite
hard to follow, especially after commits 8a6e02d0c00e ("of:
reserved_mem: Restructure how the reserved memory regions are
processed") and 2c223f7239f3 ("of: reserved_mem: Restructure call site
for dma_contiguous_early_fixup()")... I wonder how many reserved memory
regions are used on real machines? Maybe instead of complicating this
code even more it is enough to make this configurable via Kconfig and
restore pre-8a6e02d0c00e version?
>>> From commit, I don't understand what issue does this patch fix. Can
>>> you look into the regression and provide a fix patch.
> Please see below conversation for details on the original issue this patch fixes:
> https://lore.kernel.org/all/5aa94f41-c689-443b-8665-c6913ff5ba8f@broadcom.com/
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On 11/30/2025 11:51 PM, Marek Szyprowski wrote:
> On 01.12.2025 07:31, Oreoluwa Babatunde wrote:
>> On 11/28/2025 4:43 AM, Marek Szyprowski wrote:
>>> On 26.11.2025 02:37, Ye Li wrote:
>>>> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>>>>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>>>>> Restructure the call site for dma_contiguous_early_fixup() to
>>>>>> where the reserved_mem nodes are being parsed from the DT so that
>>>>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>>>
>>>>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>>>>> memory regions are processed")
>>>>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>>>> Thanks, applied to dma-mapping-fixes branch.
>>>>>
>>>>> Best regards
>>>> Hi Oreoluwa,
>>>>
>>>> We observed this patch causing kernel boot hang on iMX6 (armv7)
>>>> platforms if using "cma=" kernel parameter. It only happens when the
>>>> size assigned in
>>>> "cma=" parameter is smaller than cma default size in dts.
>>>>
>>>> For example, we use "cma=96M" in command line and below reserved
>>>> memory node (160M) in dts.
>>>>
>>>> reserved-memory {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> ranges;
>>>>
>>>> linux,cma {
>>>> compatible = "shared-dma-pool";
>>>> reusable;
>>>> size = <0xa000000>;
>>>> linux,cma-default;
>>>> };
>>>> };
>>>>
>>>> The root cause is this patch moving the dma_contiguous_early_fixup
>>>> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
>>>> skip the cma reserved memory if command line has cma parameter.
>>>> However, the __reserved_mem_alloc_size won't do it. So this leads to
>>>> have two cma regions added to dma_mmu_remap, one from dts, the other
>>>> from command line. But the reserved memory of memblock that only
>>>> records the cma from command line is inconsistent with dma_mmu_remap.
>>>> The dma_contiguous_remap clears the MMU paging for the region of
>>>> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
>>>> the cma from dts, this causes incorrect memory mapping cleared. Then
>>>> any allocation from memblock in iotable_init hitting to the area will
>>>> meet MMU mapping issue.
>>>>
>> Hi Ye Li,
>>
>> Thanks for pointing this out. From what I see in the code, if "cma="
>> kernel parameter is being used to configure the default cma region, then we
>> should skip adding the DT defined region to dma_mmu_remap array.
>>
>> I will work on a fix which does this and share here when it is done.
>
> I wonder how to avoid adding more such checks to
> drivers/of/of_reserved_mem.c and making this code even more tangled and
> spaghetti-like... I've briefly scanned that code and it is already quite
> hard to follow, especially after commits 8a6e02d0c00e ("of:
> reserved_mem: Restructure how the reserved memory regions are
> processed") and 2c223f7239f3 ("of: reserved_mem: Restructure call site
> for dma_contiguous_early_fixup()")... I wonder how many reserved memory
> regions are used on real machines? Maybe instead of complicating this
> code even more it is enough to make this configurable via Kconfig and
> restore pre-8a6e02d0c00e version?
Hi Marek,
There was a change which attempted a simpler approach of increasing the
size of the static array:
https://lore.kernel.org/all/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/
The comment from Rob at the time was to revive another thread which attempted
to dynamically allocate the reserved_mem array like we are doing now.
Dynamic allocation gives more flexibility because we only use the exact
amount of memory that is needed. This can save some memory if that ends
up being smaller than what is specified in MAX_RESERVED_REGIONS.
I do agree that adding another check in of_reserved_mem.c might not be the best
in terms of code complexity, so I'm exploring other options on how to keep things
simpler.
Regards,
Oreoluwa
On 12/1/2025 10:54 PM, Oreoluwa Babatunde wrote:
>
>
> On 11/30/2025 11:51 PM, Marek Szyprowski wrote:
>> On 01.12.2025 07:31, Oreoluwa Babatunde wrote:
>>> On 11/28/2025 4:43 AM, Marek Szyprowski wrote:
>>>> On 26.11.2025 02:37, Ye Li wrote:
>>>>> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>>>>>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>>>>>> Restructure the call site for dma_contiguous_early_fixup() to
>>>>>>> where the reserved_mem nodes are being parsed from the DT so that
>>>>>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>>>>
>>>>>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>>>>>> memory regions are processed")
>>>>>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>>>>> Thanks, applied to dma-mapping-fixes branch.
>>>>>>
>>>>>> Best regards
>>>>> Hi Oreoluwa,
>>>>>
>>>>> We observed this patch causing kernel boot hang on iMX6 (armv7)
>>>>> platforms if using "cma=" kernel parameter. It only happens when the
>>>>> size assigned in
>>>>> "cma=" parameter is smaller than cma default size in dts.
>>>>>
>>>>> For example, we use "cma=96M" in command line and below reserved
>>>>> memory node (160M) in dts.
>>>>>
>>>>> reserved-memory {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <1>;
>>>>> ranges;
>>>>>
>>>>> linux,cma {
>>>>> compatible = "shared-dma-pool";
>>>>> reusable;
>>>>> size = <0xa000000>;
>>>>> linux,cma-default;
>>>>> };
>>>>> };
>>>>>
>>>>> The root cause is this patch moving the dma_contiguous_early_fixup
>>>>> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
>>>>> skip the cma reserved memory if command line has cma parameter.
>>>>> However, the __reserved_mem_alloc_size won't do it. So this leads to
>>>>> have two cma regions added to dma_mmu_remap, one from dts, the other
>>>>> from command line. But the reserved memory of memblock that only
>>>>> records the cma from command line is inconsistent with dma_mmu_remap.
>>>>> The dma_contiguous_remap clears the MMU paging for the region of
>>>>> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
>>>>> the cma from dts, this causes incorrect memory mapping cleared. Then
>>>>> any allocation from memblock in iotable_init hitting to the area will
>>>>> meet MMU mapping issue.
>>>>>
>>> Hi Ye Li,
>>>
>>> Thanks for pointing this out. From what I see in the code, if "cma="
>>> kernel parameter is being used to configure the default cma region, then we
>>> should skip adding the DT defined region to dma_mmu_remap array.
>>>
>>> I will work on a fix which does this and share here when it is done.
>>
>> I wonder how to avoid adding more such checks to
>> drivers/of/of_reserved_mem.c and making this code even more tangled and
>> spaghetti-like... I've briefly scanned that code and it is already quite
>> hard to follow, especially after commits 8a6e02d0c00e ("of:
>> reserved_mem: Restructure how the reserved memory regions are
>> processed") and 2c223f7239f3 ("of: reserved_mem: Restructure call site
>> for dma_contiguous_early_fixup()")... I wonder how many reserved memory
>> regions are used on real machines? Maybe instead of complicating this
>> code even more it is enough to make this configurable via Kconfig and
>> restore pre-8a6e02d0c00e version?
>
> Hi Marek,
>
> There was a change which attempted a simpler approach of increasing the
> size of the static array:
> https://lore.kernel.org/all/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/
>
> The comment from Rob at the time was to revive another thread which attempted
> to dynamically allocate the reserved_mem array like we are doing now.
> Dynamic allocation gives more flexibility because we only use the exact
> amount of memory that is needed. This can save some memory if that ends
> up being smaller than what is specified in MAX_RESERVED_REGIONS.
>
> I do agree that adding another check in of_reserved_mem.c might not be the best
> in terms of code complexity, so I'm exploring other options on how to keep things
> simpler.
>
> Regards,
> Oreoluwa
>
Hi all,
Apologies for the delay in pushing a fix for this.
I've uploaded a fix now:
https://lore.kernel.org/all/20251210002027.1171519-1-oreoluwa.babatunde@oss.qualcomm.com/
I ended up adding some checks in the reserved_mem code to skip initializing
the default cma region when the "cma=" kernel param is being used. This seems
to be the most straight forward way of fixing this issue.
Also, this way makes sense because it allows the reserved_mem code to skip the
default cma node and not add it in the reserved_mem array since it will not be
used as a cma region eventually.
Please help me review and give some feedback.
Thanks,
Oreoluwa
© 2016 - 2026 Red Hat, Inc.