RFC: replace device_type with new "class" property?
Scott Wood
scottwood at freescale.com
Tue Oct 30 06:30:17 EST 2007
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
More information about the Linuxppc-dev
mailing list