dts and dtsi files on which I tested the syntax for my recent patch set.

Grant Likely grant.likely at secretlab.ca
Thu Oct 21 16:40:24 EST 2010


On Wed, Oct 20, 2010 at 10:06:00PM -0700, John Bonesio wrote:
> On Thu, 2010-10-21 at 14:14 +1100, David Gibson wrote:
> > On Wed, Oct 20, 2010 at 07:08:36PM -0700, John Bonesio wrote:
> > > On Wed, 2010-10-20 at 17:46 -0600, Grant Likely wrote:
> > > > On Wed, Oct 20, 2010 at 03:22:17PM -0700, John Bonesio wrote:
> > > > > Hi,
> > > > > 
> > > > > I have attached the two file I've used to test the new syntax from my
> > > > > patch set. These might help get a feel for how the syntax and the
> > > > > features work.
> > > > 
> > > > heh, what you should actually do (because you have to anyway) is add
> > > > testcases for the new features to dtc in the tests directory.  'make
> > > > check' runs the test cases.
> > > > 
> > > > > /remove-node/ &{soc/serial at 2400};                  /* an example of using a label rooted path */
> > > > 
> > > > As previously mentioned by David, this conflicts with the already
> > > > established convention of a path that does not start with a '/' means
> > > > use a value from the /aliases node.  That ambiguity needs to
> > > > be avoided, so the syntax still needs some massaging.
> > > 
> > > I think we should explore this a bit further. I just don't see in the
> > > lexer code where it would parse anything with the syntax
> > > &{alias/node/path} (except for my recent patch).
> > > 
> > > I looked through the parser too, and it wasn't obvious where it would
> > > match '&' directly.
> > > 
> > > Maybe I'm just missing it.
> > 
> > No, we just weren't being clear.  dtc does not itself expand aliases
> > in this way.  However, it's a common convention in existing device
> > tree stuff.  The OF interface will expand aliases in this way, as will
> > fdt_path_offset().
> > 
> > So it's not an actual ambiguity with existing syntax, but the fact
> > that your proposed syntax is subtley different from a common existing
> > device tree convention would violate least-surprise.
> 
> Would it really? Isn't an alias and a label on a node pretty much the
> same concept?

Nope, because an alias is a property in the /aliases node with very
well defined conventions.  A label uses an entirely different namespace,
so it should use a different syntax to avoid being ambiguous.

g.



More information about the devicetree-discuss mailing list