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

Albert Yang
2025-09-25T09:09:25Z

Hi Arnd,

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

You are absolutely right about the soc@lists.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@lists.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@lists.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@lists.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@lists.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