[RFC PATCH 07/10] net: pcs: xpcs: add Rockchip RK3568 platform glue driver

[Coia Prant]

Andrew Lunn <andrew at lunn.ch> 于2026年7月16日周四 06:25写道：
>
> > The current design
> > ==================
> > The dependency chain I chose is simple:
> >
> >     stmmac (GMAC) -> pcs-handle -> XPCS node -> phys -> SerDes PHY
>
> Maybe we need to be more accurate here.
>
> In QSGMII I _think_ it is actually
>
> stmmac (GMAC) -> pcs-handle -> XPCS node -\
> stmmac (GMAC) -> pcs-handle -> XPCS node -------> phys -> SerDes PHY
> stmmac (GMAC) -> pcs-handle -> XPCS node -/ /
> stmmac (GMAC) -> pcs-handle -> XPCS node --/
>
> There are four instances of stmmac, four instances of the XPCS, which
> then all come together into one PHY.
>
> When using SGMII, does it look like this ?
>
> stmmac (GMAC) -> pcs-handle -> XPCS node -------> phys -> SerDes PHY
> stmmac (GMAC) -> pcs-handle -> XPCS node -------> phys -> SerDes PHY
> stmmac (GMAC) -> pcs-handle -> XPCS node -------> phys -> SerDes PHY
> stmmac (GMAC) -> pcs-handle -> XPCS node -------> phys -> SerDes PHY
>
> There are four of everything, all working independently.
>
> Is there 1 QSGMII PHY and 4 SGMII PHYs? Or does one of the 4 phys
> support SGMII + QSGMII, while 3 are SGMII only?
>
> > 2. User misconfiguration: even with reference counting, if a user sets
> >    `phys = <&combphy2 PHY_TYPE_SGMII>` for GMAC0 and
> >    `phys = <&combphy2 PHY_TYPE_QSGMII>` for GMAC1, the same PHY would
> >    be initialized in two different modes.
>
> I would hope that results in -EINVAL.
>
>   Andrew

Hi Andrew,

Thanks for the follow-up. I've dug through Rockchip's BSP and found the
exact device tree configurations they use for their EVBs, which I think
clears up the topology question.

For reference, here are the relevant BSP device tree files:
- QSGMII: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr6.1/arch/arm64/boot/dts/rockchip/rk3568-evb2-lp4x-v10.dtsi#L185
- SGMII: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr6.1/arch/arm64/boot/dts/rockchip/rk3568-evb5-ddr4-v10.dtsi#L208

Hardware topology confirmed
===========================
The BSP shows that for RK3568, the hardware is indeed a shared resource.

One important clarification: the XPCS block has four logical entities
(corresponding to the four MII ports, pcs-mii at 0..3). In my driver, these
are all attached to the same MDIO bus and distinguished by address.

To clarify the PHY topology: there is only one physical SerDes PHY on
RK3568 (combphy1_usq). In QSGMII mode, this single PHY provides four
logical ports via time-division multiplexing. In the device tree, all
four ports are attached to the same MDIO bus and distinguished by
address (pcs-mii at 0..3).

So it's not "4 PHYs" but "1 PHY with 4 logical ports", all accessible
through the same MDIO bus with different address. The BSP EVB2
configuration confirms this:
both gmac0 and gmac1 reference the same combphy1_usq with
PHY_TYPE_QSGMII.

To clarify the difference between SGMII and QSGMII:
- SGMII is a single serial link at 1.25 Gbaud, providing one Gigabit port.
- QSGMII is a 5 Gbaud SerDes protocol that multiplexes four SGMII links
  onto the same physical lanes.

So for RK3568: one PHY for SGMII, or one PHY for QSGMII (both GMACs share
the same PHY, each using a dedicated logical port).

For SGMII mode, only one of these ports can be used at a time, and only
one GMAC can use the SGMII link. The BSP EVB5 configuration shows this
clearly: gmac0 uses SGMII, while gmac1 falls back to RGMII.

For QSGMII mode, the BSP EVB2 configuration shows both gmac0 and gmac1
configured with phy-mode = "qsgmii", both referencing the same combphy1_usq
as their phys. This confirms your diagram: multiple MACs converge on a
single SerDes PHY via the XPCS, with the four logical ports time-division
multiplexed onto the single PHY.

Why this matters for the design
===============================
This BSP evidence supports my current design where the XPCS node owns
the SerDes PHY:

1. It matches the hardware: the XPCS is the central multiplexer.
   Placing the PHY under the XPCS node in the device tree accurately
   reflects this hardware reality.

2. It's the only viable path for QSGMII: as the BSP shows, QSGMII
   requires multiple MACs to share one PHY. If the PHY were owned by the
   MAC driver (dwmac-rk), we'd need complex refcounting and cross-MAC
   coordination. The XPCS-owner model solves this cleanly by making the
   XPCS the single point of control.

3. It aligns with the BSP's own logic: even though the BSP uses a
   non-standard property (rockchip,xpcs), the underlying idea is the
   same: the MACs point to a shared XPCS node, which then manages the
   PHY. My design just does this using the standard kernel frameworks.

So, I believe the current design is correct. It's based on the hardware
reality confirmed by Rockchip's own BSP, and it uses the standard kernel
interfaces to do so. I'm happy to keep the XPCS as the owner of the
SerDes PHY in v2 if you agree.

Thanks,
Coia