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

[Darren Vincent Hart]

On Wed, 2014-05-14 at 14:06 +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 14:14:42 Olof Johansson wrote:
> > On Tue, May 06, 2014 at 03:35:41PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 06 May 2014 14:18:56 Rafael J. Wysocki wrote:
> > > 
> > > We should definitely be able to have an interface like this for
> > > ACPI, but you don't have a 'struct device_node' pointer then.
> > > We can add a new
> > > 
> > > bool dev_property_read_bool(const struct device *dev,
> > >                             const char *propname);
> > 
> > > 
> > > that handles both, but then you have to change every driver
> > > that is already using of_property_read_bool() and that can
> > > get used with ACPI.
> > 
> > It's actually not that easy in practice. There's not a one-to-one
> > correspondence between device tree nodes and struct devices in the
> > kernel. There are many bindings that use subnodes for sections of their
> > information, and so on.
> 
> I also don't think we can have a grand unified solution to the general
> problem, but doing the above would solve a lot of individual problems
> for all the simple drivers that don't use sub-nodes in DT.
> 
> I really don't see any downsides to using a common named property
> API for simple values in drivers that can.
> 
> Devices with sub-nodes are by definition complex to handle, and
> I think we will always have cases that are too complex to use
> a common interface. At the moment, we can share drivers that
> have only memory and irq resources, which is a significant share
> already. We can over time extend this to drivers that use strings,
> booleans, integers, or arrays of those. We can also extend it
> for things like gpios and dma-channels (both of which partly work
> already but are limited when it comes to naming) and a few other
> things.


Agreed, well said.


-- 
Darren Hart
Intel Open Source Technology Center