From: David Gibson <david@gibson.dropbear.id.au>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Olof Johansson <olof@lixom.net>, Jon Loeliger <jdl@jdl.com>,
Frank Rowand <frowand.list@gmail.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Rob Herring <rob.herring@calxeda.com>,
Grant Likely <grant.likely@secretlab.ca>,
Stephen Warren <swarren@nvidia.com>
Subject: Re: [dtc RFC PATCH] Enforce node name unit-address presence/absence
Date: Thu, 19 Sep 2013 22:31:03 +1000 [thread overview]
Message-ID: <20130919123103.GD3551@voom.redhat.com> (raw)
In-Reply-To: <523A30FC.3060309@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
On Wed, Sep 18, 2013 at 05:02:20PM -0600, Stephen Warren wrote:
> On 09/18/2013 02:41 PM, Olof Johansson wrote:
> > On Wed, Sep 18, 2013 at 1:23 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> From: Stephen Warren <swarren@nvidia.com>
> >>
> >> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
> >> node that has a reg property must include a unit address in its name
> >> with value matching the first entry in its reg property. Conversely, if
> >> a node does not have a reg property, the node name must not include a
> >> unit address.
> >>
> >> Implement a check for this. The code doesn't validate the format of the
> >> unit address; ePAPR implies this may vary from binding to binding, so
> >> I'm not sure that it's possible to validate the value itself.
> ...
> > Anyway, I think it'd be better to produce warnings than errors for
> > this. That way we could also merge it now while the trees are fixed
> > up.
>
> Yes, that makes sense.
>
> > Also, maybe warn for @0x<foo>, which is another unpreferred syntax, it
> > should just be @<foo> (with foo being in hex).
>
> ePAPR doesn't seem to disallow that; it explicitly says that the
> unit-address consists of the characters from table 2-1, which is the
> same table of characters used for the node name itself. However, it does
> state that the binding for a particular bus may impose additional
> restrictions; should I implement such a check but limit it to the root
> node or specific known bus types? That would require explicitly
> whitelisting the check for a lot of bus types, given that each I2C/...
> controller binding is a bus type...
Yeah, I think that's the wrong approach. Instead I think we need a
table of bus type -> unit address validation functions. That way we
can start with the common ones - plain memory address, PCI, USB and
I2C, then add more as we need them.
I actually started implementing this once, but I seem to have lost the
patch.
One thing to bear in mind if you do have a crack at this - the correct
encoding of reg -> unit address isn't always unique, although it
usually is.
--
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: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-09-19 12:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 20:23 [dtc RFC PATCH] Enforce node name unit-address presence/absence Stephen Warren
[not found] ` <1379535836-12726-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-18 20:41 ` Olof Johansson
2013-09-18 20:41 ` Olof Johansson
[not found] ` <CAOesGMg0Rrmew0iK-Gtrx_UiODhpro_S2xUxQi0gZ+7PJmBHnw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-18 23:02 ` Stephen Warren
2013-09-18 23:02 ` Stephen Warren
2013-09-19 12:31 ` David Gibson [this message]
2013-09-19 7:10 ` Benjamin Herrenschmidt
2013-09-19 7:10 ` Benjamin Herrenschmidt
2013-09-19 12:27 ` David Gibson
2013-09-19 12:27 ` David Gibson
2013-09-19 12:33 ` David Gibson
2013-09-19 12:33 ` David Gibson
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=20130919123103.GD3551@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=jdl@jdl.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=olof@lixom.net \
--cc=rob.herring@calxeda.com \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.org \
--cc=tomasz.figa@gmail.com \
/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.