Re: RFC: replace device_type with new "class" property?
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
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: > I think device_type, compatible and model properties fulfil > this already, they simply aren't being used correctly. device_type has a few drawbacks, though: 1. You can only specify one type, whereas with a new property we could define it as a list (similar to compatible). It's possible for one node to comply with multiple class bindings, such as when there's a binding for clients of the type of bus it's on as well as the type of device it is, or when there are multiple levels of detail (such as complying with both simple-bus and some specific bus binding). 2. We want to avoid any confusion with OF bindings and abused device_type entries that have been allowed to become existing practice. 3. It's the only standard property (AFAIK) with an underscore in it. :-) > 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). Sure -- and we don't want to risk the code thinking it can call into OF based on what we put in a flat device tree, right? > 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' I don't think that's more readable than setting the name to display. Something containing "diu" will be in the compatible list. > 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. It's what we currently do with compatible. Why break it into two properties? The PCI ID thing can be quite a headache, BTW, when you get a new PCI device that won't work with the existing driver, for no reason other than that it hasn't been updated with the new ID. > 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 - No, you should use compatible for that. > 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). No, that goes in name/compatible according to the OF PCI binding. > 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?) No. That's precisely the sort of device_type abuse we want to get away from with class. 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. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
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. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
Scott Wood wrote: > On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: >> I think device_type, compatible and model properties fulfil >> this already, they simply aren't being used correctly. > > device_type has a few drawbacks, though: > > 1. You can only specify one type, whereas with a new property we could > define it as a list (similar to compatible). This is the whole point; device_type and compatible are companion properties. You specify the exact thing in device_type and give it a list of compatible device_types in compatible. > 2. We want to avoid any confusion with OF bindings and abused device_type > entries that have been allowed to become existing practice. Creating whole new device type bindings that are not OF standards, which puts OF vendors at a sort of impass; do they comply to the Open Firmware standard or use the Linux Standard? Flat device trees are already somewhat of a strange beast, it is probably best not to make them much stranger. > 3. It's the only standard property (AFAIK) with an underscore in it. :-) Petty :D >> 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' > > I don't think that's more readable than setting the name to display. > Something containing "diu" will be in the compatible list. It at least makes the device tree far more human readable. "Name" and "Device Type" are not required to be the same thing. A name is just a human readable marker, device_type is what drivers need to match on. While name is derived from device_type on creation of a device (after all a display is a display), giving it a human readable name is sometimes a boon. Remember that Open Firmware is not just a text file you compile with U-Boot - the console you get on boot needs to be useful to users too. In that sense, 8 USB controllers with names [EMAIL PROTECTED], [EMAIL PROTECTED] going upwards to infinity is not the greatest thing in the world. >> Selecting the "model" would be no different to, for example, >> having a list of PCI IDs that will work with a driver. > > It's what we currently do with compatible. Why break it into two > properties? Because encoding human-readable descriptions of devices in the compatible property is ridiculously long-winded. Currently it's being terribly misused, in my opinion (USB especially, there is no need to tell that it is "compatible" with mpc5200b-usb, USB is a well-defined standard with 3 possible host controllers, encoding the specific SoC into it is going way overboard) > No, you should use compatible for that. > > No, that goes in name/compatible according to the OF PCI binding. This is absolutely contrary to your own request for comments; you want to implement a new class property, but.. you can use device_type and compatible for it, as is evident everywhere and in two already existing bus bindings. If you need more information in the device tree for each device, I simply recommend we take a hint from the PCI and USB bindings and add properties of the same names and descriptions (why create new standards when old ones work fine). >> 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?) > > No. That's precisely the sort of device_type abuse we want to get away from > with class. It is not an abuse to give a device_type by some very easily matchable device type. > 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. You can formally indicate compliance with a standard binding by using the standard bindings.. be they the USB or PCI standard, be your device not on USB or PCI, they already exist, and already do what Stuart asks. For devices which do not have a standard binding you run into a problem; who arbitrates what class goes where? Reusing vendor codes from PCI and USB, class codes from PCI and USB, and implementing a few 'non-standard others' is far more efficient as there is plenty of code in the Linux tree for parsing and collecting this data. It is not so far a leap to go from parsing "pci" or "usb" device_types to collecting "fsl" or "soc" data and a selection of appended codes. Therefore, if there is not a standard binding that gives it a neat name (i2c would be a good example), I suggest following the route of PCI and USB, and encoding that specific device as a set of matchable codes, rather than a list of strings. "soc5121,0c0320" matches a device exactly where "usb" particularly does not. As with the specification for PCI where such a device may not have a particular device_type name (not a good example with USB) simply prefix with the bus type, then vendor code, device code, class
Re: RFC: replace device_type with new "class" property?
Matt Sealey wrote: > Scott Wood wrote: >> On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: >>> I think device_type, compatible and model properties fulfil this >>> already, they simply aren't being used correctly. >> >> device_type has a few drawbacks, though: >> >> 1. You can only specify one type, whereas with a new property we >> could define it as a list (similar to compatible). > > This is the whole point; device_type and compatible are companion > properties. You specify the exact thing in device_type and give it a > list of compatible device_types in compatible. That sounds more like a description of "model", or the original use of "name", than device_type. >> 2. We want to avoid any confusion with OF bindings and abused >> device_type entries that have been allowed to become existing >> practice. > > Creating whole new device type bindings that are not OF standards, > which puts OF vendors at a sort of impass; do they comply to the Open > Firmware standard or use the Linux Standard? We try to stay compatible with OF when practical; however, we have no choice if an OF device_type implies a method interface that we cannot provide. >>> 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' >> >> I don't think that's more readable than setting the name to >> display. Something containing "diu" will be in the compatible list. >> > > It at least makes the device tree far more human readable. Unless you're familiar with the hardware, "diu" is likely to be a meaningless acronym. "display" is obvious, and much more human-friendly. > While name is derived from device_type on creation of a device (after > all a display is a display), giving it a human readable name is > sometimes a boon. name generally comes from the generic names document, not device_type. > Remember that Open Firmware is not just a text file you compile with > U-Boot - the console you get on boot needs to be useful to users too. > In that sense, 8 USB controllers with names [EMAIL PROTECTED], > [EMAIL PROTECTED] going upwards to infinity is not the greatest thing in > the world. And the alternative is? >>> Selecting the "model" would be no different to, for example, >>> having a list of PCI IDs that will work with a driver. >> >> It's what we currently do with compatible. Why break it into two >> properties? > > Because encoding human-readable descriptions of devices in the > compatible property is ridiculously long-winded. Putting something human readable in model is fine. It's not a reason to force drivers to care about it by failing to include a highly specific entry in the compatible list. > Currently it's being terribly misused, in my opinion (USB especially, > there is no need to tell that it is "compatible" with mpc5200b-usb, > USB is a well-defined standard with 3 possible host controllers, > encoding the specific SoC into it is going way overboard) Well, there are various non-standard registers also present on many embedded USB controllers. >> No, you should use compatible for that. >> >> No, that goes in name/compatible according to the OF PCI binding. > > This is absolutely contrary to your own request for comments; you > want to implement a new class property, but.. you can use device_type > and compatible for it, as is evident everywhere and in two already > existing bus bindings. It was Stuart's RFC, not mine. :-) What I originally proposed was deprecating device_type, and using name and compatible. Stuart wanted something to indicate formal adherence to a standard binding, so I suggested "class" if such a thing is really needed. You seem to be confusing name and device_type, BTW. >>> 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?) >> >> No. That's precisely the sort of device_type abuse we want to get >> away from with class. > > It is not an abuse to give a device_type by some very easily > matchable device type. That's not a device type, it's a device. > For devices which do not have a standard binding you run into a > problem; who arbitrates what class goes where? The issue that brought all this up was new bindings for device classes that OF doesn't have bindings for. > Reusing vendor codes from PCI and USB, OF already specifies OUI numbers for this, why be different? We use things like "ibm" and "fsl" for common, unambiguous vendors for readability sake. > class codes from PCI and USB, What do we need the class codes for? > and implementing a few 'non-standard others' is far more efficient as > there is plenty of code in the Linux tree for parsing and collecting > this data. I highly doubt there's any code in Linux that wants a PCI or USB class ID for something that isn't a PCI or USB device. > It is not so far a leap
Re: RFC: replace device_type with new "class" property?
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
Re: RFC: replace device_type with new "class" property?
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
Here's an example of what I'm trying to get at-- take a node from a FSL device tree. The ideas I've heard for expressing the class are like this-- #1 don't express any class at all: [EMAIL PROTECTED] { compatible = "fsl,ucc_geth"; model = "UCC"; device-id = <3>; reg = <2200 200>; interrupts = <22>; interrupt-parent = < &qeic >; mac-address = [ 00 00 00 00 00 00 ]; local-mac-address = [ 00 00 00 00 00 00 ]; rx-clock = <19>; tx-clock = <1a>; phy-handle = < &phy3 >; pio-handle = < &pio3 >; > This is bad IMHO because the human reader has to > infer the class of device. Can the human reader > tell if it implements a standardized binding or > not?? #2 use device_type [EMAIL PROTECTED] { device_type = "network"; compatible = "fsl,ucc_geth"; model = "UCC"; device-id = <3>; reg = <2200 200>; interrupts = <22>; interrupt-parent = < &qeic >; mac-address = [ 00 00 00 00 00 00 ]; local-mac-address = [ 00 00 00 00 00 00 ]; rx-clock = <19>; tx-clock = <1a>; phy-handle = < &phy3 >; pio-handle = < &pio3 >; }; > This is better...I can tell it implments the network > binding. The problem is the past abuse and OF > connotations. #3 use a new "class" property [EMAIL PROTECTED] { class = "network"; compatible = "fsl,ucc_geth"; model = "UCC"; device-id = <3>; reg = <2200 200>; interrupts = <22>; interrupt-parent = < &qeic >; mac-address = [ 00 00 00 00 00 00 ]; local-mac-address = [ 00 00 00 00 00 00 ]; rx-clock = <19>; tx-clock = <1a>; phy-handle = < &phy3 >; pio-handle = < &pio3 >; }; > This is good...I can tell it implments the "network" > binding. There is no association with the abused > OF device_type. #4 use "compatible" [EMAIL PROTECTED] { compatible = "fsl,ucc_geth","[official spec],network"; model = "UCC"; device-id = <3>; reg = <2200 200>; interrupts = <22>; interrupt-parent = < &qeic >; mac-address = [ 00 00 00 00 00 00 ]; local-mac-address = [ 00 00 00 00 00 00 ]; rx-clock = <19>; tx-clock = <1a>; phy-handle = < &phy3 >; pio-handle = < &pio3 >; }; > I don't like this...we are overloading "compatible" with > stuff that is not specifying a programming interface. compatible > is supposed to be specifying a programming interface which > the device complies to. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
Yoder Stuart-B08248 wrote: > Here's an example of what I'm trying to get at-- take > a node from a FSL device tree. The ideas I've heard > for expressing the class are like this-- > > #1 don't express any class at all: > > [EMAIL PROTECTED] { > compatible = "fsl,ucc_geth"; > model = "UCC"; > device-id = <3>; > reg = <2200 200>; > interrupts = <22>; > interrupt-parent = < &qeic >; > mac-address = [ 00 00 00 00 00 00 ]; > local-mac-address = [ 00 00 00 00 00 00 ]; > rx-clock = <19>; > tx-clock = <1a>; > phy-handle = < &phy3 >; > pio-handle = < &pio3 >; Of course, this should properly be something like [EMAIL PROTECTED] { compatible = "fsl,mpc8360-qe-enet", "fsl,qe-enet"; local-mac-address = [ 00 00 00 00 00 00 ]; ... }; With no "mac-address", and a more useful "model" if any at all. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 07:37:04AM -0700, 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. > > Taking a long term view, the question I'd like to pose is > how should classes of device should be identified in the > flat device tree model? A device class, as I'm using it, > refers basically to general categories of devices-- devices > that share common properties. Examples in current device > would be "cpu", "memory", "pci", "network", "serial". > > Today the device_type property serves this purpose to some > degree. However, the original meaning of device_type in > Open Firmware is related to the method interface of a node > it has a recent history of abuse in the Linux kernel DTS > files, with a plethora of types made up in an ad hoc way. > In addition, an OS can match on "compatible" and in the > absence of method interfaces really doesn't need > device_type anyway. > > However, one good thing about device_type (if properly used) > is that it could identify which device nodes follow an official > binding, vs proprietary devices or one-off device node definitions. > Without something like device_type the _human_ reader of a DTS > file has to infer from the name or compatible what the device > type is. So, device class identifiers like "memory", "cpu", > "serial", "pci", "network" provide that clarity. > > So, what should the long term approach be? Here are a couple > of options: > > 1. Keep device_type, with it's use specifically defined to > mean that the node with that property implements an > 'official' binding. In the flat device tree model a > binding is just a defined set of required (and optional > properties. > > 2. Get rid of device_type and create a _new_ property like > "class". The only nodes permitted to have this property > are those with 'official' bindings. These nodes would > have a set of required (and optional) properties. > > The benefit of a new property is cutting all baggage > associated with the old device_type property. I don't see how switching the property name from "device_type" to "class" is going to stop people from misunderstanding it's intended use. There's nothing inherently more understandable in calling it "class" -- it also invites people to make up their own class names as they go along, just as what happened to "device_type". I also don't understand the people wanting to use "compatible" for _everything_. It's just mashing together two separate pieces of information into one property, and I seriously don't see how that helps anything or anyone. It's absolutely useless for a driver to be able to bind to a compatible field of "standard,network" or whatever it might be, since there's no way that "standard," will imply that the register layout and programming model is somehow the same as all other standard-labelled devices. So yes, there is a problem with the device trees and how people build them, and it requires education on how to properly craft one. I don't think changing the layout to either be flatter (only using compatible), or changing names of a property (device_type->class) will help anything at all. I actually prefer keeping device_type myself, since it means existing OF-based device trees will already have some of the labels. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message- > From: Wood Scott-B07421 > Sent: Monday, October 29, 2007 2:44 PM > To: Yoder Stuart-B08248 > Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > Yoder Stuart-B08248 wrote: > > Here's an example of what I'm trying to get at-- take > > a node from a FSL device tree. The ideas I've heard > > for expressing the class are like this-- > > > > #1 don't express any class at all: > > > > [EMAIL PROTECTED] { > > compatible = "fsl,ucc_geth"; > > model = "UCC"; > > device-id = <3>; > > reg = <2200 200>; > > interrupts = <22>; > > interrupt-parent = < &qeic >; > > mac-address = [ 00 00 00 00 00 00 ]; > > local-mac-address = [ 00 00 00 00 00 00 ]; > > rx-clock = <19>; > > tx-clock = <1a>; > > phy-handle = < &phy3 >; > > pio-handle = < &pio3 >; > > Of course, this should properly be something like > > [EMAIL PROTECTED] { > compatible = "fsl,mpc8360-qe-enet", "fsl,qe-enet"; > local-mac-address = [ 00 00 00 00 00 00 ]; > ... > }; > > With no "mac-address", and a more useful "model" if any at all. That's fine, but as a human reader there is nothing that would tell me this node implemented a defined binding that specified required properties. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote: > #4 use "compatible" > > [EMAIL PROTECTED] { > compatible = "fsl,ucc_geth","[official spec],network"; > model = "UCC"; > device-id = <3>; > reg = <2200 200>; > interrupts = <22>; > interrupt-parent = < &qeic >; > mac-address = [ 00 00 00 00 00 00 ]; > local-mac-address = [ 00 00 00 00 00 00 ]; > rx-clock = <19>; > tx-clock = <1a>; > phy-handle = < &phy3 >; > pio-handle = < &pio3 >; > }; > > > I don't like this...we are overloading "compatible" with > > stuff that is not specifying a programming interface. compatible > > is supposed to be specifying a programming interface which > > the device complies to. If your proposed class property doesn't specify a programming interface, then I agree that we shouldn't put that info in compatible. My point was that compatible is the one and only property that a driver should look at to find a node with a suitable programming interface. But, that begs the question: How will the code use your class property? Another post implied that it's for human-readable purposes. If that's all, I'd leave it out, or use a comment instead. -Dale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote: > On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote: > > I think device_type, compatible and model properties fulfil > > this already, they simply aren't being used correctly. > > device_type has a few drawbacks, though: > > 1. You can only specify one type, whereas with a new property we could > define it as a list (similar to compatible). It's possible for one node to > comply with multiple class bindings, such as when there's a binding for > clients of the type of bus it's on as well as the type of device it is, or > when there are multiple levels of detail (such as complying with both > simple-bus and some specific bus binding). > > 2. We want to avoid any confusion with OF bindings and abused device_type > entries that have been allowed to become existing practice. > > 3. It's the only standard property (AFAIK) with an underscore in it. :-) > > > 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). > > Sure -- and we don't want to risk the code thinking it can call into OF > based on what we put in a flat device tree, right? > > > 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' > > I don't think that's more readable than setting the name to display. > Something containing "diu" will be in the compatible list. > > > 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. > > It's what we currently do with compatible. Why break it into two > properties? > > The PCI ID thing can be quite a headache, BTW, when you get a new PCI device > that won't work with the existing driver, for no reason other than that it > hasn't been updated with the new ID. Indeed. Replacing the flexible string based matching we have already, with a limited ID based matching is just silly. > > 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 - > > No, you should use compatible for that. Yes. Driver binding should be based on compatible. Period. Drivers can enable quirks based on 'model' or any other information available to them (either from the device tree or direct from the hardware). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 10:27:24AM -0700, 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. That would overload the meaning of compatible. A driver which matches any compatible entry should be able to drive the device, even if it can't use all the devices features. You can't do that if all you know is that something is a display. So, standardised or defacto-standard hardware-level interfaces belong in compatible, e.g. ohci, uhci, ns16550. The mere fact that something is a display or network interface (and has *general* properties related to such devices) doesn't let you drive it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote: > > Here's an example of what I'm trying to get at-- take > a node from a FSL device tree. The ideas I've heard > for expressing the class are like this-- > > #1 don't express any class at all: > > [EMAIL PROTECTED] { > compatible = "fsl,ucc_geth"; > model = "UCC"; > device-id = <3>; > reg = <2200 200>; > interrupts = <22>; > interrupt-parent = < &qeic >; > mac-address = [ 00 00 00 00 00 00 ]; > local-mac-address = [ 00 00 00 00 00 00 ]; > rx-clock = <19>; > tx-clock = <1a>; > phy-handle = < &phy3 >; > pio-handle = < &pio3 >; > > > > This is bad IMHO because the human reader has to > > infer the class of device. Can the human reader > > tell if it implements a standardized binding or > > not?? Well... except that by the generic names convention, the node should be called "[EMAIL PROTECTED]", which makes it rather clearer to a human reader. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote: [snip] > I don't see how switching the property name from "device_type" to > "class" is going to stop people from misunderstanding it's intended > use. There's nothing inherently more understandable in calling it > "class" -- it also invites people to make up their own class names > as they go along, just as what happened to "device_type". > > I also don't understand the people wanting to use "compatible" > for _everything_. It's just mashing together two separate pieces of > information into one property, and I seriously don't see how that helps > anything or anyone. It's absolutely useless for a driver to be able to > bind to a compatible field of "standard,network" or whatever it might be, > since there's no way that "standard," will imply that the register layout > and programming model is somehow the same as all other standard-labelled > devices. > > So yes, there is a problem with the device trees and how people build > them, and it requires education on how to properly craft one. I don't > think changing the layout to either be flatter (only using compatible), > or changing names of a property (device_type->class) will help anything > at all. > > I actually prefer keeping device_type myself, since it means existing > OF-based device trees will already have some of the labels. Yeah.. what he said. The *only* substantive change with the "class" proposal is the fact that multiple classes can be specified. That's nice, but I don't think it's worth the trouble of attempting to define a whole new chunk of standard for. Stuart, I think you overestimate the value of this class property to a human reader. The generic names convention (not followed as much as it should be) means the name should give the reader some idea of what the device is, in most cases. For trickier cases, if we really want something for humans reading the tree, we could add an optional "comment" or "description" property with purely human readable information. I think we should leave existing IEEE1275 defined uses of device_type, in order not to make flat trees gratuitously different from real-OF trees, but we should avoid any new use of device_type. Explicitly specifying what device class bindings / conventions the node complies with is cute, but not actually all that useful in practice. If it looks like a "duck" class device node, and it quacks^Whas the properties of a "duck" class device node, it's "duck" class compliant. Or to look at it another way, "class bindings" aren't really bindings, but rather a set of conventions that device bindings for specific devices in that class ought to follow. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message- > From: David Gibson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 7:52 PM > To: Olof Johansson > Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote: > [snip] > > I don't see how switching the property name from "device_type" to > > "class" is going to stop people from misunderstanding it's intended > > use. There's nothing inherently more understandable in calling it > > "class" -- it also invites people to make up their own class names > > as they go along, just as what happened to "device_type". > > > > I also don't understand the people wanting to use "compatible" > > for _everything_. It's just mashing together two separate pieces of > > information into one property, and I seriously don't see > how that helps > > anything or anyone. It's absolutely useless for a driver to > be able to > > bind to a compatible field of "standard,network" or > whatever it might be, > > since there's no way that "standard," will imply that the > register layout > > and programming model is somehow the same as all other > standard-labelled > > devices. > > > > So yes, there is a problem with the device trees and how > people build > > them, and it requires education on how to properly craft > one. I don't > > think changing the layout to either be flatter (only using > compatible), > > or changing names of a property (device_type->class) will > help anything > > at all. > > > > I actually prefer keeping device_type myself, since it > means existing > > OF-based device trees will already have some of the labels. > > Yeah.. what he said. > > The *only* substantive change with the "class" proposal is the fact > that multiple classes can be specified. That's nice, but I don't > think it's worth the trouble of attempting to define a whole new chunk > of standard for. I tend to agree, but I think device_type serves a useful purpose. I don't think we should deprecate it. > Stuart, I think you overestimate the value of this class property to a > human reader. The generic names convention (not followed as much as > it should be) means the name should give the reader some idea of what > the device is, in most cases. For trickier cases, if we really want > something for humans reading the tree, we could add an optional > "comment" or "description" property with purely human readable > information. > > I think we should leave existing IEEE1275 defined uses of device_type, > in order not to make flat trees gratuitously different from real-OF > trees, but we should avoid any new use of device_type. I'm fine with keeping device_type, but there are a few of things I don't like about the 'no new use'. 1. There are types of nodes that don't have a programming inteface per se and thus no compatible. "cpu", "memory", "cache" are 3 that come to mind. What if there is a _new_ class of nodes of this type? What is wrong with a new use of device_type for something say like "i2c"? Conceptually and ideally, what _is_ the right way to represent these types of devices. 2. 'Existing IEEE1275 defined uses' of device_type is actually very vague. There are a conglomeration of old bindings, recommended practices, proposals and it is not clear at all which are useful or not. What are the existing IEEE1275 uses??? I actually went through all the OF documents and there are dozens of device types that have no practical use. Also, many 'real-OF' trees seem to follow no published binding at all. Conceptually, I'd like to a crisp list of 'official' bindings and hope that the current ePAPR work in power.org will establish this list. 3. You're advocating deprecating device_class, but still requiring it for certain node types. So a "network" node is _required_ to have the deprecated device_type="network". But a "i2c" node is required _not_ to have device_type. Long term, I'd like to see any inconsitency be removed. If device_type is deprecated, it's use should be optional in flat device trees. That goes for "cpu", "memory", etc. I think what we should do is keep device_type, including permitting new uses of it in a limited way-- only permitting the us
RE: RFC: replace device_type with new "class" property?
> Explicitly specifying what device class bindings / conventions the > node complies with is cute, but not actually all that useful in > practice. If it looks like a "duck" class device node, and it > quacks^Whas the properties of a "duck" class device node, it's "duck" > class compliant. Don't know how cute it is, but I think it is practically helpful. Take another example: Say you-- a human reader-- see this in a device tree: ... interrupts = ; interrupt-parent = < &mpic >; ... What does the 'b' and '8' mean? You look at the interrupt controller node-- mpic: [EMAIL PROTECTED] { clock-frequency = <0>; interrupt-controller; #address-cells = <0>; #interrupt-cells = <2>; reg = <4 4>; compatible = "fsl,xyz"; big-endian; } Note-- I removed the device_type property and changed compatible somewhat. How are you going to find where the meaning interrupt controller's interrupt cells are defined? What spec will you look at? device_type = "open-pic"; makes it perfectly clear. It's an open-pic type controller and follows that binding. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: > mpic: [EMAIL PROTECTED] { > clock-frequency = <0>; > interrupt-controller; > #address-cells = <0>; > #interrupt-cells = <2>; > reg = <4 4>; > compatible = "fsl,xyz"; > big-endian; > } > > Note-- I removed the device_type property and changed > compatible somewhat. How are you going to find where > the meaning interrupt controller's interrupt cells are > defined? What spec will you look at? The binding for fsl,xyz. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, October 30, 2007 11:34 AM > To: Yoder Stuart-B08248 > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: > > mpic: [EMAIL PROTECTED] { > > clock-frequency = <0>; > > interrupt-controller; > > #address-cells = <0>; > > #interrupt-cells = <2>; > > reg = <4 4>; > > compatible = "fsl,xyz"; > > big-endian; > > } > > > > Note-- I removed the device_type property and changed > > compatible somewhat. How are you going to find where > > the meaning interrupt controller's interrupt cells are > > defined? What spec will you look at? > > The binding for fsl,xyz. Not every string listed in compatible has a spec backing it (or should be required to). You would have to go look at the source code and cross your fingers that the comments were sufficient. Another good reason for device_type-- it helps distinguish between two similar classes of devices. Both "open-pic" and "isa-pic" look very similar but have different encodings of their interrupt cells. Without a device_type it may be difficult or impossible to distinguish them unless the "name" and "compatible" are luckily clear enough. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On 10/30/07, Yoder Stuart-B08248 <[EMAIL PROTECTED]> wrote: > Another good reason for device_type-- it helps > distinguish between two similar classes of devices. > Both "open-pic" and "isa-pic" look very similar but > have different encodings of their interrupt cells. > Without a device_type it may be difficult or impossible > to distinguish them unless the "name" and > "compatible" are luckily clear enough. I don't think you want to go down that path. If your compatible list does not uniquely describe what the device is (followed by a list of devices it is compatible with); then it is not specific enough. It's fine for a device driver to go looking at other properties to get more details; but drivers should primarily bind on the compatible list. In other words; device_type and/or class are a coarser grained description of the device than the compatible list. If you match on compatible; why would there be any need at all to look at 'name', 'device_type' or the proposed 'class' properties? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: > > > Explicitly specifying what device class bindings / conventions the > > node complies with is cute, but not actually all that useful in > > practice. If it looks like a "duck" class device node, and it > > quacks^Whas the properties of a "duck" class device node, it's "duck" > > class compliant. > > Don't know how cute it is, but I think it is practically > helpful. Take another example: > > Say you-- a human reader-- see this in a device > tree: > > ... > interrupts = ; > interrupt-parent = < &mpic >; > ... > > What does the 'b' and '8' mean? You look > at the interrupt controller node-- > > mpic: [EMAIL PROTECTED] { > clock-frequency = <0>; > interrupt-controller; > #address-cells = <0>; > #interrupt-cells = <2>; > reg = <4 4>; > compatible = "fsl,xyz"; > big-endian; > } > > Note-- I removed the device_type property and changed > compatible somewhat. How are you going to find where > the meaning interrupt controller's interrupt cells are > defined? What spec will you look at? > > device_type = "open-pic"; makes it perfectly clear. > It's an open-pic type controller and follows that > binding. That's an extremely contrived example - it only works because for historical reasons the "open-pic" device_type describes a programming model as well as an OF method interface. In general, you always need to look at a node's "compatible" and the binding for that to work out what it's properties mean, or if it's an interrupt controller what the format of its interrupt specifiers is. open-pic is the *only* example I can think of where device_type will tell you this. In fact, "open-pic" really belongs in compatible. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote: > > > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Tuesday, October 30, 2007 11:34 AM > > To: Yoder Stuart-B08248 > > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org > > Subject: Re: RFC: replace device_type with new "class" property? > > > > On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote: > > > mpic: [EMAIL PROTECTED] { > > > clock-frequency = <0>; > > > interrupt-controller; > > > #address-cells = <0>; > > > #interrupt-cells = <2>; > > > reg = <4 4>; > > > compatible = "fsl,xyz"; > > > big-endian; > > > } > > > > > > Note-- I removed the device_type property and changed > > > compatible somewhat. How are you going to find where > > > the meaning interrupt controller's interrupt cells are > > > defined? What spec will you look at? > > > > The binding for fsl,xyz. > > Not every string listed in compatible has a spec > backing it (or should be required to). You would > have to go look at the source code and cross your > fingers that the comments were sufficient. But that's true in general. open-pic is practically the only time device_type will let you avoid that. > Another good reason for device_type-- it helps > distinguish between two similar classes of devices. > Both "open-pic" and "isa-pic" look very similar but > have different encodings of their interrupt cells. > Without a device_type it may be difficult or impossible > to distinguish them unless the "name" and > "compatible" are luckily clear enough. This is a totally misleading argument. There may be one or two cases where the device_type is useful, but in most cases device_type will be either not specific enough to give you the information you need, or it we add lots of new device_type values, it will be so specific that it suffers the same problem as looking at name or compatible - you have to find the finding that goes with a particular device_type. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote: [snip] > > Yeah.. what he said. > > > > The *only* substantive change with the "class" proposal is the fact > > that multiple classes can be specified. That's nice, but I don't > > think it's worth the trouble of attempting to define a whole new chunk > > of standard for. > > I tend to agree, but I think device_type serves a useful > purpose. I don't think we should deprecate it. > > > Stuart, I think you overestimate the value of this class property to a > > human reader. The generic names convention (not followed as much as > > it should be) means the name should give the reader some idea of what > > the device is, in most cases. For trickier cases, if we really want > > something for humans reading the tree, we could add an optional > > "comment" or "description" property with purely human readable > > information. > > > > I think we should leave existing IEEE1275 defined uses of device_type, > > in order not to make flat trees gratuitously different from real-OF > > trees, but we should avoid any new use of device_type. > > I'm fine with keeping device_type, but there are a few > of things I don't like about the 'no new use'. > > 1. There are types of nodes that don't have a programming > inteface per se and thus no compatible. > "cpu", "memory", "cache" are 3 that come to mind. Well, yes, this is why I suggested treating these "fundamental" nodes as a special case in an earlier mail. > What if there is a _new_ class of nodes of this type? > What is wrong with a new use of device_type for something > say like "i2c"? Memory and cpu are pretty clearly special cases - if they're not there, you don't have a computer at all. The programming model for "memory" is always the same", and the programming model for the cpu has to be known before reading the device tree anyway. I don't think we need to worry about new classes of such things - i2c is *certainly* not an example of such. cache is a bit weird, because although there can be different types, the programming model is essentially determined by the cpu to which it is attached, and the nodes for cache are really just to give details of sizes and levels. > Conceptually and ideally, what _is_ the right way to > represent these types of devices. > > 2. 'Existing IEEE1275 defined uses' of device_type is > actually very vague. There are a conglomeration of > old bindings, recommended practices, proposals and > it is not clear at all which are useful or not. What > are the existing IEEE1275 uses??? I actually went > through all the OF documents and there are dozens > of device types that have no practical use. > > Also, many 'real-OF' trees seem to follow no published > binding at all. > > Conceptually, I'd like to a crisp list of 'official' > bindings and hope that the current ePAPR work in > power.org will establish this list. Yeah, sorry, I am being a bit vauge here and we do need to be more specific. My point is that if you take a tree from a real OF, with lots of device_type values representing programming interfaces, then flatten it, it shouldn't be considered "bad" as a flattened tree. It's fine if most or all of the device_type values are optional in the flattened tree, so that it's ok whether or not they're present. > 3. You're advocating deprecating device_class, but still > requiring it for certain node types. So a "network" > node is _required_ to have the deprecated > device_type="network". But a "i2c" node is required > _not_ to have device_type. Long term, I'd like to see > any inconsitency be removed. If device_type is > deprecated, it's use should be optional in flat > device trees. That goes for "cpu", "memory", etc. > > I think what we should do is keep device_type, including > permitting new uses of it in a limited way-- only permitting > the use of device_type when there is an official binding > (like in the power.org ePAPR) defined. That's what I was thinking when we first started defining flat tree bindings. But the more time I've spent thinking about it, and the more time I've spent reviewing people's proposed bindings, the less useful I think it is. The *only* reason I'm suggesting leaving device_type values for IEEE1275 defined classes is so that flat trees written as flat trees look more similar to OF derived trees. > > Explicitly specifying what device class bindings / conventions the > > node complies with is cute, but not actually all that useful in > > practice. If it looks like a "duck" class device node, and it > > quacks^Whas the properties of a "duck" class device node, it's "duck" > > class compliant. > > > > Or to look at it another way, "class bindings" aren't really bindings, > > but rather a set of conventions that device bindings for specific > > devices in that class ought to follow. > > I tend to th
RE: RFC: replace device_type with new "class" property?
> > 1. There are types of nodes that don't have a programming > > inteface per se and thus no compatible. > > "cpu", "memory", "cache" are 3 that come to mind. > > Well, yes, this is why I suggested treating these "fundamental" nodes > as a special case in an earlier mail. Given your statement below, I'm wondering how you think "fundamental" nodes should be represented ideally? > The *only* reason I'm suggesting leaving device_type values for > IEEE1275 defined classes is so that flat trees written as flat trees > look more similar to OF derived trees. So, ideally (without respect to 1275) how should a "cpu" node be represented and identified as a cpu node? Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> > I think what we should do is keep device_type, including > > permitting new uses of it in a limited way-- only permitting > > the use of device_type when there is an official binding > > (like in the power.org ePAPR) defined. > > That's what I was thinking when we first started defining flat tree > bindings. But the more time I've spent thinking about it, and the > more time I've spent reviewing people's proposed bindings, the less > useful I think it is. > > The *only* reason I'm suggesting leaving device_type values for > IEEE1275 defined classes is so that flat trees written as flat trees > look more similar to OF derived trees. > > > > Explicitly specifying what device class bindings / conventions the > > > node complies with is cute, but not actually all that useful in > > > practice. If it looks like a "duck" class device node, and it > > > quacks^Whas the properties of a "duck" class device node, > it's "duck" > > > class compliant. > > > > > > Or to look at it another way, "class bindings" aren't > really bindings, > > > but rather a set of conventions that device bindings for specific > > > devices in that class ought to follow. > > > > I tend to think of a 'binding' as a 'set of conventions'. > > Well, whatever. My point is that conventions are most flexible if you > don't have to explicitly announce that you're following them - you > just go ahead and follow as many conventions as make sense for your > device. Let me repeat what I think you are advocating-- we should treat the collection of properties for 'established' device classes like like "network", "serial", etc as a set of useful conventions. That is, there are no set of _required_ properties per se, but the device tree creator picks from the established properties plus supplementing with "company,xyz" properties in whatever way they think makes sense for them. This works...but certainly is weaker with respect to standardization. My previous argument had the assumption that something like "mac-address" in a network node was _required_, and thus needed a class id of some sort to tie the standardized node to. If we relax things so there are no required properties for device nodes, then I agree that a device class property has limited or no value. However, maybe we do want to keep device_type in a very limited way to define requirements for what you call 'fundamental' types of nodes. It may be that certain properties in a "cpu" node (like cache-size?) should be _required_ so that an OS that consumes the device tree can really count on certain properties being there. Or, I guess we could use "compatible" for that...? Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote: > This works...but certainly is weaker with respect to > standardization. My previous argument had the assumption > that something like "mac-address" in a network node was > _required_, and thus needed a class id of some sort to tie > the standardized node to. It is certainly not required -- the device could have an eeprom, or it might not be ethernet at all. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new "class" property?
> -Original Message- > From: Wood Scott-B07421 > Sent: Wednesday, October 31, 2007 12:06 PM > To: Yoder Stuart-B08248 > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org > Subject: Re: RFC: replace device_type with new "class" property? > > On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote: > > This works...but certainly is weaker with respect to > > standardization. My previous argument had the assumption > > that something like "mac-address" in a network node was > > _required_, and thus needed a class id of some sort to tie > > the standardized node to. > > It is certainly not required -- the device could have an > eeprom, or it might > not be ethernet at all. Fine, I picked a bad example. My point was that if a property was _required_ that it should have a class id of some sort that ties it back to the standard that required it. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: replace device_type with new "class" property?
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote: > > > > I think what we should do is keep device_type, including > > > permitting new uses of it in a limited way-- only permitting > > > the use of device_type when there is an official binding > > > (like in the power.org ePAPR) defined. > > > > That's what I was thinking when we first started defining flat tree > > bindings. But the more time I've spent thinking about it, and the > > more time I've spent reviewing people's proposed bindings, the less > > useful I think it is. > > > > The *only* reason I'm suggesting leaving device_type values for > > IEEE1275 defined classes is so that flat trees written as flat trees > > look more similar to OF derived trees. > > > > > > Explicitly specifying what device class bindings / conventions the > > > > node complies with is cute, but not actually all that useful in > > > > practice. If it looks like a "duck" class device node, and it > > > > quacks^Whas the properties of a "duck" class device node, > > it's "duck" > > > > class compliant. > > > > > > > > Or to look at it another way, "class bindings" aren't > > really bindings, > > > > but rather a set of conventions that device bindings for specific > > > > devices in that class ought to follow. > > > > > > I tend to think of a 'binding' as a 'set of conventions'. > > > > Well, whatever. My point is that conventions are most flexible if you > > don't have to explicitly announce that you're following them - you > > just go ahead and follow as many conventions as make sense for your > > device. > > Let me repeat what I think you are advocating-- we should > treat the collection of properties for 'established' device > classes like like "network", "serial", etc as a set of useful > conventions. That is, there are no set of _required_ properties > per se, but the device tree creator picks from the established > properties plus supplementing with "company,xyz" properties > in whatever way they think makes sense for them. Not the device tree creater, the device binding creator (though for "one-off" type devices those may be the same person). > This works...but certainly is weaker with respect to > standardization. My previous argument had the assumption > that something like "mac-address" in a network node was > _required_, and thus needed a class id of some sort to tie > the standardized node to. Not for a network device type that represented a point-to-point link.. (Well, technically most nodes should lack 'mac-address', but I think 'local-mac-address' is what you meant) > If we relax things so there are no required properties for > device nodes, then I agree that a device class property > has limited or no value. There are required properties, but the requrements are done at the device binding (i.e. compatible property) level. Those bindings might in turn reference class requirements ("A foobaz-ethernet node must have all the standard properties for a network node described in Sx.y.z, and in addition must have foobaz,frobnication-quotient"). > However, maybe we do want to keep device_type in > a very limited way to define requirements for what you > call 'fundamental' types of nodes. It may be that certain > properties in a "cpu" node (like cache-size?) should be > _required_ so that an OS that consumes the device tree > can really count on certain properties being there. Or, > I guess we could use "compatible" for that...? No, I'm saying keep device_type for cpu and memory - we could do otherwise but it would be a gratuitous divergence from OF trees. And yes they should have their required properties, too. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev