Message-ID: <20250925090412.2068216-1-yangzh0906@thundersoft.com>
Date: Thu, 25 Sep 2025 17:03:57 +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,
	soc@...ts.linux.dev,
	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

Hi Arnd,

Thanks a lot for the clear guidance and for looking at the series.

You are absolutely right about the soc@...ts.linux.dev submission. The 
inclusion was an unintended side effect of using:
    b4 prep --auto-to-cc
I mistakenly trusted the automatically generated list without pruning it.
I'll manually adjust the To/Cc going forward and only add soc@...ts.linux.dev 
once the SoC base is ready for your tree.

> I'd be happy to merge the actual SoC portions in arch/arm64 as they
> do seem to be ready, and for a new SoC support I sometimes merge
> in required driver changes with a subsystem (uart, irqchip, clk, ...)
> maintainer's Ack as well. However the MMC driver portions in patches
> 4-6 don't really fall into that category, as there has not been
> any Ack for this version yet, and MMC is not one of the subsystems
> we normally make this exception for.

Understood. Not all patches in the series have Acked-by/Reviewed-by yet 
(especially the MMC related ones), so I'll restructure for v5 per your 
recommendation instead of waiting for every Ack before resubmitting.

> Given the current timing, I would suggest that you respin the
> series for 6.19 once 6.18-rc1 is out and leave out those three
> patches in the submission to soc@...ts.linux.dev.

Will do. Planned split for v5:

  Series A (SoC foundation) -> target: arm-soc (NOT including MMC driver patches)
    1. Vendor prefix dt-binding
    2. SoC / board dt-bindings  
    3. ARCH_BST Kconfig/Makefile enablement
    4. Initial dtsi/dts (without the sdhci/mmc nodes, see note below)
    5. MAINTAINERS entry
    6. (Optional/minimal) defconfig updates – avoiding enabling symbols 
       that rely on not-yet-merged drivers

  Separate MMC series -> target: linux-mmc (cc: devicetree, you, lists)
    a. MMC controller dt-binding (current patch 4)
    b. MMC driver patches (current patches 5–6)

> If the MMC driver gets merged for 6.19, it's ok to keep the
> sdhci device nodes in the dtsi file here, but to make things
> easier, you can also leave out those nodes in the initial
> submission and send this as a follow-up patch to
> soc@...ts.linux.dev once the driver is actually merged.

My preference is to OMIT the sdhci/mmc nodes entirely in v5 to keep the 
base SoC description minimal and avoid orphan nodes. If you would rather 
I keep them present but with status = "disabled", please let me know and 
I will adjust accordingly before sending.

After the MMC driver lands, I'll send a follow-up patch adding the 
sdhci/mmc nodes to the SoC dtsi.

I will also:
  - Ensure vendor prefix binding precedes its usage
  - Trim any defconfig entries referencing the unmerged driver
  - Remove soc@...ts.linux.dev from To/Cc until the SoC subset is 
    really intended for your tree

Does this split and sequencing match your expectations? Any further 
adjustments you'd like before I prepare v5?

Thanks again for the review and direction.

-- 
Best regards,
Albert Yang

Powered by blists - more mailing lists