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: <20250926014807.2919409-1-yangzh0906@thundersoft.com>
Date: Fri, 26 Sep 2025 09:48:07 +0800
From: Albert Yang <yangzh0906@...ndersoft.com>
To: arnd@...db.de
Cc: 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,
	ulf.hansson@...aro.org,
	will@...nel.org,
	yangzh0906@...ndersoft.com
Subject: Re: [PATCH 0/9] arm64: introduce Black Sesame Technologies C1200 SoC and CDCU1.0 board

On Thu, Sep 25, 2025 at 03:38:44PM +0200, Arnd Bergmann wrote:
> 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:
> >>
> >> 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.

Hi Arnd, Ulf,

Thank you both for the clarifications.

Understood regarding validation expectations. I'll proceed with the split:
  * v5 SoC series (no MMC binding/driver, no mmc nodes in dtsi)
  * Separate MMC series (binding + driver) to linux-mmc
  * Follow-up enable patch once the driver lands


If any critical fix is found while iterating on the MMC series, I'll send
a follow-up patch depending on timing.

I'll move ahead with preparing v5 accordingly.

Thanks again for the guidance.

Best regards,
Albert Yang