[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