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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dts: type-c dual data-role contradicts usb controller host mode
- [Medium] dts: parallel dapm routing bypasses headphone amplifier
--

commit 9f35004d471e8daa3f6d6ace7fb6441749b6b25d
Author: BG9OXA <bg9oxa@163.com>

arm64: dts: rockchip: add ALIENTEK QuarkPi-CA2

This commit adds the device tree for the RK3588S-based ALIENTEK QuarkPi-CA2
board. It configures memory, networking, video outputs, and USB interfaces.

> 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..d9d679d99266f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-quarkpi-ca2.dts

[ ... ]

> +	husb311: typec-port@4e {
> +		compatible = "hynetek,husb311", "richtek,rt1711h";
> +		reg = <0x4e>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PA4 IRQ_TYPE_LEVEL_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usbc0_int>;
> +		vbus-supply = <&vbus5v0_typec>;
> +
> +		usb_con: connector {
> +			compatible = "usb-c-connector";
> +			label = "USB-C";
> +			power-role = "dual";
> +			data-role = "dual";

[Severity: Medium]
Does this type-C connector configuration contradict the USB controller mode?

This connector advertises dual data-role capability to the Type-C subsystem,
which might negotiate device mode with a connected partner. However, looking
at usb_host0_xhci later in this file, the underlying controller is hardcoded
to host mode (dr_mode = "host") and lacks a usb-role-switch property.

If device mode is negotiated here, will this cause the USB link to fail
completely since the controller cannot switch modes?

> +			try-power-role = "sink";
> +			source-pdos = <0x401912c>;
> +			sink-pdos = <0x4019064>;

[ ... ]

> +	analog_sound: analog-sound {
> +		compatible = "simple-audio-card";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hp_det &hp_con>;
> +		simple-audio-card,name = "QuarkPi-CA2 ES8388";
> +		simple-audio-card,format = "i2s";
> +		simple-audio-card,bitclock-master = <&sound_cpu>;
> +		simple-audio-card,frame-master = <&sound_cpu>;
> +		simple-audio-card,mclk-fs = <256>;
> +		simple-audio-card,aux-devs = <&hp_amp>;
> +		simple-audio-card,hp-det-gpios = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
> +		simple-audio-card,pin-switches = "Headphones";
> +		simple-audio-card,widgets =
> +			"Headphone", "Headphones",
> +			"Microphone", "Headset Mic",
> +			"Microphone", "Main Mic";
> +		simple-audio-card,routing =
> +			"Headphones", "LOUT1",
> +			"Headphones", "ROUT1",

[Severity: Medium]
Does this DAPM audio graph routing logically bypass the headphone amplifier?

This configuration connects the raw codec output (LOUT1/ROUT1) directly to
Headphones, simultaneously with the headphone amplifier's output (Headphone
Power OUTL/OUTR) on the lines immediately following this.

Will this contradictory parallel routing allow the DAPM subsystem to bypass
the amplifier entirely during playback, potentially leaving the amplifier
powered off and resulting in no or faint audio?

> +			"Headphones", "Headphone Power OUTL",
> +			"Headphones", "Headphone Power OUTR",
> +			"Headphone Power INL", "LOUT1",
> +			"Headphone Power INR", "ROUT1",
> +			"LINPUT1", "Headset Mic",

[ ... ]

> +&usb_host0_xhci {
> +	dr_mode = "host";
> +	status = "okay";

[Severity: Medium]
As mentioned above for the usb_con node, the USB controller is forced into
host-only mode here and lacks a usb-role-switch property. Does this need
to support dual-role to match the connector's data-role capability?

> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;

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