Re: [PATCH v2 1/2] overlays: auto allocate phandles for nodes in base fdt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, Jan 4, 2018 at 9:53 PM, David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 04, 2018 at 03:08:08PM -0700, Ian Lepore wrote:
>> On Thu, 2018-01-04 at 15:47 -0600, Kyle Evans wrote:
>> > 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  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
>>
>> In particular, it makes lookups more expensive as it now must traverse
>> a list that includes every node in the dtb, rather than just nodes that
>> are actually referenced.  (It also increases the amount of storage, but
>> at 20-ish bytes per node, that's not a big deal.)
>
> Lookups of what exactly?  Aren't you unflattening the tree after you
> read it in?

Lookup in this context would be a lookup of the device from the xref
phandle, see OF_device_from_xref [1] and its inverse
OF_xref_from_device right below it. Devices, as they attach, register
for the xref phandle, then consumers lookup the device associated with
it and generally hold a handle to the device afterwards.

[1] http://src.illumos.org/source/xref/freebsd-head/sys/dev/ofw/openfirm.c#628
--
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



[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux