Subnodes of vendor-added nodes

Subnodes of vendor-added nodes

[David VomLehn]

I know the device tree has a protocol for vendors to extend the types of nodes without
causing namespace collisions, e.g. acme,explosives. Do subnodes and properties of the
extended nodes also need the leading <vendor> and comma?
-- 
David VL

Re: Subnodes of vendor-added nodes

[Grant Likely]

On Mon, Sep 19, 2011 at 10:37 PM, David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> I know the device tree has a protocol for vendors to extend the types of nodes without
> causing namespace collisions, e.g. acme,explosives. Do subnodes and properties of the
> extended nodes also need the leading <vendor> and comma?

Nope; haven't done that so far.  There isn't the same threat of
namespace conflict there because deciding by-name what to do with a
node is generally discouraged.  There are cases where it is
appropriate, (ie. /chosen and /cpus), but generally nodes should be
named according to the "generic names" recommended practice.

g.

Re: Subnodes of vendor-added nodes

[David Gibson]

On Mon, Sep 19, 2011 at 09:37:35PM -0700, David VomLehn wrote:
> I know the device tree has a protocol for vendors to extend the types of nodes without
> causing namespace collisions, e.g. acme,explosives. Do subnodes and properties of the
> extended nodes also need the leading <vendor> and comma?

If the subnodes and properties in question have the semantics of
existing nodes or properties, just in the context of the new vendor
node, then no, you can use the existing names.

If they're newly defined nodes and properties with their own new
semantics, then, yes, they should have the vendor prefix.

There is some grey area here.  IBM, for example, it its OF
implementations has heaps of "ibm,XXX" properties for things which
were not defined at the time the old OF working group stopped doing
much of anything.  Some of these are truly vendor specific and deserve
the prefix, others are actually pretty general in concept and it would
have been nice in some ways to define new general bindings for them
without the vendor prefixes.

-- 
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

Re: Subnodes of vendor-added nodes

[Grant Likely]

On Mon, Sep 19, 2011 at 10:58 PM, David Gibson
<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> On Mon, Sep 19, 2011 at 09:37:35PM -0700, David VomLehn wrote:
>> I know the device tree has a protocol for vendors to extend the types of nodes without
>> causing namespace collisions, e.g. acme,explosives. Do subnodes and properties of the
>> extended nodes also need the leading <vendor> and comma?
>
> If the subnodes and properties in question have the semantics of
> existing nodes or properties, just in the context of the new vendor
> node, then no, you can use the existing names.
>
> If they're newly defined nodes and properties with their own new
> semantics, then, yes, they should have the vendor prefix.
>
> There is some grey area here.  IBM, for example, it its OF
> implementations has heaps of "ibm,XXX" properties for things which
> were not defined at the time the old OF working group stopped doing
> much of anything.  Some of these are truly vendor specific and deserve
> the prefix, others are actually pretty general in concept and it would
> have been nice in some ways to define new general bindings for them
> without the vendor prefixes.

Hmmm, good point.  It would be a good idea to use the prefix for the
properties of the sub nodes (assuming they aren't truly generic).  The
node names should be fine without however.

g.