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?
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 = b 8;
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 = b 8;
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 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
RFC: replace device_type with new class property?
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. One other point-- the intent of a device class is not necessarily to specify a sufficient set of properties to implement drivers. The network class would have a base set of required properties (e.g. mac-address,etc), but most likely would need additional properties to implement a driver for a specific device. The value in the class is when a developer needs to represent a new device that fits into an existing class he has a base set of properties to start with that has had some good thinking put into defining it. A device class would facilitate and encourage consistent use of properties names, which would be a good thing. 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? Stuart Yoder Freescale Semiconductor, Inc. ___ 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: 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?
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 code etc. gives you an identical match. Why not; chickenlittle
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 to go from parsing pci or usb device_types name/compatible, not device_type. Please actually read the PCI binding. And you
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
