linux-kernel - Re: K3 AM62x SoC dts/dtsi include hierarchy and naming scheme

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230209153352.5tgkqe3xbby7pmju@polio>
Date:   Thu, 9 Feb 2023 09:33:52 -0600
From:   Nishanth Menon <nm@...com>
To:     Francesco Dolcini <francesco@...cini.it>
CC:     Vignesh Raghavendra <vigneshr@...com>,
        Dave Gerlach <d-gerlach@...com>,
        Tero Kristo <kristo@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <francesco.dolcini@...adex.com>
Subject: Re: K3 AM62x SoC dts/dtsi include hierarchy and naming scheme

On 19:44-20230207, Francesco Dolcini wrote:
> Hello Vignesh and all,
> I am writing you to get some clarification on the way the dts/dtsi
> naming and include hierarchy is designed for the TI K3 AM62x SOC family.
> 
> I read commit f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC").
> 
> I plan to send in the next few weeks some device tree files for
> inclusion in the kernel for SOM (or computer on module) based on the
> AM62x SOC.
> 
> I do envision to have the same dts file for different machine that are
> going to use different variant of the AM62x SOC, e.g. AM623 vs AM625 or
> just a different number of CPU cores, handling the differences at
> runtime (patching the .dtb in U-Boot?) to limit the maintenance effort and
> limit the amount of very similar dts files.
> 
> Said that we would prefer to stay close with what is considered/agreed
> to be the best approach.
> 
> Would something like that work or you would have a completely different
> expectation?
> 
> What would be the expected naming scheme? k3-am62-${board_name}.dts ?
> Something else?
> 
> k3-am625.dtsi defines the CPU nodes, why are these in a AM625 specific
> file? To me this looks like something that would be just the same with
> AM623, and at the same time AM6251 has only one core (see [0] Table 5-1).
> Am I missing something?
> 
> Thanks for your help,
> Francesco
> 
> [0] https://www.ti.com/lit/ds/symlink/am625.pdf 
> 

Typically, our strategy has been to introduce the superset device,
primarily because the device variants are quite a few, and without
actual users, it makes no sense to introduce a dtsi in kernel
in-anticipation of a potential board. Now that said, also keep in mind
the part number definitions do change depending on the market demands
over time (qualification requirements etc..), The initial device tree
was based on the definition we had at the time, as usual, over time,
definitions are changing :(.

Considering the potential combinatorial explosion if we are trying
to constantly catching up with variations of chip configurations as
market definitions change over time, we need to be a bit pragmatic in
the various dtsi files we introduce. With that in mind, If we have
just one board using the part variant, we should reduce the churn in
the tree by keeping the processor variation isolated to the board
(See arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi as an
example), on the other hand, the AM6251 (Single A53 variant) promises
to be a variant that will probably get used in multiple boards, I'd
suggest introducing a dtsi that is reused across the boards.

NOTE: this would be no different from similar strategies we have
followed in OMAP devices, for example.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D