From: Herve Codina <herve.codina@bootlin.com>
To: Ayush Singh <ayush@beagleboard.org>
Cc: Jason Kridner <jkridner@beagleboard.org>,
d-gole@ti.com, Deepak Khatri <lorforlinux@beagleboard.org>,
Robert Nelson <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>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
devicetree-spec@vger.kernel.org
Subject: Re: [RFC] Adding export-symbols to specification
Date: Tue, 4 Feb 2025 20:21:57 +0100 [thread overview]
Message-ID: <20250204202157.202230fe@bootlin.com> (raw)
In-Reply-To: <d5f629f5-68d0-4c41-be62-1f1acee3db64@beagleboard.org>
On Tue, 4 Feb 2025 22:54:52 +0530
Ayush Singh <ayush@beagleboard.org> wrote:
> > You have perfectly summarized the export-symbols goal and the benefit of
> > this new feature.
> >
> > I am waiting for feedback from other people. I hope we will move forward
> > on this topic and unblock several users (me included) stuck on this real
> > issue.
> >
> > Thanks a lot!
> >
> > Best regards,
> > Hervé
>
> While working on a Patch series to the specification itself, I realized
> that I was missing some edge cases, so wanted to discuss those:
>
> # Scope
>
> Should export-symbols only be used to resolve the properties in parent,
> or should all other children (and their decedents) use the
> `export-symbols` for resolving phandles and path references?
>
> For example, should the following work:
>
>
> parent {
>
> sibling {
>
> led = <&gpio 0 GPIO_ACTIVE_HIGH>
>
> };
>
>
> export-symbols {
>
> gpio = <&my_gpio1>;
>
> };
>
> };
>
>
> This would also mean that bottoms up lookup needs to take place for all
> `export-symbols` that might be present in path to root, before using top
> level `__symbols__` or `/aliases`.
I restricted the use of export-symbols node when an overlay is applied at a node
which contains an export-symbols sub-node.
In your example, If you apply an overlay at parent node, your export-symbols
is used but if you apply an overlay at sibling node, your export-symbols is
not used.
Of course if your overlay applied at parent node looks like the following:
__overlay__ {
sibling {
prop = <&gpio>;
};
};
&gpio will be resolved using your export-symbols. __overlay__ is applied
at parent -> visible in the overlay.
If the base device-tree looks like this:
parent {
sibling {
export-symbols {
gpio = <&my_gpio1>;
};
};
};
The same overlay applied at parent will failed.
Indeed, no export-symbols is available at parent node and so the
gpio symbols used by the overlay will not be resolved even
if an export-symbols exists in the sibling node.
To see this export-symbols from the overlay, the overlay has to be applied
at sibling node and not parent node.
>
>
> # Export symbols phandles
>
> Can export symbols reference each other? For example is the following valid:
>
>
> parent {
>
> export-symbols {
>
> shadow_gpio = <&my_gpio1>;
>
> gpio = <&shadow_gpio>;
>
> };
>
> };
For sure, not planned.
Also, maybe I missed something but I am not sure you can have a
phandle referencing a property.
In your example, shadow_gpio is a property, even if we add a label
to this property i.e.
label_shadow_gpio: shadow_gpio = <&my_gpio1>;
How can we set:
gpio = <&label_shadow_gpio>;
Best regards,
Hervé
next prev parent reply other threads:[~2025-02-04 19:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 13:45 [RFC] Adding export-symbols to specification Ayush Singh
2025-01-27 15:20 ` Herve Codina
2025-02-04 17:24 ` Ayush Singh
2025-02-04 19:21 ` Herve Codina [this message]
2025-02-04 20:23 ` Ayush Singh
2025-02-05 9:32 ` Herve Codina
2025-02-12 10:47 ` Herve Codina
2025-02-12 11:02 ` Ayush Singh
2025-01-30 16:47 ` Quentin Schulz
2025-01-30 18:07 ` Herve Codina
2025-01-30 19:01 ` Ayush Singh
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=20250204202157.202230fe@bootlin.com \
--to=herve.codina@bootlin.com \
--cc=afd@ti.com \
--cc=arnd@arndb.de \
--cc=ayush@beagleboard.org \
--cc=conor+dt@kernel.org \
--cc=d-gole@ti.com \
--cc=david@gibson.dropbear.id.au \
--cc=devicetree-spec@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.