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

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

On Wed, 2009-05-27 at 20:29 +0100, Russell King wrote:
> 
> 
> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?

Yes. Anything. Basically just a bunch of named properties with
arbitrary content in the nodes for the various devices.
  
> If you're going to say yes to all that, I'm going to start asking how
> you cope with verifying that the data for ethernet driver A doesn't
> get accidentally used for ethernet driver B.

I'm not sure about the question. If it's about identifying which
instance of a device is using the data, it's basically easy since
you used that device-node to create the device in the kernel in
the first place, so you just stick that node pointer into the
achdata as we do on powerpc and can use it to retrieve all the
properties.

If you are talking about different drivers for the same device,
well we try to define bindings such that they describe the hardware
itself in a way that is reasonably agnostic to whatever driver will be
used... 

> I assume you have some kind of compiler, which needs a set of
> specification files to tell it what's required for each driver which
> is OF compatible. If not, I can see no way for OF trees to ever be
> safe and correct.

No, the format at boot time is a flattened tree of nodes with arbitrary
named nodes containing other nodes and named properties (names are
ASCII) and properties have arbitrary binary content.

_Bindings_ define what to put in these things for various bus and device
types, and we do have a compiler, dtc, that goes from a C-like textual
representation and generates the blob.

It makes it easy to create properties that contains strings, numbers,
phandles (references to other nodes), etc...

Cheers,
Ben.