linux-kernel - Re: [PATCH 0/9] arm64: introduce Black Sesame Technologies C1200 SoC and CDCU1.0 board

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: <f64b0e00-1c30-47a1-b6b0-1bc28cc7f8ac@app.fastmail.com>
Date: Thu, 25 Sep 2025 15:38:44 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ulf Hansson" <ulf.hansson@...aro.org>,
 "yangzh0906@...ndersoft.com" <yangzh0906@...ndersoft.com>
Cc: "Adrian Hunter" <adrian.hunter@...el.com>,
 bst-upstream <bst-upstream@...ai.top>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Conor Dooley" <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 "gordon.ge" <gordon.ge@....ai>, krzk+dt@...nel.org,
 "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 "linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
 "Rob Herring" <robh@...nel.org>, "Will Deacon" <will@...nel.org>
Subject: Re: [PATCH 0/9] arm64: introduce Black Sesame Technologies C1200 SoC and
 CDCU1.0 board

On Thu, Sep 25, 2025, at 15:34, Ulf Hansson wrote:
> On Thu, 25 Sept 2025 at 14:12, Albert Yang <yangzh0906@...ndersoft.com> wrote:
>> On Thu, Sep 25, 2025 at 05:03:57PM +0800, Albert Yang wrote:
>> Subject: Re: [PATCH] splitting SoC and MMC parts
>>
>> Hi Arnd,
>>
>> I may have missed an important detail in my previous note. If I split
>> out the MMC-related patches and submit only the SoC parts first, I
>> cannot validate the SoC on real hardware: both the kernel and the root
>> filesystem live on the MMC device. Without the MMC stack (DT bindings
>> and the controller driver), the board does not boot to userspace, so I
>> cannot properly verify the SoC/DT changes in isolation.
>
> At least to me, I would not consider that a problem. As long as you
> can test the pieces together "manually" that's fine, I think.
>
> I mean, the platform was not supported in the first place, so it's not
> like we would be introducing a regression - or break something, right?

Agreed, it's rare for newly added platforms to immediately have
everything working, and we can still fix things if they don't.

It's also possible to test userspace by using a standalone
initramfs with a login shell or an automated test suite, but
I don't require that.

     Arnd