From: David Gibson <david@gibson.dropbear.id.au>
To: Tom Rini <trini@konsulko.com>
Cc: devicetree-compiler@vger.kernel.org
Subject: Re: [PATCH] libfdt: fdt_check_full: Add can_assume(PERFECT) check
Date: Wed, 17 Jun 2026 15:38:19 +1000 [thread overview]
Message-ID: <ajIyy7hesDaTlvc5@zatzit> (raw)
In-Reply-To: <20260605222054.GC382693@bill-the-cat>
[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]
On Fri, Jun 05, 2026 at 04:20:54PM -0600, Tom Rini wrote:
> On Tue, May 26, 2026 at 10:38:59PM -0600, Tom Rini wrote:
> > On Wed, May 27, 2026 at 02:23:20PM +1000, David Gibson wrote:
> > > On Tue, May 26, 2026 at 02:30:22PM -0600, Tom Rini wrote:
> > > > In this function from fdt_check.c we have (reasonably and as the name
> > > > implies) a number of checks on the DTB. However, there are cases where
> > > > we may wish to assume that we have been given a perfect DTB already and
> > > > do nothing here. Add a test for can_assume(PERFECT) as the first check
> > > > in this function and if true, perform no checks.
> > > >
> > > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > > ---
> > > > Along the lines of the patches I posted back in December, in U-Boot SPL
> > > > we just don't have the space for this check much of the time and so have
> > > > always omitted it (going back to at least when Simon posted the initial
> > > > patch to make libfdt/fdt_check.c here). This is another case where it's
> > > > a noticeable size win for us. I had missed this change in particular
> > > > because we had in turn missed catching up on fdt_check_full being moved
> > > > out of fdt_ro.c and in to fdt_check.c.
> > >
> > > I'm not necessarily against this, but I have some misgivings.
> > >
> > > fdt_check_full() is (deliberately) not called from anywhere else in
> > > libfdt - it's intended to allow the user to explicitly do a full
> > > validity check on the tree. Given that meaning, I'm not sure it's
> > > wise to turn it into a no-op based on the assume flags.
> > >
> > > Your comment seems to imply that the issue here is size - simply
> > > having this function compiled - rather than being too expensive when
> > > (explicitly) called. That's a little surprising to me - it's in its
> > > own compilation unit, specifically so that the linker can omit it if
> > > it's not used. Is there something unusual about your build
> > > environment that's not letting that happen?
> >
> > So, we have code like this:
> > /* Get the total space reserved for FDT in blob */
> > live_fdt = bloblist_get_blob(BLOBLISTT_CONTROL_FDT, &blob_size);
> > if (live_fdt != gd->fdt_blob)
> > return -ENOENT;
> >
> > ret = fdt_check_full(live_fdt, blob_size);
> > if (ret)
> > return fdtdec_ret_to_errno(ret);
> >
> > And this is compiled on TPL, SPL and full U-Boot builds. On the first
> > two, we're just too space constrained to do this check. So it's not the
> > linker doing the right thing or not, it's avoiding having to #if the
> > code directly (or rather, CONFIG_VAL(...)). My line of thinking was that
> > since ASSUME_PERFECT is that everything is really perfect, this is the
> > way to go. Yes, it's a little odd to have both "call the validation
> > function" and "the validation function does not validate" but that's
> > just because in the second case, we explicitly configured ourself to not
> > validate anything.
> >
> > And FWIW, that's really how we use the assume mask in U-Boot, either
> > 0xff or 0x0. It's a case where we're either passing along the tree we
> > bundled with ourself (and so we can assume it's fine) or it's passed
> > along (and we verify).
>
> Hey, just checking if there's any further discussion here? I want to try
> and get the delta between U-Boot and upstream down to zero if we can.
No further discussion, I just have approximately zero time for dtc
maintenance :(.
--
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 --]
next prev parent reply other threads:[~2026-06-17 5:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 20:30 [PATCH] libfdt: fdt_check_full: Add can_assume(PERFECT) check Tom Rini
2026-05-27 4:23 ` David Gibson
2026-05-27 4:38 ` Tom Rini
2026-06-05 22:20 ` Tom Rini
2026-06-16 18:39 ` Tom Rini
2026-06-17 5:38 ` David Gibson [this message]
2026-06-17 15:16 ` Tom Rini
2026-06-17 5:37 ` David Gibson
2026-05-27 4:41 ` Simon Glass
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=ajIyy7hesDaTlvc5@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=devicetree-compiler@vger.kernel.org \
--cc=trini@konsulko.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.