Hi Rob,

Ping.

There is a conflict between this and Mauro's v3 patch at:

  https://lore.kernel.org/r/cover.1586961793.git.mchehab+hua...@kernel.org

I pointed out the conflict to Mauro in his v2 patch, and he said he would
rebase on a new -next to resolve the conflict.  Unfortunately my patch
was not in -next, so the conflict remains.

If Mauro's patches should go in first, I can redo my patches on top of
his, after his go in.

-Frank

On 1/27/20 6:37 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand <frank.row...@sony.com>
> 
> The overlay implementation details in the compiled (DTB) file are
> now properly implemented by the dtc compiler and should no longer
> be hard coded in the source file.
> 
> Signed-off-by: Frank Rowand <frank.row...@sony.com>
> ---
> 
> changes since v1:
>   - fixed typo in patch comment (implementation)
> 
>  Documentation/devicetree/overlay-notes.txt | 85 
> ++++++++++++------------------
>  1 file changed, 35 insertions(+), 50 deletions(-)
> 
> diff --git a/Documentation/devicetree/overlay-notes.txt 
> b/Documentation/devicetree/overlay-notes.txt
> index 725fb8d255c1..fddc63da7dba 100644
> --- a/Documentation/devicetree/overlay-notes.txt
> +++ b/Documentation/devicetree/overlay-notes.txt
> @@ -19,6 +19,7 @@ Lets take an example where we have a foo board with the 
> following base tree:
>  
>  ---- foo.dts 
> -----------------------------------------------------------------
>       /* FOO platform */
> +     /dts-v1/;
>       / {
>               compatible = "corp,foo";
>  
> @@ -30,30 +31,25 @@ Lets take an example where we have a foo board with the 
> following base tree:
>               ocp: ocp {
>                       /* peripherals that are always instantiated */
>                       peripheral1 { ... };
> -             }
> +             };
>       };
>  ---- foo.dts 
> -----------------------------------------------------------------
>  
> -The overlay bar.dts, when loaded (and resolved as described in [1]) should
> +The overlay bar.dts,
>  
> ----- bar.dts 
> -----------------------------------------------------------------
> -/plugin/;    /* allow undefined label references and record them */
> -/ {
> -     ....    /* various properties for loader use; i.e. part id etc. */
> -     fragment@0 {
> -             target = <&ocp>;
> -             __overlay__ {
> -                     /* bar peripheral */
> -                     bar {
> -                             compatible = "corp,bar";
> -                             ... /* various properties and child nodes */
> -                     }
> +---- bar.dts - overlay target location by label 
> ------------------------------
> +     /dts-v1/;
> +     /plugin/;
> +     &ocp {
> +             /* bar peripheral */
> +             bar {
> +                     compatible = "corp,bar";
> +                     ... /* various properties and child nodes */
>               };
>       };
> -};
>  ---- bar.dts 
> -----------------------------------------------------------------
>  
> -result in foo+bar.dts
> +when loaded (and resolved as described in [1]) should result in foo+bar.dts
>  
>  ---- foo+bar.dts 
> -------------------------------------------------------------
>       /* FOO platform + bar peripheral */
> @@ -73,8 +69,8 @@ result in foo+bar.dts
>                       bar {
>                               compatible = "corp,bar";
>                               ... /* various properties and child nodes */
> -                     }
> -             }
> +                     };
> +             };
>       };
>  ---- foo+bar.dts 
> -------------------------------------------------------------
>  
> @@ -82,6 +78,27 @@ As a result of the overlay, a new device node (bar) has 
> been created
>  so a bar platform device will be registered and if a matching device driver
>  is loaded the device will be created as expected.
>  
> +If the base DT was not compiled with the -@ option then the "&ocp" label
> +will not be available to resolve the overlay node(s) to the proper location
> +in the base DT. In this case, the target path can be provided. The target
> +location by label syntax is preferred because the overlay can be applied to
> +any base DT containing the label, no matter where the label occurs in the DT.
> +
> +The above bar.dts example modified to use target path syntax is:
> +
> +---- bar.dts - overlay target location by explicit path 
> ----------------------
> +     /dts-v1/;
> +     /plugin/;
> +     &{/ocp} {
> +             /* bar peripheral */
> +             bar {
> +                     compatible = "corp,bar";
> +                     ... /* various properties and child nodes */
> +             }
> +     };
> +---- bar.dts 
> -----------------------------------------------------------------
> +
> +
>  Overlay in-kernel API
>  --------------------------------
>  
> @@ -105,35 +122,3 @@ enum of_overlay_notify_action for details.
>  Note that a notifier callback is not supposed to store pointers to a device
>  tree node or its content beyond OF_OVERLAY_POST_REMOVE corresponding to the
>  respective node it received.
> -
> -Overlay DTS Format
> -------------------
> -
> -The DTS of an overlay should have the following format:
> -
> -{
> -     /* ignored properties by the overlay */
> -
> -     fragment@0 {    /* first child node */
> -
> -             target=<phandle>;       /* phandle target of the overlay */
> -     or
> -             target-path="/path";    /* target path of the overlay */
> -
> -             __overlay__ {
> -                     property-a;     /* add property-a to the target */
> -                     node-a {        /* add to an existing, or create a 
> node-a */
> -                             ...
> -                     };
> -             };
> -     }
> -     fragment@1 {    /* second child node */
> -             ...
> -     };
> -     /* more fragments follow */
> -}
> -
> -Using the non-phandle based target method allows one to use a base DT which 
> does
> -not contain a __symbols__ node, i.e. it was not compiled with the -@ option.
> -The __symbols__ node is only required for the target=<phandle> method, since 
> it
> -contains the information required to map from a phandle to a tree location.
> 

Reply via email to