All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	David Lechner <dlechner@baylibre.com>,
	Ayush Singh <ayush@beagleboard.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	devicetree-compiler@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree-spec@vger.kernel.org,
	Hui Pu <hui.pu@gehealthcare.com>,
	Ian Ray <ian.ray@gehealthcare.com>,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Frank Li <Frank.Li@nxp.com>
Subject: Re: [PATCH v3 02/15] libfdt: Don't assume the root node is available at offset 0
Date: Tue, 8 Sep 2026 10:08:23 +0200	[thread overview]
Message-ID: <20260908100823.1f474894@bootlin.com> (raw)
In-Reply-To: <ap-t8qMg5VMwh-T9@gractus.seuss>

On Tue, 8 Sep 2026 16:41:06 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Mon, Sep 07, 2026 at 06:46:41PM +0200, Herve Codina wrote:
> > Hi David,
> > 
> > On Wed, 2 Sep 2026 17:06:03 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> > 
> > ...  
> > > > 
> > > > Ok, I will update fdt_check_node_offset_() to have it updating its offset
> > > > parameter to the real offset of the root node when its value is 0.
> > > > 
> > > > Based on this update, will see where it goes. I mean, impacts on callers, if
> > > > it simplifies things or not, if the offset update needs also to be propagate
> > > > to caller's parameter or any other similar point that we can see during the
> > > > implementation.
> > > > 
> > > > Having something implemented and available in a patch will be the best to
> > > > compare changes and impacts related to fdt_check_node_offset_() update.
> > > > 
> > > > Here we have a version of handling offset 0 vs real root node without any
> > > > offset update done in fdt_check_node_offset_(). In the next iteration we will
> > > > have the version with update done in fdt_check_node_offset_().
> > > > 
> > > > I think the golden rules to follow on this point is "keep it as simple as
> > > > possible".    
> > > 
> > > Agreed.  Feel free to repost just the NOP before root patches on their
> > > own.  At this time, frequent small series is easier for me to tackle
> > > than occasional large series.
> > >   
> > 
> > I've moved forward on the fdt_check_node_offset_() update.
> > 
> > The new fdt_check_node_offset_() looks like this:
> > --- 8< ---
> > int fdt_check_node_offset_(const void *fdt, int *offset)
> > {
> > 	int nextoffset;
> > 
> > 	if (!can_assume(VALID_INPUT)
> > 	    && ((*offset < 0) || (*offset % FDT_TAGSIZE)))
> > 		return -FDT_ERR_BADOFFSET;
> > 
> > 	if (*offset == 0) {
> > 		*offset = fdt_root_offset(fdt);
> > 		if (*offset < 0)
> > 			return *offset;
> > 	}
> > 
> > 	if (fdt_next_tag(fdt, *offset, &nextoffset) != FDT_BEGIN_NODE)
> > 		return -FDT_ERR_BADOFFSET;
> > 
> > 	return nextoffset;
> > }
> > --- 8< ---  
> 
> That looks fine.  If it was an exposed function I'd want to look for a
> better interface, but as an internal function it's fine.
> 
> > If the given offset is 0, fdt_check_node_offset_() considers we want to check
> > the root node and so update offset to the real root node offset.
> > 
> > Ok, I still need some fdt_root_offset() calls from some other parts but that's
> > not my main issue.
> > 
> > My main issue comes with orphan nodes in addons. fdt_check_node_offset_() is
> > called with offset pointing to an orphan node and this offset can be 0.
> > 
> > The offset 0 seen by fdt_check_node_offset_() can be the "fake" offset of a root
> > node and in that case fdt_check_node_offset_() should update offset to the real
> > root node offset but it can also be the offset of the orphan node we want to check
> > and in that case the offset should not be updated.
> > 
> > fdt_check_node_offset_() cannot determine whether or not the offset should be
> > updated.  
> 
> Hrm.  But if offset 0 has an orphan node, we can see that with the
> FDT_BEGIN_NODE or FDT_BEGIN_NODE_REF there, right?
> 
> > With orphan nodes in the loop, fdt_check_node_offset_() becomes:
> > --- 8< ---
> > int fdt_check_node_offset_(const void *fdt, int *offset)
> > {
> >         int nextoffset;
> >         uint32_t tag;
> > 
> >         if (!can_assume(VALID_INPUT)
> >             && ((*offset < 0) || (*offset % FDT_TAGSIZE)))
> >                 return -FDT_ERR_BADOFFSET;
> > 
> >         if (*offset == 0) {
> > #pragma message "We have a problem!"
> >                 /*
> >                  * An orphan node can be present at offset 0.
> >                  * In that case, looking for the root node may or may not be
> >                  * correct.
> >                  * Indeed is offset = 0 requested because we want the root
> >                  * node and sadly an orphan node is available at offset 0 or
> >                  * is it requested because we want to really check the orphan
> >                  * node available at offset 0. How to determine the correct
> >                  * case?
> >                  */
> >                 tag = fdt_next_tag(fdt, *offset, &nextoffset);
> >                 if (tag == FDT_BEGIN_NODE || tag == FDT_BEGIN_NODE_REF)
> >                         return nextoffset;
> > 
> >                 *offset = fdt_root_offset(fdt);
> >                 if (*offset < 0)
> >                         return *offset;
> >         }
> > 
> >         tag = fdt_next_tag(fdt, *offset, &nextoffset);
> >         if (tag != FDT_BEGIN_NODE && tag != FDT_BEGIN_NODE_REF)
> >                 return -FDT_ERR_BADOFFSET;
> > 
> >         return nextoffset;
> > }
> > --- 8< ---  
> 
> Right.. like that.  Except simpler would be to have fdt_root_offset()
> stop when it sees a FDT_BEGIN_NODE_REF as well as a FDT_BEGIN_NODE.
> Or maybe that should be, say, fdt_root_offset_(), and
> fdt_root_offset() will wrap it to return an error on an addon tree
> with no root.

No, fdt_root_offset() must get the root node offset. An orphan node identified
with FDT_BEGIN_NODE_REF cannot be a root node.

An addon can have, a root node only, orphan nodes only or both a root node and
orphan nodes.

fdt_root_offset() looks for the root node (i.e. the first FDT_BEGIN_NODE at
top level). If not found, -ERRNOTFOUND (addon) or -ERRBADSTRUCTURE (not addon).

Having a fdt_root_offset() stop at either FDT_BEGIN_NODE_REF or FDT_BEGIN_NODE
is "fdt_first_node_offset()".

Let me introduce the internal fdt_first_node_offset_()
- fdt_root_offset()
  It calls fdt_first_node_offset_() and check that this node is a
  FDT_BEGIN_NODE node.

- fdt_check_node_offset_()
  if the offset == 0, it updates the value with the offset returned by
  fdt_first_node_offset_()

And so, a node offset 0 doesn't means the root node but the first node
in the dtb (root or orphan). I am totally fine with this definition.

At some point, maybe users of the API (when addon are involved) will have to
take care of that and perform something like:
  root = fdt_root_offset();
  fdt_get_property(fdt, root, "prop", NULL);

Or
  fdt_for_each_orphan(orphan, fdt) {
     fdt_get_property(fdt, orphan, "prop", NULL);
     ...
  }

Here also, I am totally fine with that an I already use this kind of sequence
in libfdt/fdt_addon.c to apply an addon on a base dtb.

I will introduce fdt_first_node_offset_() but let me know if you prefer
having fdt_first_node_offset_() introduced right now in this "structure
tags" series or later in the addon series.

Best regards,
Hervé

  reply	other threads:[~2026-09-08  8:08 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  8:31 [PATCH v3 00/15] Add support for structured tags and v18 dtb version Herve Codina
2026-08-26  8:31 ` [PATCH v3 01/15] fdtget: Use libfdt iterators instead of open coded loops Herve Codina
2026-08-27  3:55   ` David Gibson
2026-08-26  8:31 ` [PATCH v3 02/15] libfdt: Don't assume the root node is available at offset 0 Herve Codina
2026-08-30  3:21   ` David Gibson
2026-08-31 12:01     ` Herve Codina
2026-09-01  7:42       ` David Gibson
2026-09-01 12:18         ` Herve Codina
2026-09-02  7:06           ` David Gibson
2026-09-07 16:46             ` Herve Codina
2026-09-08  6:41               ` David Gibson
2026-09-08  8:08                 ` Herve Codina [this message]
2026-09-09  6:18                   ` David Gibson
2026-09-09  6:58                     ` Herve Codina
2026-09-09  7:02                       ` David Gibson
2026-08-26  8:31 ` [PATCH v3 03/15] tests: " Herve Codina
2026-09-01  8:03   ` David Gibson
2026-09-01 13:36     ` Herve Codina
2026-09-02  8:56       ` David Gibson
2026-08-26  8:31 ` [PATCH v3 04/15] tests/nopulate: Add a FDT_NOP before the root node Herve Codina
2026-09-01  8:05   ` David Gibson
2026-08-26  8:31 ` [PATCH v3 05/15] tests: treegen: Introduce emit_fdt_header_vers() Herve Codina
2026-09-09  6:38   ` David Gibson
2026-08-26  8:31 ` [PATCH v3 06/15] Introduce structured tag value definition Herve Codina
2026-09-10  4:51   ` David Gibson
2026-09-10  7:41     ` Herve Codina
2026-09-10  9:32       ` David Gibson
2026-09-11  7:16         ` Herve Codina
2026-09-12  2:34           ` David Gibson
2026-09-10  5:33   ` David Gibson
2026-09-10  7:58     ` Herve Codina
2026-09-10  9:41       ` David Gibson
2026-09-11  7:53         ` Herve Codina
2026-09-12  2:35           ` David Gibson
2026-08-26  8:31 ` [PATCH v3 07/15] fdtdump: Handle unknown tags Herve Codina
2026-09-10  5:25   ` David Gibson
2026-09-10  8:27     ` Herve Codina
2026-08-26  8:31 ` [PATCH v3 08/15] flattree: " Herve Codina
2026-08-26  8:31 ` [PATCH v3 09/15] libfdt: Handle unknown tags in fdt_next_tag() Herve Codina
2026-08-26  8:31 ` [PATCH v3 10/15] libfdt: Introduce fdt_ptr_offset_() Herve Codina
2026-08-26  8:31 ` [PATCH v3 11/15] libfdt: Introduce fdt_getprop_by_offset_w() Herve Codina
2026-08-26  8:31 ` [PATCH v3 12/15] libfdt: Introduce fdt_getprop_offset_namelen() Herve Codina
2026-08-26  8:31 ` [PATCH v3 13/15] tests: Add wip_func utility Herve Codina
2026-08-26  8:31 ` [PATCH v3 14/15] libfdt: Handle unknown tags on dtb modifications Herve Codina
2026-08-26  8:31 ` [PATCH v3 15/15] Introduce v18 dtb version 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=20260908100823.1f474894@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=Frank.Li@nxp.com \
    --cc=ayush@beagleboard.org \
    --cc=conor+dt@kernel.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=devicetree-spec@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=hui.pu@gehealthcare.com \
    --cc=ian.ray@gehealthcare.com \
    --cc=krzk@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=robh@kernel.org \
    --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.