From: Thierry Reding <treding@nvidia.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] fdt: Fix fdtdec_get_addr_size() for 64-bit
Date: Tue, 4 Aug 2015 17:36:26 +0200 [thread overview]
Message-ID: <20150804153625.GG3812@ulmo.nvidia.com> (raw)
In-Reply-To: <55C0D8EF.2060702@wwwdotorg.org>
On Tue, Aug 04, 2015 at 09:23:27AM -0600, Stephen Warren wrote:
> On 08/04/2015 08:26 AM, Thierry Reding wrote:
> ... [ discussion of new fdtdec_get_addr_size() implementation]
> >So what this does is really fix parsing of address and size cells in the
> >general case, though it would still fail for values of #address-cells or
> >#size-cells bigger than 2 (because we don't have a datatype that would
> >be able to contain such large values).
> >
> >Note that there's also still a corner case that this doesn't handle. The
> >DT specification states, if I remember correctly, that #address-cells
> >and #size-cells are inherited. That means with the current code we will
> >wrongly parse something like this:
> >
> > / {
> > ...
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ...
> > bus at XXXXXXXX {
> > ...
> > device at XXXXXXXX {
> > ...
> > reg = <0xXXXXXXXX 0x1000>;
> > ...
> > };
> > ...
> > };
> > ...
> > };
> >
> >According to the DT specification the bus at XXXXXXXX node would inherit
> >#address-cells = <1> and #size-cells = <1> from the root node. However
> >with libfdt what really happens is that since bus at XXXXXXXX does not have
> >either property it will default to 2 in both cases. I'm not sure if this
> >really is a problem. Typically nodes are not nested that deeply, or if
> >they are then, typically, they explicitly contain #address-cells and
> >#size-cells properties.
>
> I don't think #address-cells/#size-cells do actually get inherited.
> Admittedly some other properties (e.g. interrupt-parent) do, but according
> to:
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2008-January/049113.html
> [PATCH] powerpc: #address-cells & #size-cells properties not inherited
>
> ... and my vague memory, these two don't.
>
> You can search Google for e.g. "#address-cells inherited" and find a number
> of similar assertions.
Okay, that's good. It means there's not even a corner case. =)
Thierry
-------------- 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/20150804/e48d0499/attachment.sig>
prev parent reply other threads:[~2015-08-04 15:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 16:51 [U-Boot] [PATCH] fdt: Fix fdtdec_get_addr_size() for 64-bit Stephen Warren
2015-07-27 17:13 ` Simon Glass
2015-08-02 21:27 ` Simon Glass
2015-08-04 14:26 ` Thierry Reding
2015-08-04 15:23 ` Stephen Warren
2015-08-04 15:36 ` Thierry Reding [this message]
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=20150804153625.GG3812@ulmo.nvidia.com \
--to=treding@nvidia.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.