From: Ayush Singh <ayush@beagleboard.org>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Andrew Davis <afd@ti.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
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>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 0/7] of: overlay: Add support for export-symbols node feature
Date: Tue, 10 Dec 2024 15:26:44 +0530 [thread overview]
Message-ID: <bab9f277-a366-48ec-acdd-0896c8307ad9@beagleboard.org> (raw)
In-Reply-To: <20241210104141.39acffb1@bootlin.com>
On 10/12/24 15:11, Herve Codina wrote:
> Hi Ayush,
>
> On Tue, 10 Dec 2024 14:52:22 +0530
> Ayush Singh <ayush@beagleboard.org> wrote:
>
> ...
>>
>> What is the reason for not using symbols directly as described here [3]?
>>
>> I do like this approach since it does not pollute the global symbols.
>> Just want to know if there are any other reasons for it.
>>
>
> Modifying the __symbols__ node at runtime (adding / removing properties in
> it) exposes memory leaks if __symbols__ already exist in the live DT.
> This __symbols__ node exist if the dtb was compiled with '-@' or if you
> chain the overlay (i.e. __symbols__ node created by the first overlay).
Yeah, that is a problem, specially in a setup which might involve
hot-plugging.
>
> I think also that some conflicts can appears. What happens if you want to
> add a new label but this label is already present for some other purpose?
I do not think that actually is a problem. As described in the original
patch [0], the symbol and connector overlay is supposed to be applied as
a group (overwriting any conflicting symbols in the process).
The reason why this is not a problem is that `__symbols__` are only used
to resolve the phandles (overlays do not support path references yet),
but do not really have a purpose in the livetree (at least far as I
know, but I can be wrong).
>
> Best regards,
> Hervé
[0]: https://lore.kernel.org/lkml/20240702164403.29067-1-afd@ti.com/
Ayush Singh
next prev parent reply other threads:[~2024-12-10 9:56 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 15:18 Herve Codina
2024-12-09 15:18 ` [PATCH 1/7] dt-bindings: Add support for export-symbols node Herve Codina
2024-12-09 16:26 ` Rob Herring (Arm)
2024-12-18 13:05 ` Herve Codina
2024-12-09 17:27 ` Luca Ceresoli
2024-12-10 8:20 ` Herve Codina
2024-12-09 15:18 ` [PATCH 2/7] of: resolver: Introduce get_phandle_from_symbols_node() Herve Codina
2024-12-09 15:18 ` [PATCH 3/7] of: resolver: Add export_symbols in of_resolve_phandles() parameters Herve Codina
2024-12-09 15:18 ` [PATCH 4/7] of: resolver: Add support for the export symbols node Herve Codina
2024-12-09 15:18 ` [PATCH 5/7] of: overlay: Add export_symbols_name in of_overlay_fdt_apply() parameters Herve Codina
2024-12-09 17:27 ` Luca Ceresoli
2024-12-10 8:21 ` Herve Codina
2024-12-09 15:18 ` [PATCH 6/7] of: overlay: Add support for the export symbols node Herve Codina
2024-12-09 15:18 ` [PATCH 7/7] of: unittest: Add tests for export symbols Herve Codina
2024-12-10 16:51 ` kernel test robot
2024-12-12 1:05 ` kernel test robot
2024-12-09 16:47 ` [PATCH 0/7] of: overlay: Add support for export-symbols node feature Andrew Davis
2024-12-09 17:03 ` Herve Codina
2024-12-09 17:47 ` Andrew Davis
2024-12-09 19:39 ` Rob Herring
2024-12-10 9:30 ` Ayush Singh
2024-12-09 20:11 ` Rob Herring
2024-12-10 8:16 ` Herve Codina
2024-12-10 13:46 ` Rob Herring
2024-12-10 14:58 ` Herve Codina
2024-12-18 12:22 ` Herve Codina
2024-12-10 9:22 ` Ayush Singh
2024-12-10 9:41 ` Herve Codina
2024-12-10 9:56 ` Ayush Singh [this message]
2024-12-10 10:55 ` Herve Codina
2025-01-08 7:36 ` Ayush Singh
2025-01-08 8:07 ` Herve Codina
2025-01-08 8:28 ` Ayush Singh
2025-01-08 9:47 ` Herve Codina
2025-01-10 4:26 ` David Gibson
2025-01-10 7:36 ` Herve Codina
2025-01-10 7:55 ` Ayush Singh
2025-01-11 3:17 ` David Gibson
2025-04-29 19:12 ` Ayush Singh
2025-04-30 12:48 Herve Codina
2025-04-30 12:50 ` Herve Codina
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=bab9f277-a366-48ec-acdd-0896c8307ad9@beagleboard.org \
--to=ayush@beagleboard.org \
--cc=afd@ti.com \
--cc=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=herve.codina@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.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
all inboxes | Powered by JetHome®