Dale Farnsworth wrote:

Scott wrote:

quoted

Personally, I'm fine with just using name and compatible, but others such as
Stuart have expressed a desire for something to formally indicate compliance
with a standard binding.  I don't think we should expand the use of
device_type in any case.

I agree that the existing compatible property is sufficient to do
what Stuart wants.  All that is required is to define some standard
bindings and give them well-known names for the compatible property.
If needed, we could define a prefix that indicates that a compatible
entry refers to a standards-compliant binding.  For example,
"standard,network", or "standard,display".  I don't see the benefit
of creating a new property similar to device_type.

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 (with the glorious exception of
potentially giving it a "compatible" of "vga" - on PCI this is
handled very easily by the PCI class code! Which was exactly my
point..).

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?

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" but since it is a network adapter,
have device_type "ethernet". 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.

-- 
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations