[RFC] MAX_RESERVED_REGIONS hard-coded value

[RFC] MAX_RESERVED_REGIONS hard-coded value

[Daniele Alessandrelli]

Hi,

I'm using a Device Tree with more then 32 reserved memory regions and
I'm seeing the following error while booting the Kernel:
[    0.000000] OF: reserved mem: not enough space all defined regions.

My understanding is that this is due to the hard-coded value of
MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c

Googling around, I found this old discussion [1] in which Miles
suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
poses some implementation issues [2]. At that point the discussion
seemed to have stopped.

Is there any chance for the patch proposed by Miles to be reconsidered?

Regards,
Daniele

[1] https://lkml.org/lkml/2018/11/21/423
[2] https://lkml.org/lkml/2018/11/28/275

Re: [RFC] MAX_RESERVED_REGIONS hard-coded value

[Rob Herring]

On Mon, Jan 6, 2020 at 12:05 PM Daniele Alessandrelli
<daniele.alessandrelli@gmail.com> wrote:
>
> Hi,
>
> I'm using a Device Tree with more then 32 reserved memory regions and
> I'm seeing the following error while booting the Kernel:
> [    0.000000] OF: reserved mem: not enough space all defined regions.

How many do you have? Is that DT available somewhere?

> My understanding is that this is due to the hard-coded value of
> MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c
>
> Googling around, I found this old discussion [1] in which Miles
> suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
> configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
> that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
> later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
> poses some implementation issues [2]. At that point the discussion
> seemed to have stopped.

Not sure what the problem was as there's no code, but I'd guess the
array alloc and populating have to be done later (perhaps in
unflattening).

> Is there any chance for the patch proposed by Miles to be reconsidered?

A kconfig option would still be my 3rd choice after dynamically
allocating the array or just growing the fixed array size.

Rob

Re: [RFC] MAX_RESERVED_REGIONS hard-coded value

[Miles Chen]

Hi,

On Tue, 2020-01-07 at 15:13 -0600, Rob Herring wrote:
> On Mon, Jan 6, 2020 at 12:05 PM Daniele Alessandrelli
> <daniele.alessandrelli@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm using a Device Tree with more then 32 reserved memory regions and
> > I'm seeing the following error while booting the Kernel:
> > [    0.000000] OF: reserved mem: not enough space all defined regions.
> 
> How many do you have? Is that DT available somewhere?
> 
> > My understanding is that this is due to the hard-coded value of
> > MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c
> >
> > Googling around, I found this old discussion [1] in which Miles
> > suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
> > configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
> > that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
> > later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
> > poses some implementation issues [2]. At that point the discussion
> > seemed to have stopped.
> 
> Not sure what the problem was as there's no code, but I'd guess the
> array alloc and populating have to be done later (perhaps in
> unflattening).

I missed my draft patch.

From what I recall, the problem I had that time is that
early_init_fdt_scan_reserved_mem() is called before paging_init(). So I
cannot allocate accessible memory in early_init_fdt_scan_reserved_mem().

For example: aarch64 setup_arch()
setup_arch()
{
    memblock_init(); /* early_init_fdt_scan_reserved_mem() is called */
    paging_init(); /* map memory */
}

> 
> > Is there any chance for the patch proposed by Miles to be reconsidered?
> 
> A kconfig option would still be my 3rd choice after dynamically
> allocating the array or just growing the fixed array size.

Not sure how many of reserve memory regions Daniele has. In my case,
we grow the MAX_RESERVED_REGIONS to 64 (3x used) and we are still trying
to suppress the amount of reserved memory to fit
MAX_RESERVED_REGIONS=32.



thanks,
Miles
> 
> Rob

Re: [RFC] MAX_RESERVED_REGIONS hard-coded value

[Daniele Alessandrelli]

Hi Rob, Miles,

Thank you both for your replies.

On Wed, Jan 8, 2020 at 6:45 AM Miles Chen <miles.chen@mediatek.com> wrote:
>
> Hi,
>
> On Tue, 2020-01-07 at 15:13 -0600, Rob Herring wrote:
> > On Mon, Jan 6, 2020 at 12:05 PM Daniele Alessandrelli
> > <daniele.alessandrelli@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm using a Device Tree with more then 32 reserved memory regions and
> > > I'm seeing the following error while booting the Kernel:
> > > [    0.000000] OF: reserved mem: not enough space all defined regions.
> >
> > How many do you have? Is that DT available somewhere?

Unfortunately, the DT is not publicly available yet. Anyway, I
currently have 41 reserved memory regions.

> >
> > > My understanding is that this is due to the hard-coded value of
> > > MAX_RESERVED_REGIONS in drivers/of/of_reserved_mem.c
> > >
> > > Googling around, I found this old discussion [1] in which Miles
> > > suggests to add a CONFIG_MAX_OF_RESERVED_REGIONS kconfig option to
> > > configure MAX_RESERVED_REGIONS. Rob replied to Miles' email saying
> > > that he would prefer MAX_RESERVED_REGIONS to be dynamic. However,
> > > later in the thread, it looks like making MAX_RESERVED_REGIONS dynamic
> > > poses some implementation issues [2]. At that point the discussion
> > > seemed to have stopped.
> >
> > Not sure what the problem was as there's no code, but I'd guess the
> > array alloc and populating have to be done later (perhaps in
> > unflattening).
>
> I missed my draft patch.
>
> From what I recall, the problem I had that time is that
> early_init_fdt_scan_reserved_mem() is called before paging_init(). So I
> cannot allocate accessible memory in early_init_fdt_scan_reserved_mem().
>
> For example: aarch64 setup_arch()
> setup_arch()
> {
>     memblock_init(); /* early_init_fdt_scan_reserved_mem() is called */
>     paging_init(); /* map memory */
> }
>
> >
> > > Is there any chance for the patch proposed by Miles to be reconsidered?
> >
> > A kconfig option would still be my 3rd choice after dynamically
> > allocating the array or just growing the fixed array size.

I'm happy with just growing the fixed array size, but just out of
curiosity, why do you prefer it to the kconfig option?

>
> Not sure how many of reserve memory regions Daniele has. In my case,
> we grow the MAX_RESERVED_REGIONS to 64 (3x used) and we are still trying
> to suppress the amount of reserved memory to fit
> MAX_RESERVED_REGIONS=32.

64 would be a safe value for my case as well.

We are also trying to reduce the amount of memory regions, but it's
unlikely we will manage to stay below 32 :/

Regards,
Daniele

>
>
>
> thanks,
> Miles
> >
> > Rob
>