Revisited, audio codec device tree entries.

[Segher Boessenkool]

> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree.  Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).

It is not arbitrary, there is a single well-defined name for every 
common
"class" of device.  It _is_ machine-readable (but shouldn't be used for
driver matching, indeed -- it says nothing about the programming model).

> device_type - indicates the open firmware method interface for the
> device.

Not "method interface", just "interface".

> Therefore, meaningless in flattened trees.

Even in flat trees, a "device_type" of for example "block" indicates the
node will have the required properties for that device type, for example
"block-size".  Such properties are perfectly useful.  OTOH, it isn't 
very
useful to search for device with a specific device type from within the
kernel, since it currently has no firmware interaction to speak of (flat
trees don't interact, and the kernel kills "real" OF dead as soon as
possible).

> No new driver should use this.

Not without very good rationalisation, anyway.

> compatible - *this* is the one for driver selection.  It describes the
> hardware level interface(s) of the device.
>
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware.  It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs.  However, you should never aim to use it
> this way in design.

Yeah.  Any non-workaround value a driver would derive from "model" is
usually better described using a separate property.


Segher