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

On 29/11/2016 02:11, David Gibson wrote:

On Mon, Nov 28, 2016 at 12:24:20PM +0000, Phil Elwell wrote:

quoted

On 28/11/2016 12:10, Pantelis Antoniou wrote:

quoted

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

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.

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.

Phil