All of lore.kernel.org
 help / color / mirror / Atom feed
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, 27 May 2026 14:23:20 +1000	[thread overview]
Message-ID: <ahZxuCONf2JfMXU8@zatzit> (raw)
In-Reply-To: <20260526203022.4006434-1-trini@konsulko.com>

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

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?

> ---
>  libfdt/fdt_check.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libfdt/fdt_check.c b/libfdt/fdt_check.c
> index cca052353213..2fd5b61d016a 100644
> --- a/libfdt/fdt_check.c
> +++ b/libfdt/fdt_check.c
> @@ -21,6 +21,8 @@ int fdt_check_full(const void *fdt, size_t bufsize)
>  	const char *propname;
>  	bool expect_end = false;
>  
> +	if (can_assume(PERFECT))
> +		return 0;
>  	if (bufsize < FDT_V1_SIZE)
>  		return -FDT_ERR_TRUNCATED;
>  	if (bufsize < fdt_header_size(fdt))
> -- 
> 2.43.0
> 
> 

-- 
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 --]

  reply	other threads:[~2026-05-27  4:24 UTC|newest]

Thread overview: 5+ 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 [this message]
2026-05-27  4:38   ` Tom Rini
2026-06-05 22:20     ` Tom Rini
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=ahZxuCONf2JfMXU8@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.