Re: [PATCH v9 5/8] riscv: dts: spacemit: k1: add SD card controller and pinctrl support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] DT Node Sorting Violation in k1.dtsi
- [Low] Hardware Semantic Mismatch / Undocumented Hardware Quirk
--

commit b041436345c6321304b2ed59c04953c7c67e6e5f
Author: Iker Pedrosa <ikerpedrosam@gmail.com>

riscv: dts: spacemit: k1: add SD card controller and pinctrl support

This commit adds the SD card controller infrastructure for the SpacemiT
K1 SoC. It includes the sdhci0 controller definition along with the
corresponding mmc1 pinctrl configurations for standard and UHS modes.

> Add sdhci0 controller definition with clocks, resets and interrupts
> Add mmc1_cfg pinctrl for 3.3V standard SD operation

Does this hardware route the SDH0 controller logic to the MMC1 physical
pads?

Since the patch defines the sdhci0 controller (using base address
0xd4280000, CLK_SDH0, and RESET_SDH0) but adds pinctrl configurations
referencing mmc1_* pins, it appears there might be a cross-routing
hardware quirk.

Could this counter-intuitive hardware behavior be explicitly documented
in the commit message or through inline comments to prevent future
maintainability confusion?

> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> index 24becab4c9594..6ded5c06b7975 100644
> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
[ ... ]
> @@ -1226,6 +1226,19 @@ emmc: mmc@d4281000 {
>  				interrupts = <101>;
>  				status = "disabled";
>  			};
> +
> +			sdhci0: mmc@d4280000 {

This isn't a bug, but should the sdhci0 node be placed before the
emmc node? 

Device tree conventions dictate that nodes should be ordered by their
unit-address in ascending order, so mmc@d4280000 would typically come
before mmc@d4281000 in the storage-bus node.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511-orangepi-sd-card-uhs-v9-0-ae48c0b2b2cf@gmail.com?part=5