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]

Message-ID: <fa686aa40905271052k3f55eb73k2cb0c3cff3c94d7b@mail.gmail.com>
Date:	Wed, 27 May 2009 11:52:50 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org, jwboyer@...ux.vnet.ibm.com,
	paulus@...ba.org,
	devicetree-discuss <devicetree-discuss@...abs.org>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Wed, May 27, 2009 at 11:44 AM, Russell King
<rmk+lkml@....linux.org.uk> wrote:
> (For whatever reason, I don't have the initial email on this.)
>
> On Wed, May 27, 2009 at 08:27:10AM -0600, Grant Likely wrote:
>> On Wed, May 27, 2009 at 1:08 AM, Janboe Ye <yuan-bo.ye@...orola.com> wrote:
>> > Hi, All
>> >
>> > Currently, ARM linux uses mach-type to figure out platform. But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals.
>> >
>> > The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code.
>> >
>> > Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware , for the detail of device tree.
>> >
>> > www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
>> >
>> > Signed-off-by: janboe <yuan-bo.ye@...orola.com>
>>
>> Heeheehe, This is Fantastic.  I'm actually working on this too.  Would
>> you like to join our efforts?
>
> My position is that I don't like this approach.  We have _enough_ of a
> problem getting boot loaders to do stuff they should be doing on ARM
> platforms, that handing them the ability to define a whole device tree
> is just insanely stupid.

The point of this approach is that the device tree is *not* create by
firmware.  Firmware can pass it in if it is convenient to do so, (ie;
the device tree blob stored in flash as a separate image) but it
doesn't have to be and it is not 'owned' by firmware.

It is also true that there is the option for firmware to manipulate
the .dts, but once again it is not required and it does not replace
the existing ATAGs.

If a board port does get the device tree wrong; no big deal, we just
fix it and ship it with the next kernel.

> The end story is that as far as machine developers are concerned, a
> boot loader, once programmed into the device, is immutable.  They never
> _ever_ want to change it, period.

I agree 100%.

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/