All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.