Date:	Wed, 27 May 2009 14:08:42 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Russell King <rmk+lkml@....linux.org.uk>
CC:	Peter Korsgaard <jacmet@...site.dk>,
	Robert Schwebel <r.schwebel@...gutronix.de>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

Russell King wrote:
> On Wed, May 27, 2009 at 11:23:29AM -0500, Scott Wood wrote:
>> That removes the ability to use the device tree to pass information from  
>> the bootloader, such as MAC addresses and clock frequencies.  On the  
>> u-boot list, you'll find people trying such hacks (which were rightly  
>> NACKed) as passing the information in the device's volatile registers  
>> (which the Linux driver must then not reset) to deal with ARM Linux's  
>> lack of this ability.
> 
> 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?

>>>  Robert> - The oftree layering is fundamentally broken. We already
>>>  Robert> have a sane abstraction for arbitrary hardware in the kernel:
>>>  Robert> platform devices.  Why not instanciate platform devices from
>>>  Robert> a generic oftree core?
>> You can, if you want.  But you'll need extra glue code that understands  
>> the individual bindings.  IMHO that logic is usually better off in the  
>> driver itself, but if you really need platform code to involve itself in  
>> some way (such as providing callbacks), then exceptions can be made.
> 
> No it is not.  Device drivers are best written to support devices, and
> the platform specific code should not be anywhere near them.  Platform
> specific code to handle oddities of platforms should be totally separate
> from the device driver itself.

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.

But to restate, having external glue to create platform devices from the 
device tree is fine if that's what you want to do.  We used to do that, 
but it was a pain compared to keeping everything in one place.  Your 
experience may differ.

> smc91x is a prime example of the kind of information drivers need - base
> address and irq are very much insufficient to describe how this device is
> connected.  There's much more information required to specify this device
> fully, and throwing it into the driver doesn't work.  We've been there
> and proven that point.

The device tree is quite capable of expressing information beyond 
addresses and interrupts.

-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists