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

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

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

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.

Cheers,
Ben.