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

[Albert Yang]

Hi Arnd,

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

You are absolutely right about the soc at 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 at 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 at 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 at 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 at 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