Re: [PATCH v4 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The 25 MHz reference clock `clk_mac_refout` for the YT8531 Ethernet PHY is not enabled by the driver in RGMII mode, leaving the PHY without a clock.
- [Medium] DisplayPort Alt Mode VDO advertises all capabilities and reserved bits as 1 (`0xffffffff`).
--

--- Patch [2]: [PATCH v4 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO ---
commit e58918599e73710e92e762060f9447be7d1a658e
Author: Jiaxing Hu <gahing@gahingwoo.com>

arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO

This commit adds support for the ArmSoM CM5 (an RK3576 compute module) and
its CM5-IO carrier board. It includes configurations for the RK806 PMIC,
Ethernet MAC, WiFi/Bluetooth, USB, HDMI, and various other peripherals.

> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
> new file mode 100644
> index 0000000000000..40d9be0c69f42
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts

[ ... ]

> @@ -198,22 +198,15 @@ usbc0: usb-typec@22 {
>  			source-pdos =
>  				<PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
>  
>  			altmodes {
>  				displayport {
>  					svid = /bits/ 16 <0xff01>;
>  					vdo = <0xffffffff>;

[Severity: Medium]
Is this vdo value correct? Setting the DisplayPort Alt Mode VDO to all 1s
(0xffffffff) asserts all possible DisplayPort capabilities and sets reserved
bits to 1.

Could this cause connected hosts to mistakenly detect the board as a
DisplayPort sink (phantom monitor) and fail alt mode negotiations?

>  				};
>  			};

[ ... ]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
> new file mode 100644
> index 0000000000000..91d7918c29c5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi

[ ... ]

> @@ -138,20 +138,15 @@ &cpu_l3 {
>  /*
>   * GMAC0 drives an on-module MotorComm YT8531. The PHY has no local crystal, so
>   * it relies on the SoC 25 MHz reference: clk_mac_refout (REFCLKO25M_GMAC0_OUT)
>   * has to be named on the gmac node for dwmac-rk to enable it, and
>   * ethm0_clk0_25m_out routes it to the pad.
>   */
>  &gmac0 {
>  	phy-mode = "rgmii-id";
>  	clock_in_out = "output";
>  	clocks = <&cru CLK_GMAC0_125M_SRC>, <&cru CLK_GMAC0_RMII_CRU>,
>  		 <&cru PCLK_GMAC0>, <&cru ACLK_GMAC0>,
>  		 <&cru CLK_GMAC0_PTP_REF>, <&cru REFCLKO25M_GMAC0_OUT>;
>  	clock-names = "stmmaceth", "clk_mac_ref", "pclk_mac", "aclk_mac",
>  		      "ptp_ref", "clk_mac_refout";

[Severity: High]
Will the PHY receive its reference clock with this configuration? 

The commit message notes that the YT8531 lacks a crystal and relies on the
SoC 25 MHz reference output described here as clk_mac_refout. However, the
device tree specifies phy-mode = "rgmii-id", and dwmac-rk only parses and
enables clk_mac_refout if the PHY mode is RMII.

Since the clock is ignored in RGMII mode, does the PHY remain unclocked and
break Ethernet initialization?

>  	phy-handle = <&rgmii_phy0>;
>  	phy-supply = <&vcc_3v3_s3>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717065903.2629399-1-gahing@gahingwoo.com?part=2