From: David Gibson <david@gibson.dropbear.id.au>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jon Loeliger <jdl@jdl.com>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree-compiler@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH/RFC dtc 0/2] Drop unit addresses from overlay fragments
Date: Wed, 7 Mar 2018 14:34:50 +1100 [thread overview]
Message-ID: <20180307033450.GG3083@umbus.fritz.box> (raw)
In-Reply-To: <20180305064013.GM2650@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]
On Mon, Mar 05, 2018 at 05:40:13PM +1100, David Gibson wrote:
> On Fri, Feb 23, 2018 at 09:35:15AM +0100, Geert Uytterhoeven wrote:
> > Hi all,
> >
> > Using "fragment@N" as node name for overlay fragments violates unit
> > address rules:
> >
> > <stdout>: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
>
> Hm, regardless of this patch, that's really a bug in the checks not to
> handle overlays as a different case.
>
> The quick fix would be to just suppress that check if an __overlay__
> subnode exists. THe more ambitious approach would be to actually
> parse things that look like overlays into their components and apply
> checks separately to each fragment (except for ones that don't make
> sense except on a fully resolved tree). I had plans for that, but am
> unlikely to get time to work on it any time soon.
Fwiw, I've now made such a change to the checks. However, I think you
can still get a similar problem in the generated __local_fixups__ node
for similar reasons. That one's a bit harder to check.
>
> > This patch series (for dtc) fixes:
> > 1. generation of node names when using overlay sugar syntax,
> > 2. all documentation and tests.
> >
> > If this is accepted, I'll send similar patches for Linux.
> >
> > Note that I've been using "fragment-N" in hand-written DT overlays for
> > years, so this is known to work fine with Linux.
>
> Existing tools expecting the @ would be my only concern with this.
> You've check Linux is ok, and I've checked libfdt is ok too. I'm not
> really confident if that's enough to call it everything we care about.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-03-07 3:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 8:35 [PATCH/RFC dtc 0/2] Drop unit addresses from overlay fragments Geert Uytterhoeven
2018-02-23 8:35 ` [PATCH/RFC dtc 1/2] overlay: Do not use @ in overlay fragment generation Geert Uytterhoeven
2018-02-23 8:35 ` [PATCH/RFC dtc 2/2] Use "fragment-N" instead of "fragment@N" Geert Uytterhoeven
2018-03-05 6:40 ` [PATCH/RFC dtc 0/2] Drop unit addresses from overlay fragments David Gibson
2018-03-07 3:34 ` David Gibson [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=20180307033450.GG3083@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=devicetree-compiler@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=geert+renesas@glider.be \
--cc=jdl@jdl.com \
--cc=pantelis.antoniou@konsulko.com \
--cc=robh+dt@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).