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

[John Bonesio]

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?

>