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

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

On Wed, 2014-05-07 at 12:05 +0100, David Woodhouse wrote:
> On Mon, 2014-05-05 at 18:39 +1000, Benjamin Herrenschmidt wrote:
> > 
> > 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 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.

Fair enough. I was mostly putting all options on the table. It is still
not completely clear on my mind how we'll get the properties from ACPI
(via that new scheme Darren's working on ?) and how good we'll manage to
keep the bindings in sync sufficiently to avoid a bunch of:

	if (OF)
		get_property("foo"...)
	else
		get_property("bar"...)

Because of subtle differences in property names, format, content, etc...

It might end up working out ... but it's going to be a constant battle
at least initially.

I'm mostly concerned here about device specific random attributes. I
think we all agree that the "common" stuff such as memory and irq is
going to be translated by the core into Linux native representation.

Of course there is going to be a pile of work defining the right
representation & translation for some of that "common" stuff in areas
like clocks, gpios, etc...

Cheers,
Ben.