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

Message-ID: <CAPDyKFp3onTDGgygvOrK-G40w4mSx4S5=PbdZ+26hsQ+nPVRSA@mail.gmail.com>
Date: Thu, 25 Sep 2025 15:34:22 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Albert Yang <yangzh0906@...ndersoft.com>
Cc: arnd@...db.de, adrian.hunter@...el.com, bst-upstream@...ai.top, 
	catalin.marinas@....com, conor+dt@...nel.org, devicetree@...r.kernel.org, 
	gordon.ge@....ai, krzk+dt@...nel.org, krzysztof.kozlowski@...aro.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-mmc@...r.kernel.org, robh@...nel.org, will@...nel.org
Subject: Re: [PATCH 0/9] arm64: introduce Black Sesame Technologies C1200 SoC
 and CDCU1.0 board

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?

>
> Would you prefer that I:
> - keep the MMC pieces in the same series for initial bring-up; or
> - validate everything locally, then send only the SoC/DT parts first and
>   follow up with the MMC binding/driver as a separate series?
>
> I’m not entirely sure which approach best matches the normal workflow,
> so your guidance would be appreciated. I can proceed whichever way you
> think is most appropriate.

I think doing things in parallel would be the best/fastest way
forward. Validating locally and sending the pieces upstream to
different subsystems.

>
> Thanks for the review and suggestions.
>
> Best regards,
> Albert

Kind regards
Uffe