[RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Joel A Fernandes]

On Fri, Nov 9, 2012 at 8:29 AM, David Gibson
<david at gibson.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 at antoniou-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 at 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