devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ayush Singh <ayush@beagleboard.org>
To: Herve Codina <herve.codina@bootlin.com>
Cc: d-gole@ti.com, lorforlinux@beagleboard.org,
	jkridner@beagleboard.org, robertcnelson@beagleboard.org,
	nenad.marinkovic@mikroe.com, Andrew Davis <afd@ti.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Robert Nelson <robertcnelson@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Saravana Kannan <saravanak@google.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	devicetree-compiler@vger.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>
Subject: Re: [PATCH] libfdt: overlay: Add export-symbols support
Date: Sun, 19 Jan 2025 18:49:01 +0530	[thread overview]
Message-ID: <86a7a08c-d81c-43d4-99fb-d0c4e9777601@beagleboard.org> (raw)
In-Reply-To: <20250116144054.0ba5805a@bootlin.com>

On 16/01/25 19:10, Herve Codina wrote:
> Hi Ayush,
> 
> Cc Thomas and Lucas (interested in this topic).
> 
> 
> On Sun, 12 Jan 2025 00:58:52 +0530
> Ayush Singh <ayush@beagleboard.org> wrote:
> 
>> The export symbols node adds some additional symbols that can be used
>> in the symbols resolution. The resolver tries to match unresolved
>> symbols first using the export symbols node and, if a match is not
>> found, it tries the normal route and searches the __symbols__ node.
>>
>> Contrary to symbols available in the global __symbols__ node, symbols
>> listed in the export symbols node can be considered as local symbols.
>> Indeed, they can be changed depending on the node the overlay is going
>> to be applied to and are only visible from the current node properties.
>>
>> export-symbols are phandle based as opposed to global __symbols__. This
>> allows for much simpler use with overlays as opposed to __symbols__
>> where paths require resizing of overlays as show in [0].
>>
>> The phandle resolution in overlay is now broken into 2 steps:
>> - fragment target phandles
>> - All other phandles
>>
>> The reason this is required is because to find the export-symbols node
>> in the target node, we first need to resolve the target phandles. Here
>> is an example of overlay that will generate the target __fixup__ after
>> the property fixup, and thus fail without this 2 step resolution.
>>
>> ```
>> /dts-v1/;
>> /plugin/;
>>
>> &connectora {
>>    prop = <&gpio_connector>;
>> };
>>
>> &connectorb {
>>    prop = <&gpio_connector>;
>> };
>> ```
>>
>> Using fdtdump, we get the following:
>>
>> ```
>> **** fdtdump is a low-level debugging tool, not meant for general use.
>> **** If you want to decompile a dtb, you probably want
>> ****     dtc -I dtb -O dts <filename>
>>
>> /dts-v1/;
>> // magic:               0xd00dfeed
>> // totalsize:           0x1b1 (433)
>> // off_dt_struct:       0x38
>> // off_dt_strings:      0x180
>> // off_mem_rsvmap:      0x28
>> // version:             17
>> // last_comp_version:   16
>> // boot_cpuid_phys:     0x0
>> // size_dt_strings:     0x31
>> // size_dt_struct:      0x148
>>
>> / {
>>      fragment@0 {
>>          target = <0xffffffff>;
>>          __overlay__ {
>>              prop = <0xffffffff>;
>>          };
>>      };
>>      fragment@1 {
>>          target = <0xffffffff>;
>>          __overlay__ {
>>              prop = <0xffffffff>;
>>          };
>>      };
>>      __fixups__ {
>>          connectora = "/fragment@0:target:0";
>>          gpio_connector = "/fragment@0/__overlay__:prop:0", "/fragment@1/__overlay__:prop:0";
>>          connectorb = "/fragment@1:target:0";
>>      };
>> };
>> ```
>>
>> [0]: https://lore.kernel.org/devicetree-compiler/6b2dba90-3c52-4933-88f3-b47f96dc7710@beagleboard.org/T/#m8259c8754f680b9da7b91f7b7dd89f10da91d8ed
>>
>> Signed-off-by: Ayush Singh <ayush@beagleboard.org>
>> ---
>> As discussed in the export-symbols kernel patch series [0] and [1], the
>> following patch series adds support for export-symbols in fdtoverlay.
>>
>> This patch series is mostly a prototype for the functionality. Depending
>> on the direction, next revision of the patch will add tests.
>>
>> [0]: https://lore.kernel.org/all/20241209151830.95723-1-herve.codina@bootlin.com/
>> [1]: https://lore.kernel.org/r/20250110-export-symbols-v1-1-b6213fcd6c82@beagleboard.org
>> ---
>>   libfdt/fdt_overlay.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++-----
>>   1 file changed, 222 insertions(+), 23 deletions(-)
> 
> Thanks a lot for this patch!
> 
> I did a little modification related to unitialized variables leading to
> compilation errors.
> 
> Here is my modification.
> --- 8< ---
> diff --git a/libfdt/fdt_overlay.c b/libfdt/fdt_overlay.c
> index 7cb2230..12745b5 100644
> --- a/libfdt/fdt_overlay.c
> +++ b/libfdt/fdt_overlay.c
> @@ -411,7 +411,7 @@ static int overlay_fixup_target_phandle(void *fdt, void *fdto, int symbols_off,
>          const char *symbol_path;
>          int prop_len;
>          int symbol_off;
> -       uint32_t phandle;
> +       uint32_t phandle = 0;
>   
>          value = fdt_getprop_by_offset(fdto, property,
>                                        &label, &len);
> @@ -544,7 +544,7 @@ static int overlay_fixup_non_target_phandle(void *fdt, void *fdto,
>          const char *symbol_path;
>          int prop_len;
>          int symbol_off;
> -       uint32_t symbol_phandle;
> +       uint32_t symbol_phandle = 0;
>   
>          value = fdt_getprop_by_offset(fdto, property, &label, &len);
>          if (!value) {
> --- 8< ---
> 
> 
> I tested your code and fdtoverlay failed when the __symbols__ node is not in
> the base devicetree.
> 
> With the export-symbols node, the resolution can be successful without the
> need of the global __symbols__ node.
> 
> The error was just related to a check in overlay_fixup_one_phandle().
> 
> All verification are already done in previous operations. And so, I removed
> the check and the symbols_off parameter (not needed anymore). Here is the
> exact modification I did:
> --- 8< ---
> diff --git a/libfdt/fdt_overlay.c b/libfdt/fdt_overlay.c
> index 12745b5..a9f0465 100644
> --- a/libfdt/fdt_overlay.c
> +++ b/libfdt/fdt_overlay.c
> @@ -308,7 +308,6 @@ static int overlay_update_local_references(void *fdto, uint32_t delta)
>   /**
>    * overlay_fixup_one_phandle - Set an overlay phandle to the base one
>    * @fdto: Device tree overlay blob
> - * @symbols_off: Node offset of the symbols node in the base device tree
>    * @path: Path to a node holding a phandle in the overlay
>    * @path_len: number of path characters to consider
>    * @name: Name of the property holding the phandle reference in the overlay
> @@ -327,7 +326,7 @@ static int overlay_update_local_references(void *fdto, uint32_t delta)
>    *      0 on success
>    *      Negative error code on failure
>    */
> -static int overlay_fixup_one_phandle(void *fdto, int symbols_off,
> +static int overlay_fixup_one_phandle(void *fdto,
>   				     const char *path, uint32_t path_len,
>   				     const char *name, uint32_t name_len,
>   				     int poffset, uint32_t phandle)
> @@ -335,9 +334,6 @@ static int overlay_fixup_one_phandle(void *fdto, int symbols_off,
>   	fdt32_t phandle_prop;
>   	int fixup_off;
>   
> -	if (symbols_off < 0)
> -		return symbols_off;
> -
>   	fixup_off = fdt_path_offset_namelen(fdto, path, path_len);
>   	if (fixup_off == -FDT_ERR_NOTFOUND)
>   		return -FDT_ERR_BADOVERLAY;
> @@ -468,7 +464,7 @@ static int overlay_fixup_target_phandle(void *fdt, void *fdto, int symbols_off,
>   		if (path_len == (fixup_len - 1))
>   			return -FDT_ERR_BADOVERLAY;
>   
> -		ret = overlay_fixup_one_phandle(fdto, symbols_off, path,
> +		ret = overlay_fixup_one_phandle(fdto, path,
>   						path_len, "target",
>   						sizeof("target") - 1, 0,
>   						phandle);
> @@ -628,7 +624,7 @@ static int overlay_fixup_non_target_phandle(void *fdt, void *fdto,
>   			target_phandle = symbol_phandle;
>   		}
>   
> -		ret = overlay_fixup_one_phandle(fdto, symbols_off, path,
> +		ret = overlay_fixup_one_phandle(fdto, path,
>   						path_len, name, name_len,
>   						poffset, target_phandle);
>   		if (ret)
> --- 8< ---
> 
> With this modification applied, fdtoverlay worked without any issue using
> the following commands:
>    dtc -I dts -O dtb base.dts > base.dtb
>    dtc -I dts -O dtb overlay.dtso > overlay.dtbo
>    fdtoverlay -i base.dtb -o full.dtb overlay.dtbo
> 
> The resulting full.dtb was correct.
> 
> The file base.dts used for the test was:
> --- 8< ---
> /dts-v1/;
> 
> /{
> 	somewhere {
> 		base_node1: base-node1 {
> 			prop = "base,node1";
> 		};
> 
> 		base-node2 {
> 			prop = "base,node2";
> 			ref-base-node1 = <&base_node1>;
> 		};
> 
> 		base_node3: base-node3 {
> 			prop = "base,node3";
> 		};
> 
> 		export-symbols {
> 			base_node = <&base_node3>;
> 		};
> 	};
> };
> --- 8< ---
> 
> And the overlay.dso:
> --- 8< ---
> /dts-v1/;
> /plugin/;
> 
> / {
> 	fragment@0 {
> 		target-path = "/somewhere";
> 
> 		__overlay__ {
> 			ovl_node1: ovl_node1 {
> 				prop = "ovl,node1";
> 			};
> 
> 			ovl_node2 {
> 				prop = "ovl,node2";
> 				ref-ovl-node1 = <&ovl_node1>;
> 			};
> 
> 			ovl_node3 {
> 				prop = "ovl,node3";
> 				ref-base-node = <&base_node>;
> 			};
> 		};
> 	};
> };
> --- 8< ---
> 
> Hope this will help moving forward on this topic.
> 
> Best regards,
> Hervé

Thanks for the feedback.

I will add the changes in v2 of the patch.

I will also be sending a patch series to devicetree-spec mailing list 
[0] to see if any changes would be needed to make it part of the spec 
rather than linux specific node.

[0]: https://lore.kernel.org/devicetree-spec/

Ayush Singh

      reply	other threads:[~2025-01-19 13:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-11 19:28 [PATCH] libfdt: overlay: Add export-symbols support Ayush Singh
2025-01-16 13:40 ` Herve Codina
2025-01-19 13:19   ` Ayush Singh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86a7a08c-d81c-43d4-99fb-d0c4e9777601@beagleboard.org \
    --to=ayush@beagleboard.org \
    --cc=afd@ti.com \
    --cc=arnd@arndb.de \
    --cc=conor+dt@kernel.org \
    --cc=d-gole@ti.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herve.codina@bootlin.com \
    --cc=jkridner@beagleboard.org \
    --cc=krzk+dt@kernel.org \
    --cc=lorforlinux@beagleboard.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=nenad.marinkovic@mikroe.com \
    --cc=robertcnelson@beagleboard.org \
    --cc=robertcnelson@gmail.com \
    --cc=robh@kernel.org \
    --cc=saravanak@google.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).