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 --]
next prev parent 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.