linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 May 2009 15:05:58 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Russell King <rmk+lkml@....linux.org.uk>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Timur Tabi <timur@...escale.com>,
	Scott Wood <scottwood@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 2:52 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> 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?

Here are some that I've find useful:

There is the advantage that it decouples the machine description from
the kernel code, which in turn seems to encourage code reuse.  There
has been a significant decrease in the amount of platform specific
code in powerpc since the switch to FDT booting.

There is the advantage of easy multiplatform support.  I regularly
build a single kernel image which boots on all my MPC5200 boards, and
on my MPC83xx boards.  Because the machine description is a separate
image blob, and not hard compiled into the kernel, the kernel doesn't
have to be explicitly told what boards it may possibly be booted on
(other than turning on the appropriate drivers; handled with modules,
just like on x86).  It may not be much of an advantage for current
deployed systems, but it is a huge win during development and
testing....

That being said, I've been told that Motorola has shipped phones with
FDT support in the kernel for exactly the reason of booting a single
kernel image on multiple versions of the device.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/