Re: [PATCH V5 6/6] arm64: dts: rockchip: Add Anbernic RG Vita-Pro

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] USB Type-C source PDO advertises 3A, exceeding the SGM41542 charger's OTG boost capability.
- [Medium] Missing SPI child device node prevents userspace control of the analog joysticks.
- [Medium] Ghost HDMI configuration exists for a device that lacks an HDMI port.
--

commit 9a10b9538aecda51a72bf0a4aa5290b693df3a4b
Author: Chris Morgan <macromorgan@hotmail.com>
arm64: dts: rockchip: Add Anbernic RG Vita-Pro

This commit adds the device tree for the Anbernic RG Vita-Pro, based on the
Rockchip RK3576. It defines the hardware configuration including the display,
buttons, analog joysticks, battery, and USB-C.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts b/arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-anbernic-rg-vita-pro.dts
[ ... ]
> +	hdmi-con {
> +		compatible = "hdmi-connector";
> +		type = "c";
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
[ ... ]
> +&hdmi {
> +	status = "okay";
> +};

[Severity: Medium]
The commit message lists "DisplayPort over USB-C alt-mode" for video output
but does not mention an HDMI port. Does this device physically have an HDMI
port, or is this a leftover ghost configuration?

Leaving the HDMI pipeline enabled might waste resources or cause audio/display
routing confusion in userspace if the port doesn't exist on the hardware.

[ ... ]
> +	sgm41542: charger@3b {
> +		compatible = "sgmicro,sgm41542";
> +		reg = <0x3b>;
[ ... ]
> +		regulators {
> +			vbus5v0_typec: otg-vbus {
> +				regulator-name = "vbus5v0_typec";
> +				regulator-max-microvolt = <5000000>;
> +				regulator-min-microvolt = <5000000>;
> +
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
[ ... ]
> +	husb311: typec-portc@4e {
> +		compatible = "hynetek,husb311", "richtek,rt1711h";
[ ... ]
> +		vbus-supply = <&vbus5v0_typec>;
> +
> +		connector {
> +			compatible = "usb-c-connector";
> +			label = "USB-C";
> +			data-role = "dual";
> +			op-sink-microwatt = <10000000>;
> +			power-role = "dual";
> +			try-power-role  = "sink";
> +
> +			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
> +				     PDO_FIXED(9000, 2000, PDO_FIXED_USB_COMM)>;
> +			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;

[Severity: High]
Does advertising 3A for the source PDO risk overloading the SGM41542 charger?

The husb311 Type-C port advertises 5V at 3A to connected sinks, but its
vbus-supply is powered by the sgm41542 charger's OTG boost converter.
According to the sgm41542 driver, its maximum OTG output capability is
physically limited to 2A (2,000,000 uA).

If a sink attempts to draw the advertised 3A, could it cause an overcurrent
fault and collapse the VBUS rail?

[ ... ]
> +&spi1 {
> +	num-cs = <1>;
> +	pinctrl-0 = <&spi1m2_pins>, <&spi1m2_csn0>;
> +	status = "okay";
> +
> +	/* SPI controlled MCU for joystick and joystick LEDs. */
> +};

[Severity: Medium]
The commit message notes the analog joysticks are "controlled via userspace,"
but the &spi1 node doesn't have a child device node (such as spidev).

Without a child node, the kernel SPI subsystem will not instantiate an SPI
device. How will userspace communicate with the joysticks if the device node
is missing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604220802.119107-1-macroalpha82@gmail.com?part=6