Yoder Stuart-B08248 wrote: > We've had some discussions internally here at Freescale among > various PPC Linux developers about the device_type property > and how 'classes' of devices should be represented in the > device tree. > > The initial list of official classes would be small-- > "cpu","memory", "cache", "pci", "serial", "network", > "open-pic"(?). As other types get codified in actual use > and have official bindings specified (perhaps through > power.org) new types would be supported--e.g. "i2c", > "jdec-flash". > > Thoughts?
I think device_type, compatible and model properties fulfil this already, they simply aren't being used correctly. Remember that, while you may want to make FDTs easier to design, OpenFirmware and the requirement on device interfaces through the client interface still exist and are still implemented (from time to time). What I would recommend is that the device_type encapsulate the class of the device as it is currently. This means for a display, you set device_type to "display". OF platform devices for displays can then get a list of all the "displays" available on a system, or "i2c" controllers available on a system. For readability, the name of the device needn't match device_type; for instance on the 5121E it may be that the 'diu' unit be called diu, but be of device_type 'display' - further information can be added through the 'compatible' property of devices that also support the same register model. Further differentiation should be done through the 'model' property in my opinion. This is optional in the OpenFirmware spec, but that does not mean it should be important. It is currently defined as something to determine the exact model of a chip in order to enable quirks, bugfixes and suchlike, but most implementations switch on something else entirely (like SVR or a heuristic behaviour). Selecting the "model" would be no different to, for example, having a list of PCI IDs that will work with a driver. Basically, I envision that instead device trees should be a little more verbose, and that OF device probing should be improved so that drivers can hook in on many levels of matching. There was a little discussion at bplan once that it would be easier to implement a kind of vendor/device id system much like PCI, USB etc. implements in hardware in order to match hardware. I suppose you could use a "class" property to implement this - but for instance in the case of USB or PCI, this is already encoded in the device_type for anything the firmware cannot work out (pci1106,6062 or so). Perhaps it is a solution though; mark each device with a class property, for instance on the 5200B give it a unique chip ID (fsl5200 or soc5200?) and each unit a device id and take a big hint from PCI class codes and programming interfaces here - USB might be fsl5200,0c0310 (0c, 03 and 10 are all the PCI class, subclass and progif for USB OHCI). Additionally you can add more specific information such as the type of USB controller, for instance in the case of EHCI, perhaps also differentiate between EHCI with a companion controller, EHCI with a transaction translator and no companion controller, etc. with a further code - fsl520B,0c0320.01 References to peek at: http://www.openbios.org/data/docs/bus.usb.pdf http://www.openbios.org/data/docs/bus.pci.pdf Especially take a peek at the PCI docs, page 10 where "Table 1: Generic Names based upon Class Code" gives a bunch of really nice name/device_types. Note that none of this adds any further properties to the specification for identification - you can do it all using device_type and compatible. So, why not start up a registry of vendor, device and "class-code" numbers for SoC devices for when PCI numbering cannot adequately fill the gap? In this case, Freescale, IBM, AMCC and PASemi already have registered vendor codes, class-codes for 99% of interfaces can be derived from the PCI specifications? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
