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 21:29:26 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	Scott Wood <scottwood@...escale.com>,
	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 6:07 PM, Robert Schwebel
<r.schwebel@...gutronix.de> wrote:
> 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.

Personally, I attribute a lot of that in powerpc land to the fact that
we had no clue what we were doing when we started the process of
porting all powerpc platforms to use the device tree.  It was hard.
It was painful.  We didn't have much established convention to learn
from.  However, now that it is complete I would say that it has been a
net-win and it is now simpler to bring up new boards and SoCs than it
ever was before.

Now we do know what we are doing and it should never cause that level
of pain again.

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/