linux-kernel - Re: [PATCH] arm/arm64: dts: renesas: Drop unused .dtsi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqJk1PfEuH6VeMkoZdU7v5AsfdhWczLj0uVx=5qWt_OJWw@mail.gmail.com>
Date: Mon, 15 Dec 2025 07:19:41 -0600
From: Rob Herring <robh@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>, Magnus Damm <magnus.damm@...il.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-renesas-soc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Jacopo Mondi <jacopo.mondi@...asonboard.com>
Subject: Re: [PATCH] arm/arm64: dts: renesas: Drop unused .dtsi

On Mon, Dec 15, 2025 at 3:02 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sat, 13 Dec 2025 at 07:20, Laurent Pinchart
> <laurent.pinchart@...asonboard.com> wrote:
> > On Fri, Dec 12, 2025 at 02:32:07PM -0600, Rob Herring (Arm) wrote:
> > > These .dtsi files are not included anywhere in the tree and can't be
> > > tested.
> > >
> > > Signed-off-by: Rob Herring (Arm) <robh@...nel.org>
>
> Thanks for your patch!
>
> > >  arch/arm64/boot/dts/renesas/r8a779m0.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r8a779m2.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r8a779m4.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r8a779m6.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r8a779m7.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r8a779m8.dtsi     |  17 -
> > >  arch/arm64/boot/dts/renesas/r8a779mb.dtsi     |  12 -
> > >  arch/arm64/boot/dts/renesas/r9a07g044c1.dtsi  |  25 --
> > >  arch/arm64/boot/dts/renesas/r9a07g044l1.dtsi  |  18 -
> > >  arch/arm64/boot/dts/renesas/r9a07g054l1.dtsi  |  18 -
> > >  arch/arm64/boot/dts/renesas/r9a09g047e37.dtsi |  18 -
> >
> > I'll let Geert comment on this :-)
>
> While I do understand your point, these might be used by customers of
> the SoCs.  Hence they can be considered part of the "stable DT ABI",
> and removing them can cause issues downstream.

DTBs are the ABI, not .dtsi. The compatible in these is not validated
and isn't valid. We could simply restructure .dtsi files in a way that
breaks downstream and wouldn't give it a second thought.

> At least for the r8a779m* parts, I do have local patches in my tree,
> so I would notice any future build breakages (most files are rather
> simple, so unlikely to break, though).
> Shall we just upstream .dts files using these .dtsi files (cfr. the
> existing arch/arm64/boot/dts/renesas/r8a779m*dts)? AFAIK none of
> the missing board/SoC-combos actually exist as products, but someone
> might create one locally by replacing the SoC on an existing board,
> as they are pin-compatible variants.

You probably could restructure these where you include the subset
.dtsi and then add nodes rather than delete them. For the ones that
just override the compatible with an invalid value that has to be
overridden by the board dts anyways, there's little value to them.
Just drop them or add a proper board.

> There is a similar story for the r9a0* parts: they are variants with
> less CPU cores, which may end up in actual products.  We could add
> .dts files using them, to make sure no build breakage is introduced.

If these are all just binned parts, I would not have separate SoC
compatibles for them.

Rob