RFC: replace device_type with new "class" property?

[David Gibson]

On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +0000, 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