Re: [PATCH 2/2] arm64: dts: rockchip: add ALIENTEK QuarkPi-CA2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] dts: copy-paste error in RK806 DVS null pin configuration
- [Medium] dts: es8388 node forces software match via incompatible schemas
- [Low] dts: outdated architectural comment contradicts USB3/Type-C implementation
--

commit cc24bb0e57d3815603a751daab32d79cde59ecb8
Author: BG9OXA <bg9oxa@163.com>
Date:   Sun Sep 27 12:37:06 2026 +0000

    arm64: dts: rockchip: add ALIENTEK QuarkPi-CA2

This commit adds a new device tree for the ALIENTEK QuarkPi-CA2 SBC, based on
the RK3588S SoC. It enables core functionalities like UART, eMMC, Ethernet,
HDMI, USB host ports, and analog audio.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-quarkpi-ca2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-quarkpi-ca2.dts
> new file mode 100644
> index 0000000000000..f598af7fe2749
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-quarkpi-ca2.dts

[ ... ]

> +		rk806_dvs1_null: dvs1-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};
> +
> +		rk806_dvs2_null: dvs2-null-pins {
> +			pins = "gpio_pwrctrl2";
> +			function = "pin_fun0";
> +		};

[Severity: High]
Does this cause a pinmux collision during initialization? The pins property
for rk806_dvs1_null duplicates "gpio_pwrctrl2" instead of requesting
"gpio_pwrctrl1". During boot, the pinctrl subsystem will likely throw a
collision error when binding the PMIC pins, potentially leaving the system
unbootable or causing dependent regulators to defer probe indefinitely.

[ ... ]

> +/*
> + * USB3 —— Type-C 口（走 usbdp_phy0 + u2phy0）
> + *
> + * 主线没有 HUSB311（TCPC）驱动，Type-C 的插入方向/角色切换（CC 检测）拿不到，
> + * 故按 rock-5c 的写法固定成 host 模式，不做 OTG/DP altmode。
> + * VBUS 由 vbus5v0_typec 控制（GPIO = gpio1 PC5，厂商 dtb 实测值）。
> + */
> +&u2phy0 {

[Severity: Low]
Is this comment accurate for the current state of the device tree? It claims
no TCPC driver is available and no DP altmode is configured, but this directly
contradicts the husb311@4e node and dp0 configuration implemented elsewhere
in this file.

[ ... ]

> +	es8388: audio-codec@11 {
> +		/* ⭐⭐⭐ 2026-09-26 关键修正：把 everest,es8323 放在**第一位**。
> +		 *   原因（读驱动源码 + 板上模块实证）：
> +		 *   - 主线 es8328.c 是**简化版**（888 行），es8323.c 是**完整版**（791 行，
> +		 *     有 set_dai_fmt / set_dai_sysclk / pcm_hw_params + coeff_div 系数表）。
> +		 *   - compatible 列表**按顺序匹配**：'everest,es8388' 排前面会被 es8328 抢走，
> +		 *     所以必须把 es8323 提到第一位才能让完整版驱动绑定。

[ ... ]

> +		 */
> +		compatible = "everest,es8323", "everest,es8388";
> +		reg = <0x11>;

[ ... ]

> +		AVDD-supply = <&vcc_3v3_s0>;
> +		DVDD-supply = <&vcc_1v8_s0>;
> +		HPVDD-supply = <&vcc_3v3_s0>;
> +		PVDD-supply = <&vcc_3v3_s0>;
> +		#sound-dai-cells = <0>;
> +	};

[Severity: Medium]
Will this cause device tree schema validation (dtbs_check) to fail? By placing
"everest,es8323" first to intentionally trick the kernel into loading a
different software driver, the tooling will map this node to es8316.yaml. That
schema strictly rejects capitalized properties like AVDD-supply, resulting in
schema errors.

Could we avoid overriding the exact hardware match string here, as device trees
are meant to describe hardware rather than configure specific driver behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/179051262312.4055.11698105707712320261@163.com?part=2