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: <20090528114408.GA11285@game.jcrosoft.org>
Date:	Thu, 28 May 2009 13:44:08 +0200
From:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	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 10:15 Thu 28 May     , Russell King - ARM Linux wrote:
> On Thu, May 28, 2009 at 05:37:16PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-05-27 at 18:56 +0100, Russell King wrote:
> > > 
> > > smc91x is a prime example of the kind of information drivers need - base
> > > address and irq are very much insufficient to describe how this device is
> > > connected.  There's much more information required to specify this device
> > > fully, and throwing it into the driver doesn't work.  We've been there
> > > and proven that point.
> > 
> > The device-tree is a very nice and convenient way to convey all the
> > informations the driver need straight to the driver without any platform
> > code in the middle :-)
> 
> I'm still uncertain whether that's actually a true statement.  For some
> cases, of course it's true, but I have a nasty suspicion that we have
> corner cases where OF won't cope well with.
> 
> As I see it, if we were to convert to OF, we're boxing ourselves in to
> a corner that would be extremely difficult to get out of.  We would
> never be able to step back from OF.  Lets take an example.  If we were
> to convert PXA to OF including all the PXA SoC drivers, and a board
> configuration came along which required hacks to a driver.  Later on
> we find that most platform authors are applying similar hacks because
> their hardware is subtly different but those differences can't be
> expressed via OF.  At this point, what do we do?  We can't say "well,
> OF doesn't work well on this platform, we want to get rid of it" that
> would be extremely difficult to impossible to do.
One of the really nice ability is to allow to simplify AMP support
by defining one device tree for each core where each kernel will use nealy the same
kernel. As done by Kumar for the mpc8572ds.

You can found here the boot procedure and kernel option
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=blob;f=doc/README.mpc8572ds;h=06dab596bea52ab8d8c2ba89d86f793cc4881ccb;hb=HEAD

Best Regards,
J.
--
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/