[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090527205218.GA5591@sirena.org.uk>
Date: Wed, 27 May 2009 21:52:23 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Russell King <rmk+lkml@....linux.org.uk>
Cc: Scott Wood <scottwood@...escale.com>,
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
On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
> > 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, apart from additional dependencies
> that have to be correct for the kernel to work. I can only see disadvantages
> if all OF is, is a way to pass some file to the kernel to (effectively) tell
> it which drivers to use.
The main selling points of the device tree AFAICT are that some
platforms have to use it it anyway due to the native OS and firmware for
the platform use it, the possibility of using the same device tree with
more than one OS (modulo unrepresentable holes) and the fact that some
people find it more convenient to use than straight data tables
(personally I find the two approaches to be much of a muchness there).
Perhaps I'm missing something, though?
--
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