From: David Gibson <david@gibson.dropbear.id.au>
To: Phil Dawson <phil.d.dawson@gmail.com>
Cc: "devicetree-compiler@vger.kernel.org"
<devicetree-compiler@vger.kernel.org>
Subject: Re: delete-node without label or address from overlay dts
Date: Mon, 19 Jan 2026 17:36:30 +1100 [thread overview]
Message-ID: <aW3Q7sXrrFR-Ki3i@zatzit> (raw)
In-Reply-To: <CALx+s3SsAikSU_Butewas-MRmP+Dt+WhnwGuYgY=x=OSw8SfQg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4666 bytes --]
On Fri, Jan 16, 2026 at 02:39:30PM +0000, Phil Dawson wrote:
> On Fri, 16 Jan 2026 at 13:03, David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > On Thu, Jan 15, 2026 at 12:00:13PM +0000, Phil Dawson wrote:
> > > Hi,
> > >
> > > Apologies if this is covered in documentation that I've missed.
> > > Is there a way to use /delete-node/ to remove a node with no label or
> > > address from a plugin/overlay dts file?
> >
> > No. /delete-node/ has no representation within overlay files. One of
> > several examples of how plugin/overlays are misleading in that they
> > sort of resemble dtc's older build-time overlays, but not really.
> >
> Just to be clear as my understanding is a bit muddy:
>
> I know you cannot use an overlay to remove a node from the base tree
> at runtime.
Oh, sorry, I misunderstood your question.
> But is it correct that when constructing an overlay with dtc you can
> only use /delete-node/ if the node you wish to remove has a label
> or address?
I think that's correct, though kind of by accident.
> > > I have a device tree overlay file pl.dtsi that is auto generated by
> > > vendor tools. Unfortunately many nodes in this file are generated
> > > wrong and the overlay fails to apply.
> > > I've been removing the broken nodes with /delete-node/ &label; syntax
> > > in a second dtsi file and then compiling the two together with a
> > > wrapper dts file and the commands:
> > > gcc -E -nostdinc -undef -D__DTS__ -x assembler-with-cpp -o pl.dts.pp
> > > <path redacted>/pl.dts
> > > dtc -R 8 -b 0 -p 0 -@ -H epapr -o pl.dtbo -I dts -O dtb pl.dts.pp
> > > (These are run as part of a larger yocto build so there may be some
> > > other work around this I'm missing!)
> > >
> > > The auto generated pl.dtsi also has a few broken nodes without labels
> > > or addresses like this:
> > >
> > > /dts-v1/;
> > > /plugin/;
> > > &amba {
> > > vcap_hdmi_input_1_v_proc_ss_1 {
> > > <contents removed for brevity>
> > > };
> > > };
> > >
> > > I am unable to figure out the syntax to remove these nodes with
> > > /delete-node/, should this be possible?
> > >
> > > I've tried using the below syntax:
> > > &amba {
> > > /delete-node/ vcap_hdmi_input_1_v_proc_ss_1;
> > > };
> > >
> > > But while dtc doesn't complain, the nodes are not removed from the
> > > resulting dtbo.
Right. So this happens because when compiling a plugin each top-level
chunk is compiled into a separate "fragment" in the plugin. The
/delete-node/ here would remove anything already defined in the same
fragment, but not things in earlier fragments.
In non-/plugin/ mode we merge all the chunks together, so
/delete-node/ (and /delete-property/ for that matter) will apply
properly regardless of which chunks everything appears in.
This is another ugly consequence of the rather haphazard ways
plugins/overlays are designed / implemented. I think we could fix it
by not merging everything during the parse: instead generating a list
of chunks, then merging them in a later, explicit step. We'd always
do that for full trees, and merge only those pieces that we can
resolve for plugins.
I think that would be a good fix, but I'm certainly not going to have
time to implement it in the forseeable future.
> > Hm, we probably should make this generate an error. I'm unlikely to
> > get to that any time soon, though.
> >
> > > I also can't remove using the full path as there is no root node/full
> > > path in the generated dtsi file.
> > >
> > > According to this discussion on an unrelated project
> > > (https://github.com/zephyrproject-rtos/zephyr/discussions/67228)
> > > trying to delete a node with a name and address without using the
> > > address won't work. But in my case the node has no address.
> > >
> > > I can work around my issue by hacking the auto generated files (while
> > > I try to persuade the vendor to fix them!) to add a label for these
> > > nodes and then removing them using the label. But is there a correct
> > > way of doing this just using my separate dtsi file and dtc?
> > >
> > > Best Regards,
> > > Phil Dawson
> > >
> >
> > --
> > 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
>
> Thanks,
> Phil
>
--
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-01-19 6:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 12:00 delete-node without label or address from overlay dts Phil Dawson
2026-01-16 0:03 ` David Gibson
2026-01-16 14:39 ` Phil Dawson
2026-01-19 6:36 ` David Gibson [this message]
2026-01-20 11:10 ` Phil Dawson
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=aW3Q7sXrrFR-Ki3i@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=devicetree-compiler@vger.kernel.org \
--cc=phil.d.dawson@gmail.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.