From: Thierry Reding <thierry.reding@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fdt: Fixup only valid memory banks
Date: Tue, 30 Jan 2018 13:09:06 +0100 [thread overview]
Message-ID: <20180130120906.GA14576@ulmo> (raw)
In-Reply-To: <20180130124115.24d0d2fe@karo-electronics.de>
On Tue, Jan 30, 2018 at 12:41:15PM +0100, Lothar Waßmann wrote:
> Hi,
>
> On Tue, 30 Jan 2018 11:34:17 +0100 Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Memory banks with address 0 and size 0 are empty and should not be
> > passed to the OS via device tree.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > common/fdt_support.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > index 724452d75452..8b33f6773d27 100644
> > --- a/common/fdt_support.c
> > +++ b/common/fdt_support.c
> > @@ -457,7 +457,7 @@ int fdt_record_loadable(void *blob, u32 index, const char *name,
> > int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
> > {
> > int err, nodeoffset;
> > - int len;
> > + int len, i;
> > u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
> >
> > if (banks > MEMORY_BANKS_MAX) {
> > @@ -489,6 +489,12 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
> > if (!banks)
> > return 0;
> >
> > + for (i = 0; i < banks; i++)
> > + if (start[i] == 0 && size[i] == 0)
> > + break;
> > +
> > + banks = i;
> > +
> > len = fdt_pack_reg(blob, tmp, start, size, banks);
> >
> > err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
> >
> Does an empty bank always imply the end of the list, or
> Is it a valid scenario to have intervening empty banks?
I think it's a fair assumption that there aren't going to be any holes.
The vast majority of boards will only every initialize a single bank or
perhaps two. There's a few odd ones (hisilicon/hikey for example) that
adds more, but they are still all contiguous.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180130/5225481b/attachment.sig>
next prev parent reply other threads:[~2018-01-30 12:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 10:34 [U-Boot] [PATCH] fdt: Fixup only valid memory banks Thierry Reding
2018-01-30 11:41 ` Lothar Waßmann
2018-01-30 12:09 ` Thierry Reding [this message]
2018-01-30 17:59 ` Stephen Warren
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=20180130120906.GA14576@ulmo \
--to=thierry.reding@gmail.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