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

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

On Sun, 2014-05-04 at 10:18 -0700, Olof Johansson wrote:
> 
> Also, even if we do a common API with different backends, there will
> need to be some knowledge somewhere about custom bindings and what they mean,
> how to translate them and how the different descriptions correlate.
> I personally think we're best off putting that in the drivers, instead of
> making some part of the driver core aware of a bunch of quirks/hooks for
> various devices.

I tend to agree.

In the end, there is no silver bullet, however, it would make things easier
of the drivers could be structured such that for most things, when they need
a piece of information they use a single accessor to get named properties,
and if needed, they can have a single conversion function that converts ACPI
"stuff" into these (provided the ACPI extension for passing properties isn't
present, or possibly for translating "keys" between the bindings etc...).

IE. A single point of translation is less messy imho than sprinkling things
all over the driver, and we *will* need translation.

Now for standard stuff such as MMIO ranges etc... we all agree I believe to
stick to the existing Linux struct resource & co and have the parsing happen
at the core level, but for everything else, the trick is to see what we can
do to make driver life easier.

They *will* have to deal with the dual world, we can't completely hide it,
but we can make it less painful via good practices.

The other option is to have both the DT representation and the ACPI
representation reach the drivers and leave it to the them (the drivers) to get
through two different functions at probe time to "translates" that into a
"3rd" driver private one (a structure, in a way akin to the old platform data
but of course completely local to the driver scope).

I know of the drawbacks but for many drivers who already just pick these
things up at probe time just to copy/encode them into their driver private
structure, that's a fairly workable and simple approach.

Cheers,
Ben.