All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Simon Glass <sjg@chromium.org>
Cc: Devicetree Compiler <devicetree-compiler@vger.kernel.org>
Subject: Re: [PATCH 4/5] fdtput: Name the property when it cannot be deleted
Date: Wed, 28 Oct 2026 12:43:32 +1100	[thread overview]
Message-ID: <auFTOCEGx_Fe0iy-@gractus.seuss> (raw)
In-Reply-To: <20261027120126.2613353-5-sjg@chromium.org>

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

On Tue, Oct 27, 2026 at 06:01:18AM -0600, Simon Glass wrote:
> When 'fdtput -d' fails to delete a property, for example because it does
> not exist, the error names the node rather than the property:
> 
>    $ fdtput -d test.dtb /chosen missing
>    Error at '/chosen': FDT_ERR_NOTFOUND
> 
> This suggests that the node is missing, when it is the property that
> is.
> 
> Report the property name instead.
> 
> Fixes: aa719618a8b7 ("fdtput: add delete node and property function")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Simon Glass <sjg@chromium.org>

I agree it would be useful to show the property name, but
	Error at '<property name'
Doesn't seem very usefully descriptive to me, and the node name _also_
seems useful.  I think we should print both in such cases.

> ---
> 
>  fdtput.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fdtput.c b/fdtput.c
> index c9973d5..8636d5a 100644
> --- a/fdtput.c
> +++ b/fdtput.c
> @@ -334,7 +334,7 @@ static int delete_prop(char *blob, const char *node_name, const char *prop_name)
>  
>  	node = fdt_delprop(blob, node, prop_name);
>  	if (node < 0) {
> -		report_error(node_name, -1, node);
> +		report_error(prop_name, -1, node);
>  		return -1;
>  	}
>  
> -- 
> 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-10-28  1:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 12:01 [PATCH 0/5] fdtput: Make it clearer how to create nodes Simon Glass
2026-10-27 12:01 ` [PATCH 1/5] fdtput: Explain " Simon Glass
2026-10-27 12:01 ` [PATCH 2/5] fdtput: Follow an alias when creating nodes with -p Simon Glass
2026-10-28  1:34   ` David Gibson
2026-10-27 12:01 ` [PATCH 3/5] fdtput: Suggest -p when a node is missing Simon Glass
2026-10-28  1:39   ` David Gibson
2026-10-28  7:39     ` Simon Glass
2026-10-27 12:01 ` [PATCH 4/5] fdtput: Name the property when it cannot be deleted Simon Glass
2026-10-28  1:43   ` David Gibson [this message]
2026-10-27 12:01 ` [PATCH 5/5] fdtput: Correct the description of -t in the manual Simon Glass
2026-10-28  1:58 ` [PATCH 0/5] fdtput: Make it clearer how to create nodes David Gibson

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=auFTOCEGx_Fe0iy-@gractus.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=sjg@chromium.org \
    /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.