linux-kernel - Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

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: <422deb4d-db29-48c1-b0c9-7915951df500@app.fastmail.com>
Date: Thu, 27 Mar 2025 09:18:42 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Krzysztof Kozlowski" <krzk@...nel.org>,
 "Peter Chen" <peter.chen@...tech.com>, "Marc Zyngier" <maz@...nel.org>
Cc: soc@...nel.org, "Rob Herring" <robh@...nel.org>, krzk+dt@...nel.org,
 "Conor Dooley" <conor+dt@...nel.org>,
 "Catalin Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, cix-kernel-upstream@...tech.com,
 marcin@...zkiewicz.com.pl, kajetan.puchalski@....com,
 "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
 "Fugang . duan" <fugang.duan@...tech.com>
Subject: Re: [PATCH v5 5/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

On Thu, Mar 27, 2025, at 08:16, Krzysztof Kozlowski wrote:
> On 27/03/2025 07:44, Peter Chen wrote:
>>>> On 25-03-25 10:52:10, Marc Zyngier wrote:
>> 
>> Thanks for your interesting of our platform, and your comments
>> help us a lot. But I don't think it wastes reviewers and maintainers
>> time, a clean patch set saves everyone's time during upstream process.
>> 
>> For how to organize the patch set for SoC, Krzysztof gave good summary
>> at [1]. We are going on upstream [2], this patch set is just a start
>> and base but not like you said for marketing purpose.
>
>
> I do not think I suggested in [1] to ever send new SoC containing only
> CPUs and interrupt controller, without even serial. My instruction [1]
> was how to organize it. The DTS can be even fully complete, see the
> upstreaming example I have been using all the time - Qualcomm SM8650:
>
> https://lore.kernel.org/all/20231124-topic-sm8650-upstream-dt-v4-0-e402e73cc5f0@linaro.org/

It is easier if there are other SoCs in the same family that are
already supported than an entire new platform, but we have certainly
done it for new SoC families as well.

> Entire SoC sent to mailing list on the day one of public release of that
> flagship Qualcomm SoC. The SoC DTSI and board DTS have almost complete
> picture, except few trickier pieces... but it even has full display and
> GPU! Plus, as I explained on my email on samsung-soc, that DTS/DTSI
> patchset references all other bindings with their state, so SoC
> maintainers can understand what is the overall progress and what will be
> the result in DT schema checks, if they apply the patchset.
>
> The minimum, absolute minimum submission is with the serial nodes. I
> would prefer to have some storage or any other interface as well, but
> that's fine.

Agreed. The usual arrangement for a new SoC family is to have
the minimum set of drivers (uart, clk, pinctrl, regulator,
iommu, irqchip) along with the DT bindings and the dts files
in one branch and have that go through the SoC tree as part of
the soc/newsoc branch. It sounds like in this case we only need
uart and a mailbox since the rest are shared with existing
firmware based drivers, so this isn't even the worst case
but still requires some coordination between subsystem maintainers
to ensure that all patches have been properly reviewed before
I merge them.

Any peripheral drivers that are not essential for booting
(typically mmc, ufs, spi, i2c, gpu, sound, pci) can get
submitted at the same time, as there is no dependency on
the platform being merged first.

     Arnd