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

Rafael J. Wysocki rjw at rjwysocki.net
Wed May 7 13:06:00 UTC 2014


On Wednesday, May 07, 2014 12:05:02 PM David Woodhouse wrote:
> 
> --===============1197259587839153410==
> Content-Type: multipart/signed; micalg="sha-1"; protocol="application/x-pkcs7-signature";
> 	boundary="=-0RE4bWH9BSP3Smq+x4xP"
> 
> 
> --=-0RE4bWH9BSP3Smq+x4xP
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> >=20
> > 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) t=
> o 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 don't like that much. For "leaf-node" device drivers, I think we're
> better off with a simple set of "device_get_property" functions which
> are a little more type-safe than the existing of_* ones, thus helping us
> to deal with the details of 32-bit cells vs. ACPI integers, etc.

I agree.


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


More information about the Ksummit-discuss mailing list