Best practice for compatible strings?

[Dave Martin]

On Thu, Nov 17, 2011 at 08:46:04AM -1000, Mitch Bradley wrote:
> As the original instigator of the generic names scheme, I can tell
> you what I had in mind.  That may not be the way things have
> evolved, but at least it's a data point.
> 
> The idea is that there are devices for which there are preexisting
> drivers.  Hardware designers often design new hardware that is
> compatible with older hardware so that the old driver can be used.
> The new hardware often has additional features that can be used with
> new drivers, but at least the device is basically functional with
> the old driver.
> 
> The point of a non-specific fallback entry in a compatible property
> is to match an old driver that is known to be present in some
> important extant version of an OS.
> 
> In the absence of a preexisting legacy programming model and the
> corresponding old driver, there isn't much point in trying to
> "invent" a non-specific name.  I suppose that, theoretically, it
> might be possible to come up with a least-common-denominator
> programming model across a family of newly-designed devices, but
> that's not the way it usually works in practice, except in the case
> of a programming model defined by a standards committee.  More
> typically, a particular device gets some traction in the market, and
> then people copy that.
> 
> This model of driver evolution is more compelling for operating
> systems with a different development and distribution model than
> Linux's.  In the Linux world, it is hard to point to a specific
> shipping version and say "we must be compatible with that because it
> is what is already out there".
> 
> The bottom line:  In my opinion, if there is no preexisting driver
> that you can't change, there is little need for a non-specific name
> in the compatible list.

I think that answers my question -- in the absence of preexisting
drivers, a DT node would list the one compatible string exactly
identifying the device, and drivers list the compatible strings for
the devices they are known to support.

More generic compatible strings may be useful sometimes, but we
probably shouldn't have them by default when defining new bindings,
unless there's a compelling reason for it.

Does anyone feel uncomfortable with that?

Cheers
---Dave