[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260116161727.7fe14658@bootlin.com>
Date: Fri, 16 Jan 2026 16:17:27 +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 11/77] Add support for FDT_REF_PHANDLE dtb tag
Hi David,
On Thu, 15 Jan 2026 12:24:49 +1100
David Gibson <david@...son.dropbear.id.au> wrote:
> On Mon, Jan 12, 2026 at 03:19:01PM +0100, Herve Codina wrote:
> > The FDT_REF_PHANDLE dtb tag is similar to the FDT_REF_LOCAL 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 names FDT_REF_PHANDLE and FDT_REF_LOCAL are perhaps a little
> misleading - both are marking a phandle, the difference is in the form
> of reference. That's quite difference from the distinction between
> the REF_PHANDLE and REF_PATH marker types, where the difference is in
> what the reference expands to in the property.
I am agree.
FDT_PHANDLE: A local phandle with the value known.
FDT_PHANDLE_REF: An external phandle, its value need to be resolved ?
This is aligned with FDT_EXPORT_SYM / FDT_EXPORT_SYM_REF.
Or maybe:
FDT_TYPE_PHANDLE
FDT_TYPE_PHANDLE_REF
"TYPE" has been mentioned by Rob in the "FDT_TYPE_U32" context.
Any other ideas are welcome.
>
> > The FDT_REF_PHANDLE dtb tag is a meta-data tag attached to a property.
> >
> > It indicates that the property defined before this tag (FDT_PROP) uses a
> > phandle value and the node related to this phandle value is not 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 phandle
> > value used in the property has to be resolved when the device-tree blob
> > is applied on top of a base device-tree.
>
> This is kind of looking ahead, but does that imply that this tag is
> only valid in addon dtbs?
addon dtbs for sure but also overlay (plugin) dtbs.
>
> > It is followed by two values and a possible alignment padding:
> > - offset (32bit):
> > Offset in the property data where the phandle is available.
> > - label (string including \0):
> > The label to use to resolve the phandle value.
>
> I expect it will become apparent later in the series, but it would be
> helpful to clarify what the scope of that label is. A single node?
> The whole tree? Across a tree and all its possible addons?
This label is the unresolved reference. Its scope is the dtb.
For instance, "prop = < 0 1 &foo>;" in a dts with the node referenced by
&foo not present in this dts (possible for addons and plugins) will lead
to 'FDT_REF_PHANDLE 8 "foo"'
The way "foo" is used when the dtb is applied is covered later in the
series.
It will be resolved with import/export mechanism (when the addon is
applied).
Also it can be a namespace label reference (see patch 66 for the definition
of namespace label reference) and here also it will be resolved thanks to
import/export mechanism. Namespace label references can only be present in
addons.
Best regards,
Hervé
Powered by blists - more mailing lists