From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fdt_support: Use VLA instead of MEMORY_BANKS_MAX
Date: Mon, 13 Aug 2018 10:52:05 -0400 [thread overview]
Message-ID: <20180813145205.GZ29229@bill-the-cat> (raw)
In-Reply-To: <CALeDE9PsmVJrO6g03RrjkQBJycreN7H84STh9fd9a0rZre0Ncw@mail.gmail.com>
On Mon, Aug 13, 2018 at 08:20:03AM +0100, Peter Robinson wrote:
> On Sun, Aug 12, 2018 at 9:37 PM, Ramon Fried <ramon.fried@gmail.com> wrote:
> > From: Ramon Fried <ramon.fried@intel.com>
> >
> > Instead of relaying on user to configure MEMORY_BANKS_MAX
> > correctly, use VLA (variable length array) to accommodate the
> > required banks.
>
> With the kernel actively removing VLAs [1] does it make sense for us
> to use them?
Agreed.
Also, why is the answer NOT to go back to the way things were with
5e5745465c94 and increase CONFIG_NR_DRAM_BANKS when needed? It seems
like the problem may be platforms setting this to 1 when really it
should be higher _even_if_ the memory space in question is contiguous.
Yes, you've always been able to say we have 1 bank of N physical chips
and it's been OK, but now I guess we're finally hitting the point where
that doesn't work.
>
> [1] https://lwn.net/Articles/749064/
>
> > Fixes: 2a1f4f1758b5 ("Revert "fdt_support: Use CONFIG_NR_DRAM_BANKS if
> > defined"")
> >
> > Signed-off-by: Ramon Fried <ramon.fried@intel.com>
> > ---
> > common/fdt_support.c | 9 ++-------
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > index 34d2bd5..e898236 100644
> > --- a/common/fdt_support.c
> > +++ b/common/fdt_support.c
> > @@ -409,19 +409,14 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64 *address, u64 *size,
> > return p - (char *)buf;
> > }
> >
> > -#define MEMORY_BANKS_MAX 4
> > int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
> > {
> > int err, nodeoffset;
> > int len, i;
> > - u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
> > + u8 tmp[banks * 16]; /* Up to 64-bit address + 64-bit size */
> >
> > - if (banks > MEMORY_BANKS_MAX) {
> > - printf("%s: num banks %d exceeds hardcoded limit %d."
> > - " Recompile with higher MEMORY_BANKS_MAX?\n",
> > - __FUNCTION__, banks, MEMORY_BANKS_MAX);
> > + if (!banks)
> > return -1;
> > - }
> >
> > err = fdt_check_header(blob);
> > if (err < 0) {
> > --
> > 2.7.4
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180813/49254a37/attachment.sig>
next prev parent reply other threads:[~2018-08-13 14:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-12 20:37 [U-Boot] [PATCH] fdt_support: Use VLA instead of MEMORY_BANKS_MAX Ramon Fried
2018-08-13 7:20 ` Peter Robinson
2018-08-13 14:52 ` Tom Rini [this message]
2018-08-13 18:54 ` Ramon Fried
2018-08-13 16:08 ` Tom Rini
2018-08-13 16:14 ` Ramon Fried
2018-08-13 16:15 ` Tom Rini
2018-08-13 16:22 ` Ramon Fried
2018-08-13 19:55 ` Ramon Fried
2018-08-13 16:59 ` Tom Rini
2018-08-13 17:19 ` Ramon Fried
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180813145205.GZ29229@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox