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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Monday, May 05, 2014 06:39:16 PM Benjamin Herrenschmidt wrote:
> 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.

Precisely.

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

Probably.

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

It may be workable from an individual driver point of view, but not from
a framework perspective.  At least duplication of code has to be avoided.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.