[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260119164628.78f713bd@bootlin.com>
Date: Mon, 19 Jan 2026 16:46:28 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Ayush Singh <ayush@...gleboard.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
devicetree-compiler@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree-spec@...r.kernel.org, Hui Pu
<hui.pu@...ealthcare.com>, Ian Ray <ian.ray@...ealthcare.com>, Luca
Ceresoli <luca.ceresoli@...tlin.com>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 29/77] Add support for FDT_EXPORT_SYM_REF dtb tag
Hi David,
On Thu, 15 Jan 2026 17:25:58 +1100
David Gibson <david@...son.dropbear.id.au> wrote:
> On Mon, Jan 12, 2026 at 03:19:19PM +0100, Herve Codina wrote:
> > The FDT_EXPORT_SYM_REF dtb tag is similar to the FDT_EXPORT_SYM tag
> > except that it identifies a reference to an external phandle. The node
> > referenced by the phandle is not present in the device-tree blob.
> >
> > The FDT_EXPORT_SYM_REF dtb tag is a meta-data tag defining an exported
> > symbol. It can be present in a node bloc meaning that a symbol is
> > exported at this node level. The node pointed to by this symbol is not a
> > local node (i.e. the node is not present in the device-tree blob.). This
> > tag can be available only in overlay or addon device-tree blobs. The
> > symbol has to be resolved when the device-tree blob is applied on top of
> > a base device-tree.
> >
> > It is followed by three values and a possible alignment padding:
> > - name (string including \0)
> > The export symbol name. I.e. the name used to reference this
> > exported symbol.
> > - padding:
> > Padding (0x00) added to have the next value aligned on 32bit.
> > - phandle (32bit)
> > A placeholder for a phandle value.
> > This placeholder can be used during some dtb manipulation to store
> > a temporary phandle value.
>
> Yuck.
Will see what I can do to avoid this placeholder.
I need to store the phandle value related to this symbol during the symbol
resolution. This is done by addon_resolve_phandles() available in
libfdt/fdt_addon.c in patch 70.
libfdt is not designed to perform allocation to store temporary values. It
manipulates data directly mapped from dtb working with offset in dtb blob
without any other kind of object. No specific objects (C struct) for node,
properties, markers, ...
To have an area for this phandle value, a room reserved in dtb was really
the easier way.
But well, I understand your "yuck".
I think it will be quite tricky to store this temporary phandle value
without allocating some additional data.
This placeholder simplified a lot of things but well, I think I need to find
an other solution.
If anyone has any ideas to store the temporary phandle value, I am all ears.
Best regards,
Hervé
Powered by blists - more mailing lists