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

Date:   Mon, 13 Feb 2023 19:36:55 +0530
From:   "Raghavendra, Vignesh" <vigneshr@...com>
To:     Francesco Dolcini <francesco@...cini.it>,
        Nishanth Menon <nm@...com>
CC:     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 2/10/2023 11:35 PM, Francesco Dolcini wrote:
[...]

>>>
>>
>> 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 :(.
> 	
> ... and from my point of view this is normal and fine. All good :-)
> 
>> 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.
> 
> Our current plan is to have multiple SKUs that will differentiate by the
> specific SoC SKU, not sure if this was clear to you, as an example we
> will have.
> 
> for board in variant1 variant2 variant3
>   k3-am6251-${board}.dts
>   k3-am6252-${board}.dts
>   k3-am6254-${board}.dts
>   k3-am6231-${board}.dts
>   k3-am6232-${board}.dts
>   k3-am6234-${board}.dts
> 
> that are just the same apart the AM62x SKU.
> Do you expect something like that (18 .dts files, in this example) ?
> 
> To me this is absolutely fine, I just want to be sure this is what you
> expect.

I am not sure if we need 18 files, IMO having dts for superset SoC per
board variant for each SoC variant is sufficient:

for board in variant1 variant2 variant3
   k3-am625-${board}.dts (assume k3-am6254-${board}.dts)
   k3-am623-${board}.dts (assume k3-am6234-${board}.dts)

And then fixup num CPUs from U-Boot as per SoC detection as long as
board remains **exactly same** as super set.

This will limit .dts files to 6. Also limits bootloader's role to just
disabling CPU cores instead of fiddling around with too many non
transparent DT fixups.

Nishanth: feel free to chime in if you have different opinion.


> 
> For example we do have these dts boards file here
> 
> arch/arm64/boot/dts/freescale/imx8mm-verdin-*.dts
> 
> and the FDT is patched in U-Boot in
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/imx8m/soc.c#L1245
> 
> with the this approach we have 4 dts files instead of the 16 if we would
> use the exact SOC SKU variant [0].
> 
> Francesco
> 
> [0] https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
> 


Regards
Vignesh