On Thu, Jan 4, 2018 at 3:34 PM, Kyle Evans <kevans@xxxxxxxxxxx> wrote: > On Thu, Jan 4, 2018 at 2:41 PM, Kyle Evans <kevans@xxxxxxxxxxx> wrote: >> On Thu, Jan 4, 2018 at 2:33 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: >>> [... snip ...] >>> >>> Does this remove the need for the proposed patch, or am I still >>> missing something? >> >> ... nope. Apparently I never tested this with this particular dtc(1) >> and instead just assumed it did the same as ours- allocate phandle >> sparsely, even with -@. That certainly removes the need for this >> patch, and I'm somewhat upset that I hadn't previously considered >> this. >> >> @David, Jon: Please disregard all of the patches along these lines... >> I'll fix this in our dtc, where it should be fixed. >> >> Thanks, Frank! > > Actually, I'm kind of torn on whether this is useful or not. With > being able to have EFI-provided FDT, it's hard to guarantee whether > the FDT we're provided has been compiled with GPL dtc(1) and -@. The > above solves this problem for most of my personal use-cases , though, > since I can guarantee that our FDT and U-Boot provided FDT is compiled > properly. Apologies for the triple post; I realized that this argument is inherently wrong, since we can't reference the node if there's no symbol anyways. The only way this might still be a good idea is to support more minimal cases where an implementation might prefer to not create a phandle for nodes that haven't been referenced. In our case, we have a function [1] that walks the tree and generates metadata on nodes that have phandles, under the assumption that these have been referenced somewhere and provides a way to more quickly reference these specifically through a separate linked link. Allocating phandles for everything as GPL dtc does adds quite a bit more overhead to this. [1] http://src.illumos.org/source/xref/freebsd-head/sys/dev/ofw/openfirm.c#119 -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
