Re: [Ksummit-discuss] [TECH TOPIC] Driver model/resources, ACPI, DT, etc (sigh)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2014-05-05 at 13:32 +0200, Rafael J. Wysocki wrote:
> The interpretation - yes, the translation - not necessarily.  By putting
> the translation part into drivers we'll duplicate a lot of code used for
> that.  In my opinion there needs to be a layer doing the translation
> automatically.

I'm afraid I don't understand. How can you do the translation
automatically if you have fundamentally different representation of
device-specific concepts ?

> > Also if the bindings evolve, you just created a 3rd way dependency.
> > Instead of just having to deal with DT/ACPI binding version vs. driver
> > version, we now have to also handle quirk versioning.
> 
> The bindings should not depend on the translation.  In the end the bindings
> are what the driver will ask for.  If it asks for an integer property called
> "fred", for example, it should get that property from the upper layer
> regardless of the firmware interface used on that platform (if the property
> is there, of course).

Except that the DT will have something like ibm,fred as a 32-bit cell
and ACPI will have it named subtly differently in a different format and
thing will not be consistent accross devices, bindings or even FW
variants.

> Otherwise every driver has to know about all of the possible firmware interfaces
> that can be used with it and may I call that suboptimal?

Well as I said, it depends what we are talking about here. For well
defined resources such as MMIO regions, interrupts, and we might
possibly manage to classify things like GPIO, etc... in that bucket, yes
we can most definitely find a common ground.

However in that case it's less likely to be a "translation" from one
representation to another than it is to be the core interpreting both
representation and turning them into something linux specific such as
struct resource or higher level representations of linkage between
subsystems.

But then there's everything else ... The various device specific
properties which *are* going to be represented differently left right
and center, the buggy firmwares with bad ACPI tables or bad device-tree,
the representation for some new linkage to a subsytem that doesn't have
stable bindings yet, etc...

In the end, it's an evolutionary process. That stuff starts in the
drivers. If enough drivers do the same thing for a given category of
"properties" (in the generic meaning of the word, not specifically a
device-tree prop), then we can move that part into the core, either in
the form of helpers, or pre-parsing into some new type of struct
resource or whatever else match.

It's time and experience that will tell us what works. There is only so
much we can "design" for when what we're going to deal with is vendor
firwmare mostly developed behind closed doors.

>   With two of them on
> the table it would be workable I guess, but what if someone invents a *third*
> firmware interface to use with device drivers?  Are we going to change all of
> them, then?

Yes. Though the odds of that happening are fairly low at this point.

Ben.