Dale Farnsworth wrote: > Scott wrote: >> 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 <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev