On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:

quoted

quoted

I think what we should do is keep device_type, including
permitting new uses of it in a limited way-- only permitting
the use of device_type when there is an official binding
(like in the power.org ePAPR) defined.    

That's what I was thinking when we first started defining flat tree
bindings.  But the more time I've spent thinking about it, and the
more time I've spent reviewing people's proposed bindings, the less
useful I think it is.

The *only* reason I'm suggesting leaving device_type values for
IEEE1275 defined classes is so that flat trees written as flat trees
look more similar to OF derived trees.

quoted

quoted

Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice.  If it looks like a "duck" class device node, and it
quacks^Whas the properties of a "duck" class device node, 

it's "duck"

quoted

quoted

class compliant.

Or to look at it another way, "class bindings" aren't 

really bindings,

quoted

quoted

but rather a set of conventions that device bindings for specific
devices in that class ought to follow.

I tend to think of a 'binding' as a 'set of conventions'.

Well, whatever.  My point is that conventions are most flexible if you
don't have to explicitly announce that you're following them - you
just go ahead and follow as many conventions as make sense for your
device.

Let me repeat what I think you are advocating--  we should
treat the collection of properties for 'established' device
classes like like "network", "serial", etc as a set of useful 
conventions.  That is, there are no set of _required_ properties
per se, but the device tree creator picks from the established
properties plus supplementing with "company,xyz" properties
in whatever way they think makes sense for them.

Not the device tree creater, the device binding creator (though for
"one-off" type devices those may be the same person).

This works...but certainly is weaker with respect to
standardization.  My previous argument had the assumption
that something like "mac-address" in a network node was
_required_, and thus needed a class id of some sort to tie
the standardized node to.

Not for a network device type that represented a point-to-point link..

(Well, technically most nodes should lack 'mac-address', but I think
'local-mac-address' is what you meant)

If we relax things so there are no required properties for
device nodes, then I agree that a device class property
has limited or no value.

There are required properties, but the requrements are done at the
device binding (i.e. compatible property) level.  Those bindings might
in turn reference class requirements ("A foobaz-ethernet node must
have all the standard properties for a network node described in
Sx.y.z, and in addition must have foobaz,frobnication-quotient").

However, maybe we do want to keep device_type in 
a very limited way to define requirements for what you
call 'fundamental' types of nodes.  It may be that certain
properties in a "cpu" node (like cache-size?) should be
_required_ so that an OS that consumes the device tree
can really count on certain properties being there.  Or,
I guess we could use "compatible" for that...?

No, I'm saying keep device_type for cpu and memory - we could do
otherwise but it would be a gratuitous divergence from OF trees.  And
yes they should have their required properties, too.

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