mirror of https://lore.kernel.org/lkml/
 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: 44+ 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-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 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®