Re: [PATCH v10 3/4] dtc: Plugin and fixup support

[Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>]

On 29/11/2016 10:39, Pantelis Antoniou wrote:
> Hi Phil,
>
>> On Nov 29, 2016, at 12:32 , Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org> wrote:
>>
>> On 29/11/2016 02:11, David Gibson wrote:
>>> On Mon, Nov 28, 2016 at 12:24:20PM +0000, Phil Elwell wrote:
>>>> On 28/11/2016 12:10, Pantelis Antoniou wrote:
>>>>> For plugins we need the __symbols__ node to support stacked overlays, i.e.
>>>>> overlays referring label that were introduced by a previous overlay.
>>>> Although it is arguably useful to be able to refer to symbols created by
>>>> one overlay from within another, do we really want all symbols to be
>>>> global? Isn't there a call for a new syntax or usage pattern to indicate
>>>> either that a symbol should be local to the overlay or, my preferred
>>>> option, global?
>>> So, this is back to a design question about the overlay format.  As
>>> noted in the initial discussions about possible "connector" formats, I
>>> think we will want some sort of local symbols.  But the current
>>> overlay format with all global symbols is out there and we need to
>>> support it.
>> The overlay format we have does not dictate the scope of the symbols.
>>
>> In all implementations I know of - the Raspberry Pi loader, the current
>> Linux kernel, the latest dtc patch set - there is a completely
>> asymmetric relationship between the base DTB and an overlay:
>> * the base DTB exports __symbols__ to resolve the overlays unresolved
>> label references, as recorded by the __fixups__ node
>> * the overlay's phandles are renumbered so as not to clash with the base
>> tree using the __local_fixups__
>> * the contents of the __overlay__ nodes are applied to the base tree, as
>> directed by the "target" or "target-path” properties
>>
> Yes
>
>> The __symbols__ node of the overlay is ignored and discarded. The
>> __fixups__ and __local_fixups__ in the base DTB (if present - the RPi
>> dtc only generates them for /plugins/) are ignored.
>>
> That was a limitation that no-longer applies. Overlay symbols can be added
> to the base tree symbol list with a small patch I have already posted.
The fact that they can doesn't mean they necessarily should.
>
>> In the set of RPi overlays only one exports a global symbol, which it
>> achieves with an overlay aimed at target-path = "/__symbols__" that adds
>> a new symbol (in this case "i2c_gpio").
>>
>> If the __symbols__ in an overlay are automatically merged with the base
>> symbols, that is a significant change in semantics which needs to be
>> discussed.
>>
> You no longer need to do this anymore. Hope this helps :)

Not really, no. With the current scheme we have control over the scope,
but now there is none.

How does your patch handle duplicate symbols?

Phil