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

Andrew Lunn andrew at lunn.ch
Wed Jul 15 15:25:49 PDT 2026


> 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



More information about the Linux-rockchip mailing list