Re: Revisited, audio codec device tree entries.

[David Gibson <david@gibson.dropbear.id.au>]

On Mon, Nov 19, 2007 at 01:48:40PM +0100, Segher Boessenkool wrote:
> > 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).

Sorry, that was an (over?) simplification on my part.  Yes, there are
conventions as to what devices should be called by class (usually, but
not universally observed), yes they can be used machine-readable under
some circumstances.

My point is that since driver matching is *not* done off name, and
machine-readable uses are not common, the name tends not to matter
very much.  Plus if an incorrect name is used, it's usually not too
bad to fix.

> > device_type - indicates the open firmware method interface for the
> > device.
> 
> Not "method interface", just "interface".

Right, I say "method interface" just to emphasise the fact that we're
talking about the runtime OF-call interface, rather than
register-level or other programming 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).

Uh... it was you who convinced me that device_type was not appropriate
for new flat-tree devices.
 
> > 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.

Well, yes, if the need for the workaround is known when the device
tree is created.  But by their nature workarounds tend not to be
planned, so from the driver's perspective it's legitimate to use *any*
reliable-in-practice information to activate a workaround (even if
it's not reliable in theory, if there's no other option).  That
includes both everything in the device tree, and any information the
driver can probe from the hardware.

My point above is that iIt's reasonably common in such cases for
"model" to be a decent choice.

-- 
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