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:	Thu, 28 May 2009 12:57:18 +1000
From:	David Gibson <david@...son.dropbear.id.au>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	Scott Wood <scottwood@...escale.com>,
	devicetree-discuss <devicetree-discuss@...abs.org>,
	linux-kernel@...r.kernel.org, Timur Tabi <timur@...escale.com>,
	Janboe Ye <yuan-bo.ye@...orola.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, May 28, 2009 at 02:07:07AM +0200, Robert Schwebel 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.

It's true that going to a device tree model does take quite a bit of
time and effort to get up to speed.  As Grant said, we've made quite a
few errors along the way on powerpc, as people experimented with the
unfamiliar idea.  Along the way a lot of people complained about how
we were much better off without the device tree.

However, I think nowadays, with most of the community at least roughly
up to speed on device tree conventions, and the worst mistakes over, a
lot of people who doubted the value of the device tree approach are
coming around.

Grant mentions the Xilinx devices as an example - they're interesting
because of the fancy stuff they're doing, autogenerating the devtree
from the FPGA configuration.  But to me the real indicator of the
device tree's value is the handful of platforms for which support has
been added with *only* a new dts - a single, fairly simple text file.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
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/