Andrew Lunn [off-list ref] 于2026年7月16日周四 03:57写道：

quoted

This is intentional. The SerDes is attached to the XPCS node because
on RK3568, a single SerDes serves all four XPCS MII ports in QSGMII
mode.

This is not the only device supporting QSGMII, and so the issues you
are addressing should be common to many QSGMII implementations.

Please take a step back. What would a generic solution look like?

Can the reference counting be placed into the core somewhere? The
common clock framework allows a clock to be enabled and disabled by
multiple consumers, and the core clock code does the reference
counting, only calling into the clock driver when state change is
actually needed. Maybe the generic PHY core needs something similar?

        Andrew

On Thu, Jul 16, 2026 at 03:57:22AM +0200, Andrew Lunn wrote:

quoted

This is intentional. The SerDes is attached to the XPCS node because
on RK3568, a single SerDes serves all four XPCS MII ports in QSGMII
mode.

This is not the only device supporting QSGMII, and so the issues you
are addressing should be common to many QSGMII implementations.

Please take a step back. What would a generic solution look like?

Can the reference counting be placed into the core somewhere? The
common clock framework allows a clock to be enabled and disabled by
multiple consumers, and the core clock code does the reference
counting, only calling into the clock driver when state change is
actually needed. Maybe the generic PHY core needs something similar?

Hi Andrew,

Thanks for the thoughtful question. Let me walk through the design
constraints on RK3568 and explain why I chose the current approach.

First, I want to emphasize that this is still RFC, so the binding is not
frozen. However, DT is ABI once merged, and changing it later is painful
and often requires maintaining compatibility with old bindings. So I
would like to be careful about the architecture we settle on.

The current design
==================
The dependency chain I chose is simple:

    stmmac (GMAC) -> pcs-handle -> XPCS node -> phys -> SerDes PHY

The XPCS driver is the single owner of both the SerDes PHY and the
power domain. The MAC driver doesn't need to know about them at all.

On RK3568, phy_power_on() is effectively a no-op for the Combo PHY in
SGMII mode; only phy_init() is required. So the PHY is not a
power-controlled resource — it's just a one-time initialization.

Power domain management is handled via PM runtime:
    - XPCS probe: dev_pm_genpd_rpm_always_on() ensures PD_PIPE is powered
      (this allows us to use PM to manage csr_clk)
    - Each register access: pm_runtime_resume_and_get()/put() controls
      the CSR clock

This is the simplest model that works for SGMII/QSGMII today.

Why not move SerDes to stmmac?
==============================
If we move SerDes and power domain control to the MAC driver, we
run into several problems:

1. Reference counting for phy_init()/phy_exit(): in QSGMII mode, four
   MACs would all call phy_init() on the same hardware. The generic PHY
   core does not currently provide reference counting for these calls.
   Adding it would be a larger change affecting all PHY users.

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.

3. The stmmac SerDes callbacks are legacy: the existing
   serdes_poweron/serdes_powerdown hooks are called from
   stmmac_legacy_serdes_power_on/down functions. They are marked as
   legacy and not intended for new hardware designs. Building new
   support on top of legacy APIs seems like the wrong direction.

Current QSGMII usage on RK3568
===============================
I searched OpenWrt, Armbian, ImmortalWrt, and GitHub for any actual
device using "rockchip,rk3568-xpcs" with QSGMII and found none. It seems
QSGMII on RK3568 is limited to specialized evaluation boards or niche
industrial applications. Even SGMII users are rare — most boards use
RGMII simply because the pins cannot be repurposed.

If QSGMII does become a real requirement in the future, the generic PHY
core could be extended with reference counting for phy_init()/phy_exit().
That would be a cleaner solution than pushing SerDes management into each
MAC driver, and would benefit all platforms with shared SerDes resources.

That said, I had an earlier test with serdes_poweron/serdes_powerdown
callbacks in stmmac, so if the community strongly prefers to move
SerDes control to dwmac-rk, I can do that in v2.

But my preference is to keep the current design: XPCS as the single
owner of the SerDes and power domain. It works today, keeps the DT
binding stable for future QSGMII, and avoids complexity.

Do you think the generic PHY core should grow reference counting for
phy_init()/phy_exit()? Or would you prefer to see a more generic
abstraction for shared SerDes resources?

Thanks,
Coia