[PATCH net-next v6 05/11] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes

[Coia Prant]

<sashiko-bot at kernel.org> 于2026年9月16日周三 22:50写道：
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] dts: incorrect fixed-clock modeling for XPCS generated clock
> --
>
> commit 18edca8a678c045ba2fe3270b1f3ca0505b94baa
> Author: Coia Prant <coiaprant at gmail.com>
>
> arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
>
> This commit adds the DesignWare XPCS node and its sub-nodes for the RK3568
> SoC, mapping it to the APB3 bus. It also adds two fixed-clock nodes to
> provide reference clocks for the GMACs when operating with XPCS.
>
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > index 3bc653f027f1f..227d03e336043 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> [ ... ]
> > +     clk_gmac0_xpcs_mii: clock-xpcs-gmac0 {
> > +             compatible = "fixed-clock";
> > +             clock-frequency = <125000000>;
> > +             clock-output-names = "clk_gmac0_xpcs_mii";
> > +             #clock-cells = <0>;
> > +     };
>
> [Severity: Medium]
> Does modeling the XPCS-generated clock as an independent fixed-clock bypass
> power management and dependency tracking?
>
> Because the clock framework has no dependency link to the XPCS power domain
> (RK3568_PD_PIPE), it seems it will switch the GMAC to this clock even if the
> XPCS block has not yet probed and is still power-gated.
>
> When the GMAC device uses this via assigned-clocks, the driver core switches
> the parent clock before the GMAC probe function is executed. If XPCS is
> absent or uninitialized, could switching to this unpowered clock hang the
> system at boot time?
>
> Would it be safer to have the XPCS or SerDes node itself act as the clock
> provider so the clock framework properly tracks power domain lifecycles?
>
> > +
> > +     clk_gmac1_xpcs_mii: clock-xpcs-gmac1 {
> > +             compatible = "fixed-clock";
> > +             clock-frequency = <125000000>;
> > +             clock-output-names = "clk_gmac1_xpcs_mii";
> > +             #clock-cells = <0>;
> > +     };
>
> [Severity: Medium]
> Is this second XPCS-generated MAC clock subject to the same decoupling from
> the XPCS power domain as the first clock?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260915123802.1561724-1-coiaprant@gmail.com?part=5

Thanks for the review.

The dependency is enforced by EPROBE_DEFER instead. If the XPCS has not
probed yet, pxpcs->bus is NULL, xpcs_rk_create() returns -EPROBE_DEFER,
rk_pcs_init() propagates it, and the GMAC probe fails and retries. The
GMAC cannot reach a state where it uses the XPCS clock while the XPCS
is unpowered.

On the assigned-clock-parents path: fixed-clock has no provider driver,
so the clock framework registers it during early init. Switching the
parent to it only updates the CCF parent pointer and does not touch any
hardware. The actual clk_prepare_enable() happens in the GMAC probe,
by which time the XPCS is ready.

Making XPCS a clock provider would require a clock controller driver
for a block that has no controllable clock output. fixed-clock is the
correct description for a fixed 125 MHz output.

Thanks,
Coia