> > 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
