Re: Best practice for compatible strings?

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