[PATCH net-next v8 05/11] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Sun Sep 20 05:53:18 PDT 2026
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] devicetree: fixed-clock anti-pattern for internal XPCS clocks
- [Low] devicetree: missing required phys property in xpcs node
--
commit 752959013e963f31a1ffc2b59a8a556bc481a7c3
Author: Coia Prant <coiaprant at gmail.com>
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
This commit adds the XPCS device node and associated fixed-clock nodes to
the RK3568 SoC device tree to support 1000BASE-X, SGMII, and QSGMII
interfaces. The XPCS node requires board-level activation and PHY
assignments, while the fixed-clock nodes are introduced to provide a
static 125 MHz reference.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -110,6 +110,51 @@ sata0: sata at fc000000 {
> status = "disabled";
> };
>
> + xpcs: ethernet-pcs at fda00000 {
> + compatible = "rockchip,rk3568-xpcs";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0xfda00000 0x0 0x200000>;
> + clocks = <&cru PCLK_XPCS>, <&cru CLK_XPCS_EEE>;
> + clock-names = "csr", "eee";
> + power-domains = <&power RK3568_PD_PIPE>;
> + status = "disabled";
[Severity: Low]
The commit message states that "dtbs_check only validates required properties
for enabled nodes, so the SoC dtsi does not provide phys/phy-names". Is this
assumption accurate?
dt-schema evaluates all nodes against the required list regardless of the
status property, unless the schema explicitly conditions the requirement. Will
this omission cause make dtbs_check to throw validation errors for all RK3568
boards that leave the XPCS node disabled?
[ ... ]
> + clk_gmac0_xpcs_mii: clock-xpcs-gmac0 {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac0_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
Does using a fixed-clock here accurately model the hardware?
Since the 125 MHz reference clock is generated internally by the XPCS or
Combo PHY, representing it as a fixed root oscillator appears to violate
devicetree hardware modeling principles.
Should the IP block that actually generates this clock act as the clock
provider, instead of injecting a dummy fixed-clock node into the device tree?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260919125119.2107089-1-coiaprant@gmail.com?part=5
More information about the linux-phy
mailing list