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

[Scott Wood <scottwood@freescale.com>]

Russell King wrote:
> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>> Russell King wrote:
>>> No one has brought that up on the ARM mailing lists - so does this issue
>>> really exist?  All of the stuff I see on the ARM lists seems to be well
>>> behaved and following our existing model - even vendor stuff (supplied
>>> to me under NDA) seems to generally get this kind of stuff right.
>> I'm just going by what I've seen on the u-boot list lately.  What is the  
>> existing ARM Linux model for passing MAC addresses, so that we can point  
>> people to that when they try to get u-boot to do silly things?
> 
> To program them into the hardware registers, 

Isn't that adding a requirement to the boot firmware?  I thought you 
didn't like that? :-)

The patches that were proposed (and NACKed) in u-boot did exactly this 
-- except supposedly they would only set the MAC address if the 
interface were actually used prior to booting the kernel.

> which is not what we in the ARM community say, but it's what the
> _network_ guys tell people they should be doing.

They don't seem to be NACKing drivers that get it from the device tree 
instead.

> I've suggested in the past having a standard kernel parameter such
> that you can specify a mac address on a per-device basis in a totally
> platform independent way, but the network folk don't like that idea.

How do you reliably associate MAC addresses with specific devices that 
way?  The device tree can do this.

Think of the device tree as a really expressive kernel command line 
argument. :-)

>> I'm not talking about platform specific code, I'm talking about code to  
>> retrieve information about a device from the device tree.  There would  
>> not be separate instances of this for "platforms X, Y and Z", just one  
>> of_platform binding in each driver.  It's no different than having a  
>> platform bus binding, except in the data structures used.
> 
> I really don't see what OF buys us then,

The data is in a key/value format rather than a C struct, which makes it 
easier to pass from entities outside the kernel *if you want to*.

It is this distinction that led to the platfom/of_platform split -- we 
can't turn key/value into C structs without glue code that knows the 
specific device binding, and it's easier for the driver to access that 
data directly.

>> The device tree is quite capable of expressing information beyond  
>> addresses and interrupts.
> 
> Bus width?  Register offset spacing?  SMC LED configuration?  Whether
> to use the hardware wait signal from the SMC?
> 
> If you're going to say yes to all that,

Sure, you can add properties for that stuff.

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

Device nodes have "compatible" properties indicating what the hardware 
is compatible with.  A given driver only binds to nodes for hardware 
that is compatible with what it knows how to drive.

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

Yes, there's a device tree compiler.  It doesn't know the details of 
individual device bindings, which is a little less safe than C structs, 
but not much.  There's nothing in theory preventing the compiler from 
being given this knowledge, and doing checks beyond what the C compiler 
can do.

> If not, I can see no way for OF trees to ever be safe and correct.

Code reviews and testing, same as how you get C code to be correct.

-Scott