From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CAF226F2BD for ; Mon, 19 Jan 2026 06:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=150.107.74.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768804602; cv=none; b=H348Z8PFbPXli4ekwlj1EBjtQr+ZcTtBu9tKUakSXOt9MBqL93gxmObsRz1kq1foTvfTZxvbKnCUldDvnDggpRJMEV8uT6pz4HbQNw7qCXY2Dg1VIS+/C+lcmVthRW2NYs9hXi0T7Nf5cTweYjIHsebvcjW8HM/teJ7dTxcjVgY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768804602; c=relaxed/simple; bh=/n2GERmUFRC4qRgdPmpbYwUJmo+2maqh1juEMlOcLiQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b4OA4qUE0I3dfRrPY8Zovem54YER9Kq4CzpJmLaGZosQbZGtdx5akUkFc1LUXMJRyTs5Qo/MipopxAqojgupKsAi8ZZZU8wRykc3MHu4lzRxa3LbysIZ6dpcMXBkBiA7dwqdc9u4LiiaeJi0S0fpBRDhdieaPo6pBOxHp86395I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au; spf=pass smtp.mailfrom=gandalf.ozlabs.org; dkim=pass (2048-bit key) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b=Z4ev7NV6; arc=none smtp.client-ip=150.107.74.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gandalf.ozlabs.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.b="Z4ev7NV6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1768804596; bh=mOlqIxvBpKMHuWBrshSo8GCC1Uglw3ucrO/lXgZBm40=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z4ev7NV6wlD8z9isc5W3/QrMzrvaT9z9jsrQjyYDMzAc5OrMQWgdMnwpiP2eO1DHP T0ygIQf9Ch6I+N7WQRhrl7rdaStIWECUCAMjYSu8JDZ7FbORc/Z4VZ1KWmb5qQMaX8 CrCSWxx4xxtyz02mKDcxclYV43bic/GfYw64/vh2zl1vfQsVFLEKKgaQcZJ0nlfLi1 LSiLa9eYUrFIbeqFZgphYo/GkxplVVtHrBKyur8V9nVJDYfwn8o3r/A4YngVqIYlCX U7uwT2Nvc6EXlXJdez/XrZhZI8Y9Ige5NoMZls7i6m2riA1JZOwlJrM2V5lMdp5b1x sMAOhDHdF1u+A== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dvgj02Z4yz4wGT; Mon, 19 Jan 2026 17:36:36 +1100 (AEDT) Date: Mon, 19 Jan 2026 17:36:30 +1100 From: David Gibson To: Phil Dawson Cc: "devicetree-compiler@vger.kernel.org" Subject: Re: delete-node without label or address from overlay dts Message-ID: References: Precedence: bulk X-Mailing-List: devicetree-compiler@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QEw9m7gTgcgGHL24" Content-Disposition: inline In-Reply-To: --QEw9m7gTgcgGHL24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2026 at 02:39:30PM +0000, Phil Dawson wrote: > On Fri, 16 Jan 2026 at 13:03, David Gibson = 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: >=20 > 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 > > > /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 { > > > > > > }; > > > }; > > > > > > 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 co= de > > david AT gibson.dropbear.id.au | minimalist, thank you, not the other = way > > | around. > > http://www.ozlabs.org/~dgibson >=20 > Thanks, > Phil >=20 --=20 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 --QEw9m7gTgcgGHL24 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmlt0O0ACgkQzQJF27ox 2GcECRAApalrenOqfy4VLnMxQ0Tiew+P3gSE8Lo2jHKeKSDF+ZTLuO05cl/OWOBO hXJf6n8/pZeee98c/J7UsA7ClHLSxUjQ7Rs3KN5AzNwBCLm4OM4G4Lqw6Wb0jaFJ Hsv2GzAespTjnCjs8N5tEECzrtk3OIlSbq6gQDpfpGxo8yJXdDn3E2hwsCtDd80c ewHjZNoMUKJywl1sxaC1+C2syrQqDIKG8YVgkYD6XmqS83+5eYCD9Mf6D2hP8x5g ErYQ5deiTIDjI5msAtjZ7o7kncvMckUyHrZNJgr5xe6S8YZDKkmPgLeoIgZW/dV8 PpuvOjPEmoCNZObKSKRCEDccDPrzZJ5EtJ4ARGVJjk1dQheXWqYqLah/lXn8iQWU MdGTP1i0t8yg+cuIKYgMrdqdtKsapILEn2r7jbv2xur16GbMiqLhi6I0FhE2hzm6 9JOOfIQSnlx2Djbtt38NNemoNEC9f470KQLeaetHjtEW3HvRn8XzfVnccZsftYJv 8uc1930iEc+Xha9B1rcpjriSPFsQ3Zqr61CiYZBpu0ef1apU7OF74XmPo84PXBwy 7Im7cvZl9gc9JW52+RQFAU/v1/8GpbaPH0EcAb1Fvb0X4YJtsikCeuraBuPuxpIE Ih5KvGumalwf3Ukjcb3kO4dUNlVOvgBQeDTi+G5JghPQbJO5JCA= =7J3F -----END PGP SIGNATURE----- --QEw9m7gTgcgGHL24--