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