> -----Original Message-----
> From: David Gibson [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 7:52 PM
> To: Olof Johansson
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
> [snip]
> > I don't see how switching the property name from "device_type" to
> > "class" is going to stop people from misunderstanding it's intended
> > use. There's nothing inherently more understandable in calling it
> > "class" -- it also invites people to make up their own class names
> > as they go along, just as what happened to "device_type".
> >
> > I also don't understand the people wanting to use "compatible"
> > for _everything_. It's just mashing together two separate pieces of
> > information into one property, and I seriously don't see
> how that helps
> > anything or anyone. It's absolutely useless for a driver to
> be able to
> > bind to a compatible field of "standard,network" or
> whatever it might be,
> > since there's no way that "standard," will imply that the
> register layout
> > and programming model is somehow the same as all other
> standard-labelled
> > devices.
> >
> > So yes, there is a problem with the device trees and how
> people build
> > them, and it requires education on how to properly craft
> one. I don't
> > think changing the layout to either be flatter (only using
> compatible),
> > or changing names of a property (device_type->class) will
> help anything
> > at all.
> >
> > I actually prefer keeping device_type myself, since it
> means existing
> > OF-based device trees will already have some of the labels.
>
> Yeah.. what he said.
>
> The *only* substantive change with the "class" proposal is the fact
> that multiple classes can be specified. That's nice, but I don't
> think it's worth the trouble of attempting to define a whole new chunk
> of standard for.
I tend to agree, but I think device_type serves a useful
purpose. I don't think we should deprecate it.
> Stuart, I think you overestimate the value of this class property to a
> human reader. The generic names convention (not followed as much as
> it should be) means the name should give the reader some idea of what
> the device is, in most cases. For trickier cases, if we really want
> something for humans reading the tree, we could add an optional
> "comment" or "description" property with purely human readable
> information.
>
> I think we should leave existing IEEE1275 defined uses of device_type,
> in order not to make flat trees gratuitously different from real-OF
> trees, but we should avoid any new use of device_type.
I'm fine with keeping device_type, but there are a few
of things I don't like about the 'no new use'.
1. There are types of nodes that don't have a programming
inteface per se and thus no compatible.
"cpu", "memory", "cache" are 3 that come to mind.
What if there is a _new_ class of nodes of this type?
What is wrong with a new use of device_type for something
say like "i2c"?
Conceptually and ideally, what _is_ the right way to
represent these types of devices.
2. 'Existing IEEE1275 defined uses' of device_type is
actually very vague. There are a conglomeration of
old bindings, recommended practices, proposals and
it is not clear at all which are useful or not. What
are the existing IEEE1275 uses??? I actually went
through all the OF documents and there are dozens
of device types that have no practical use.
Also, many 'real-OF' trees seem to follow no published
binding at all.
Conceptually, I'd like to a crisp list of 'official'
bindings and hope that the current ePAPR work in
power.org will establish this list.
3. You're advocating deprecating device_class, but still
requiring it for certain node types. So a "network"
node is _required_ to have the deprecated
device_type="network". But a "i2c" node is required
_not_ to have device_type. Long term, I'd like to see
any inconsitency be removed. If device_type is
deprecated, it's use should be optional in flat
device trees. That goes for "cpu", "memory", etc.
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.
> 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'.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
