linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Nov 2012 21:15:25 -0600
From:	Joel A Fernandes <agnel.joel@...il.com>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Scott Wood <scottwood@...escale.com>,
	Russ Dill <Russ.Dill@...com>, linux-omap@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving
 omap_devices to mach-omap2)

On Fri, Nov 9, 2012 at 8:29 AM, David Gibson
<david@...son.dropbear.id.au> wrote:
> On Fri, Nov 09, 2012 at 12:32:09AM -0500, Joel A Fernandes wrote:
>> Hi Pantelis,
>>
>> I hope I'm not too late to reply as I'm traveling.
>>
>> On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou
>> <panto@...oniou-consulting.com> wrote:
>>
>> >> Joanne has purchased one of Jane's capes and packaged it into a rugged
>> >> case for data logging. As far as Joanne is concerned, the BeagleBone and
>> >> cape together are a single unit and she'd prefer a single monolithic FDT
>> >> instead of using an FDT overlay.
>> >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files
>> >>        to generate a single .dtb for the entire system which is
>> >>        loaded by U-Boot. -or-
>> >
>> > Unlikely.
>> >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files
>> >>        (instead of .dts files), -or-
>> > Possible but low probability.
>> >
>> >> Option C: U-Boot loads both the base and overlay FDT files, merges them,
>> >>        and passes the resolved tree to the kernel.
>> >>
>> >
>> > Could be made to work. Only really required if Joanne wants the
>> > cape interface to work for u-boot too. For example if the cape has some
>> > kind of network interface that u-boot will use to boot from.
>> >
>>
>> I love Grant's hashing idea a lot keeping the phandle problem for
>> compile time and not requiring fixups.
>
> Well, using a hash only moves the problem of fixed phandles to a
> problem of fixed node paths.  The details of node paths are, if
> anything, more mutable than phandles.

So what you're saying is there's no way to make a phandle a signature
of a (property of a node) since no one property is unique. If I
follow, even node path can't be used because hash value changes if
node is moved around in the tree. This shoots down the hashing idea
then, which I guess is looked down upon anyway due to dynamic changes
to the base DT as discussed in the usecases.

> [snip]
>> Alternatively to hashing, reading David Gibson's paper I followed,
>> phandle is supposed to 'uniquely' identity node. I wonder why the node
>> name itself is not sufficient to uniquely identify.
>
> Node names are not unique, not even close.  If you have two similar
> NICs in slot 0 of two different PCI domains, they'll almost certainly
> both be called 'ethernet@0,0'.  Similar examples abound on other
> buses.  Node paths are unique, but they are long.
>
> The other big reason for phandles in OF history is that they would be
> more stable than paths.  The device tree could be manipulated during
> OF runtime, but phandles would generally be internal pointers in OF
> and so remain a consistent handle even if the node moved in the tree.
> That's not really relevant for flat trees, but we need to work with
> the same structures.

Thanks.

>> The code that does
>> the tree walking can then just strcmp the node name while it walks the
>> tree instead of having to find a node with a phandle number. I guess
>> the reason is phandles are small to store as data values. Another
>> approach can be to arrange the string block in alphabetical order
>> (unless it already is),
>
> They're not, and doing so would be a painful change to maintain
> compatibility across.  And in any case only property names use the
> strings block, not node names.

Understood, thanks.

Regards,
Joel
--
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/