Hi Rob, > On May 17, 2016, at 15:58 , Rob Herring <robherring2@xxxxxxxxx> wrote: > > On Mon, May 16, 2016 at 3:18 PM, Pantelis Antoniou > <pantelis.antoniou@xxxxxxxxxxxx> wrote: >> Add a description of the target root overlay method to the overlay >> documention file. >> >> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> --- >> Documentation/devicetree/overlay-notes.txt | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/Documentation/devicetree/overlay-notes.txt b/Documentation/devicetree/overlay-notes.txt >> index 6995fc1..3e8df30 100644 >> --- a/Documentation/devicetree/overlay-notes.txt >> +++ b/Documentation/devicetree/overlay-notes.txt >> @@ -104,6 +104,10 @@ If your board has multiple slots/places where a single overlay can work >> and each slot is defined by a node, you can use the >> of_overlay_create_target_index() method to select the target. >> >> +For overlays on probeable busses, use the of_overlay_create_target_root() method >> +in which you supply a device node as a target root, and which all target >> +references in the overlay are performed relative to that node. > > This needs a better explanation and an example. "Applying overlays to > multiple places for probeable busses" is not sufficient. Describe what > is the problem/flow, and then how does the implementation work. I > don't think this problem is limited to probeable busses either. Not > knowing the target to apply the overlay to is the same problem for > connectors with non-probeable signals. > OK. > I find a couple of things problematic with the implementation. There's > no way to validate that an overlay should apply to a base node. If > users just always make the target "/", then any overlay can apply to > any location the nodes could apply anywhere. It requires a kernel > change for every location you want to apply the overlay to. Maybe I > don't understand the usecase. > No, this doesn’t work like this. This is an in kernel interface. The piece of kernel software that applies the overlay has an additional security policy about where the target root may point to. > I feel like we are creating too many syntax's to apply overlays. I get > that there are different usecases, but that doesn't necessarily mean > the syntax needs to be different. > >> + >> Overlay DTS Format >> ------------------ >> >> @@ -141,3 +145,7 @@ contains the information required to map from a phandle to a tree location. >> Using a target index requires the use of a selector target on the call to >> of_overlay_create_target_index(). I.e. passing an index of 0 will select the >> target in the foo node, an index of 1 the bar node, etc. >> + >> +Note that when using the target root create method all target references must >> +lie under the target root node. I.e. the overlay is not allowed to 'break' out >> +of the root. > > That is not enforceable though, right? > It is enforceable. All the targets of an overlay incur an additional check that make sure that no targets break out. > Rob Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
