On Fri, Nov 9, 2012 at 8:29 AM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
