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: <1243588080.17903.52.camel@pasglop>
Date:	Fri, 29 May 2009 19:08:00 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	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 Fri, 2009-05-29 at 09:52 +0200, Sascha Hauer wrote:
> 
> I don't mean bloated in terms of kbytes but bloated in terms of complex
> code used to parse the device tree. I more than once put information in
> the device tree and wondered where this information got lost on the way
> to the driver where I wanted to use it. Back on ARM I was very happy to
> just have a simple board file which is easier for me to understand and
> maintain.
> Of course this can be solved with /me learning more about the device
> tree, that's why I said 'for my taste'.

Well, the code to walk it is trivial since once 'expanded' we reproduce
the tree structure with pointers.

Now, the problem indeed is how do you get to your node from a driver,
and that's where we are making things easy on powerpc by sticking the
node pointer in the struct device itself.

Of course that needs to be populated properly. We have code in PCI to do
it that would need to be ported over for PCI stuff (but I recommend
waiting a bit as this code is currently different on ppc32 and ppc64, a
bit messy, and Kumar is currently working on cleaning that up and
unifying it), and when device are discovered and instanciated from the
DT in the first place, then this is naturally populated.

So I don't think this is a big issue, and the amount of code involved is
relatively small and self contained.

Cheers,
Ben.

--
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/