RFC: replace device_type with new "class" property?

[Yoder Stuart-B08248]

> > 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.
> 
> > > 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"
> > > class compliant.
> > > 
> > > Or to look at it another way, "class bindings" aren't 
> really bindings,
> > > 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.

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.

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.

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

Stuart