linux-kernel - Re: [PATCH v6 3/4] arm64: dts: ti: k3-am62l: add initial infrastructure

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: <20250912192456.msnw64b62yr5ricw@bryanbrattlof.com>
Date: Fri, 12 Sep 2025 14:24:56 -0500
From: Bryan Brattlof <bb@...com>
To: Andrew Davis <afd@...com>
CC: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof
 Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Linus
 Walleij <linus.walleij@...aro.org>,
        Tony Lindgren <tony@...mide.com>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
        <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v6 3/4] arm64: dts: ti: k3-am62l: add initial
 infrastructure

On September 12, 2025 thus sayeth Andrew Davis:
> On 9/12/25 10:40 AM, Bryan Brattlof wrote:
> > From: Vignesh Raghavendra <vigneshr@...com>
> > 
> > Add the initial infrastructure needed for the AM62L. ALl of which can be
> > found in the Technical Reference Manual (TRM) located here:
> > 
> >      https://www.ti.com/lit/pdf/sprujb4
> > 
> > Signed-off-by: Vignesh Raghavendra <vigneshr@...com>
> > Signed-off-by: Bryan Brattlof <bb@...com>
> > ---
> > Changes in v4:
> >   - Corrected Copyright year
> >   - Used 'ranges' property in the fss{} node
> > 
> > Changes in v3:
> >   - Added more nodes now that the SCMI interface is ready
> > 
> > Changes in v1:
> >   - switched to non-direct links to TRM updates are automatic
> >   - fixed white space indent issues with a few nodes
> >   - separated out device tree bindings
> > ---
> >   arch/arm64/boot/dts/ti/k3-am62l-main.dtsi    | 603 +++++++++++++++++++++++++++
> >   arch/arm64/boot/dts/ti/k3-am62l-thermal.dtsi |  25 ++
> >   arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi  | 141 +++++++
> >   arch/arm64/boot/dts/ti/k3-am62l.dtsi         | 120 ++++++
> >   arch/arm64/boot/dts/ti/k3-am62l3.dtsi        |  67 +++
> >   arch/arm64/boot/dts/ti/k3-pinctrl.h          |   2 +
> >   6 files changed, 958 insertions(+)
> > 

...

> > diff --git a/arch/arm64/boot/dts/ti/k3-am62l.dtsi 
> > b/arch/arm64/boot/dts/ti/k3-am62l.dtsi
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..d058394a8d19d16f100cd87cf293c67bc189b475
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/ti/k3-am62l.dtsi
> > @@ -0,0 +1,120 @@
> > +// SPDX-License-Identifier: GPL-2.0-only or MIT
> > +/*
> > + * Device Tree Source for AM62L SoC Family
> > + * Copyright (C) 2025 Texas Instruments Incorporated - https://www.ti.com/
> > + *
> > + * Technical Reference Manual: https://www.ti.com/lit/pdf/sprujb4
> > + */
> > +

...

> > +		};
> > +	};
> > +
> > +	#include "k3-am62l-thermal.dtsi"
> 
> Not a fan of how this is included (yes I know it is done like this in
> a couple other places, those need fixed too), as we have better/standard
> ways to add nodes to nodes other than directly including a file with the
> node. The other issue is now the content of the file, including its #include
> lines are now inside this parent node.
> 
> This dtsi file should just start with "/ {" and add the extra node.
> 
> Also, isn't this broken out into a dtsi so we can handle versions of
> this device qualified for other thermal ranges without having to use
> a different parent device dtsi? If so then adding it directly to the
> base dtsi prevents that. Either all AM62L have this one thermal situation
> and then it doesn't need to be a dtsi, or this include should go into the
> board level as it is up to the given board what specific variant was chosen
> to be populated on that board type.
> 

Yeah I've noticed this as well. We have a few parts available in 
different packaging that have different maximum temp ratings. Ideally we 
should have some way to specify which package variant the board is using 
and include these thermal trip points for that package.

It does add more #includes into all of this but I guess if you've picked 
up on this as well I should probably look into seeing what we can do.

~Bryan