lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ