Messages in this thread | | | Subject | Re: [PATCH 5/6] OF: Introduce Device Tree resolve support. | From | Pantelis Antoniou <> | Date | Tue, 19 Mar 2013 13:51:01 +0200 |
| |
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@antoniou-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
| |