linux-kernel - Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.

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:	Tue, 19 Mar 2013 13:51:01 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	David Gibson <david@...son.dropbear.id.au>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>, Jon Loeliger <jdl@....com>,
	Tony Lindgren <tony@...mide.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Benoit Cousson <b-cousson@...com>,
	Mitch Bradley <wmb@...mworks.com>,
	Alan Tull <atull@...era.com>, linux-omap@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, Matt Porter <mporter@...com>,
	Russ Dill <Russ.Dill@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Joel A Fernandes <agnel.joel@...il.com>,
	Rob Clark <robdclark@...il.com>,
	Jason Kridner <jkridner@...gleboard.org>,
	Matt Ranostay <mranostay@...il.com>
Subject: Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.

Hi Grant,

On Mar 16, 2013, at 11:24 AM, Grant Likely wrote:

> On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou <panto@...oniou-consulting.com> wrote:
>> Hi David,
>> 
>> On Jan 23, 2013, at 6:40 AM, David Gibson wrote:
>>> Ok.  Nonetheless it's not hard to avoid a recursive approach here.
>> 
>> How can I find the maximum phandle value of a subtree without using recursion.
>> Note that the whole function is just 6 lines long.
> 
> It's a failure in the existing kernel DT data structures. We need a hash
> lookup for the phandles to eliminate the search entirely. Then you'd be
> able to allocated new phandles on the fly easily and resolve phandles
> without searching the whole tree (which has always been horrible).
> 

Yes, it is pretty obvious that the in-kernel data structures are sub-optimal.
But I was not after modifying them, since that's a different kind of problem.

Since we're having a 'sub-optimal' data structures, I'd like to point out that
the usage of of_find_by_name(), mostly by drivers trying to find a child
of their own node, works by a lucky accident of how the device nodes are instantiated
by the flat tree loader. Most of the use cases should be replaced by a call
to of_get_child_by_name() which does the right thing.

> That said, I'd like to punt on the whole phandle resolution thing. The
> DT overlay support can be merged without the phandle resolution support
> if the core rejects any overlays with phandle collisions.
> 


Fair enough, but be warned that phandle resolution the overlay feature is mostly useless.

In actual practice the amount of driver nodes that can be overlaid without a single case
of referencing phandles outside (or within) their own blob is close to zero.

> g.

Regards

-- Pantelis

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