[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090528000707.GR6805@pengutronix.de>
Date: Thu, 28 May 2009 02:07:07 +0200
From: Robert Schwebel <r.schwebel@...gutronix.de>
To: Scott Wood <scottwood@...escale.com>
Cc: Robert Schwebel <r.schwebel@...gutronix.de>,
Grant Likely <grant.likely@...retlab.ca>,
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>, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
On Wed, May 27, 2009 at 06:58:24PM -0500, Scott Wood wrote:
> Robert Schwebel wrote:
>> The oftree by design wants to be a complete hardware description. As
>> you mention above, there are cases where you *nevertheless* need
>> ad-hoc information about things *not* encoded into the device tree.
>>
>> This renders the whole concept ad absurdum. You need a machine number
>> again - and if you need that: why not stay with the ARM model, define
>> everything with platform data and avoid the whole thing?
>
> Because it's better to have a little platform specific code than a lot
> of it?
Until now, oftree has created more problems than it has solved for us.
The idea works fine for well-known things like memory maps and
interrupts. It works badly for corner cases, and embedded land is full
of it. The effort to get the oftree stuff right is often more than a
magnitude of order higher than the effort for the actual functionality.
That should be an alarm sign that something is wrong.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
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