Subject: Re: RFC: replace device_type with new "class" property?

From: Scott Wood <[email-masked]>
Date: Mon, 29 Oct 2007 14:30:17 -0500

Matt Sealey wrote:
> I don't see how this makes anything any better.
> 
> Under Open Firmware, if device_type is "display", then it had better
> act as a display through the client interface, interpose it's framebuffer
> methods properly and suchlike.
> 
> In FDT, what is the purpose of the binding but to report devices? It
> does not really define any interface whatsoever. Having it "conform
> to a standards-compliant binding" by reporting standard,display goes
> in the direction of ignoring the simple fact that most displays act
> and are programmed very differently

In that case, it probably make sense to simply not have a binding for 
displays.

> I would say the same for USB, where standard,usb would be really
> glossing over the simple fact that *all usb controllers should by
> default be created equal*. OHCI does not act any different, and
> UHCI doesn't act any different, in the specification. If the chip
> does weird things, you do not go around revoking it's status as an
> OHCI controller, do you?

If its weird things are sufficiently non-OHCI, yes. :-)
Good luck fitting a CPM USB controller into some *HCI designation.

> As an addendum to Scott's other mail I came up with a good reason to
> give users readable names but standard device_types. Consider 802.11g,
> which may have a name of "wifi"

This is reasonable.

> but since it is a network adapter, have device_type "ethernet".

This is acceptable as existing practice, but "standard,ethernet" would 
be just fine.  And there may be additional properties defined for 
wireless devices, and an additional "standard,wifi" binding could be 
added.  You can't have multiple device_types.

> It is ethernet after all, but users would like to know which it is
> compared with the onboard ethernet, given a list of devices on the OF
> console, without knowing the base addresses of registers.

My preferred solution to this particular problem is a label property, 
that can go beyond ethernet/wifi and say things like "front panel 
ethernet", "back panel ethernet A", "back panel ethernet B", "wireless", 
etc., without taking away name's existing use, and without limiting the 
label to the characters allowed in a node name.

-Scott