Re: [RFC] [PATCH] Device Tree on ARM platform

From: Benjamin Herrenschmidt
Date: Thu May 28 2009 - 18:22:36 EST

On Thu, 2009-05-28 at 08:13 -0600, Grant Likely wrote:
> Two nodes are used to describe the device and a "phandle" is used to
> link them. A device driver probe could be triggered (bind) against
> the i2c half of the device and follow the phandle to get the rest of
> the description.

One thing I wouldn't do though is to put "phandle" in the property
name :-) Just call it spi-interface.

Now, that's an option. And it works to a certain extent. But I do
understand the need in general to provide "methods". It's something
we don't solve (but then we don't make it worse than it was before).

I think the cleanest option might be named methods in the device-tree
for example, a device can have an "enable-method" property and a
"clock-method" property. The names would use the usual convention
of "manuf,name" to avoid clashes and could be registered by the

Now, it -does- somewhat deviates from the moto that the DT should
only contain OS agnostic HW representations, but appart for having
a full blown OF with actual method calls in each nodes I don't
see a nicer way at this stage.

Now, the methods could then take "informations" from the target DT.

For example, one could have a generic "simple-gpio-enable" method that
can be used as "enable-method" anywhere, as long as the target device
contains also a "enable-gpio" property that points to the actual GPIO
(and maybe an "enable-delay" while at it).

IE. We can provide a collection of "simple" methods that handle
the easy cases in library code.

I'm very much against putting actual function pointers in the tree
though as Jon Smirl proposed.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at