All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	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>
Subject: Re: [PATCH v2 02/10] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
Date: Thu, 18 Jun 2026 20:13:57 +1000	[thread overview]
Message-ID: <ajPE5eGcOwWMAeiN@zatzit> (raw)
In-Reply-To: <20260409115426.352214-3-herve.codina@bootlin.com>

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

On Thu, Apr 09, 2026 at 01:54:18PM +0200, Herve Codina wrote:
> In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> at the offset 0 of the structure block.
> 
> This assumption is not correct. Indeed, a FDT_NOP can be present at the
> offset 0 and this is a legit case.
> 
> fdt_first_node() has been introduced recently to get the offset of the
> first node (first FDT_BEGIN_NODE) in a fdt blob.
> 
> Use this function to get the first node offset instead of looking for
> this node at offset 0.
> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>

The problem is real, of course.  But this approach to solving it with
a special case just for the root node is really ugly.

Granted, it's a problem of my own making - I chose not to create an
fdt_root_offset() function in the first place, instead making it part
of the API that offset 0 means the root node.  Nonetheless, here we
are and the question is whether we can do better.

# Straightforward things first

 - This patch should be folded with 1/10, they're both harder to
   understand without the context of the other.

 - If it must exist, the function should be fdt_root_offset(), not
   fdt_first_node(), for at least three reasons:
    * "first" in what sense?
    * "first" amongst what set of nodes?
    * We have a strong convention to always explicitly say "offset",
      not just referring to offset values as "node" or "property".
      This is deliberate: it's an attempt to discourage the otherwise
      likely misunderstanding that a function getting a "node" gives
      you some sort of persistent handle.  "offset" makes it clearer
      that the value will no longer be valid after a modification to
      the tree.

 - The situation described is subtle enough that this *really* needs a
   testcase.  It shouldn't be that hard: change the existing
   'nopulate' test tool to add an FDT_NOP before the first tag, not
   just after

# Is FDT_NOP before the root node actually legitimate?

Arguably the simplest solution here would be to explicitly ban this.
Yes, it would be a slightly odd restriction in the spec.  However,
avoiding the mess in the library might be worth it.  Note that this
situation can never arise from fdt_nop_node(), unless you apply it to
the root node, in which case there's no tree left.

# Less special casery

Even if we accept the need for FDT_NOP before the root node, I think
we can do better.  The below implements this as a special case, just
for offset 0.  Instead, we could allow all node operations on a
FDT_NOP offset, automatically advancing to the next FDT_BEGIN_NODE
tag.  We may be able to do that in check_node_offset_() minimising
code duplication.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2026-06-18 14:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 11:54 [PATCH v2 00/10] Add support for structured tags and v18 dtb version Herve Codina
2026-04-09 11:54 ` [PATCH v2 01/10] libfdt: Introduce fdt_first_node() Herve Codina
2026-06-04 20:59   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 02/10] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0 Herve Codina
2026-06-04 21:04   ` Frank Li
2026-06-18 10:13   ` David Gibson [this message]
2026-06-18 19:17     ` Herve Codina
2026-04-09 11:54 ` [PATCH v2 03/10] tests: asm: Introduce treehdr_vers macro Herve Codina
2026-06-04 21:09   ` Frank Li
2026-06-18 10:15   ` David Gibson
2026-06-18 19:55     ` Herve Codina
2026-04-09 11:54 ` [PATCH v2 04/10] Introduce structured tag value definition Herve Codina
2026-06-04 21:14   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 05/10] fdtdump: Handle unknown tags Herve Codina
2026-06-04 21:19   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 06/10] flattree: " Herve Codina
2026-06-04 21:22   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 07/10] libfdt: Handle unknown tags in fdt_next_tag() Herve Codina
2026-06-04 21:25   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 08/10] libfdt: Introduce fdt_ptr_offset_ Herve Codina
2026-06-04 21:26   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 09/10] libfdt: Handle unknown tags on dtb modifications Herve Codina
2026-06-04 21:30   ` Frank Li
2026-04-09 11:54 ` [PATCH v2 10/10] Introduce v18 dtb version Herve Codina
2026-06-04 21:33   ` Frank Li

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=ajPE5eGcOwWMAeiN@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=ayush@beagleboard.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=devicetree-spec@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=herve.codina@bootlin.com \
    --cc=hui.pu@gehealthcare.com \
    --cc=ian.ray@gehealthcare.com \
    --cc=krzk@kernel.org \
    --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.