Re: [PATCH net-next v11 2/5] net: phy: introduce PHY_INTERFACE_MODE_REVSGMII

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Sep 22, 2025 at 09:11:40PM +0800, David Yang wrote:
> The "reverse SGMII" protocol name is a personal invention, derived from
> "reverse MII" and "reverse RMII", this means: "behave like an SGMII
> PHY".

Sorry to mess you around, but... I've been getting further with stmmac's
PCS stuff (I've started again with it) and I've come to realise that the
stmmac driver is full of worms here.

I think we need to have a bigger discussion here.

Today, we have:

- PHY_INTERFACE_MODE_REVMII
- PHY_INTERFACE_MODE_REVRMII

which both complement their _MII and _RMII definitions. So, it seems
entirely sensible to also introduce REVSGMII to complement SGMII.

However, stmmac hardware supports "reverse" mode for more than just
SGMII, also RGMII and SMII. The driver doesn't support SMII, and is
actually buggy - despite having the DT configuration knobs (which
are used), the hardware is never actually configured to operate in
"reverse" mode (it never has the GMAC_CONFIG_TC bit set to allow the
core to, in effect, act as a PHY.) That said, the core does have
it's SGMII rate adapter switched from using the incoming inband word
to using the MAC configuration.

So, while I thought this would be useful for stmmac, given that all
the platforms we have today aren't actually using "reverse SGMII"
mode, I don't think this will be useful there.

If we go round the route of adding REVSGMII, we are also opening
the path to also having REVSMII, and all four REVRGMII* as well.
Is this a good idea?

Would it be better to have phy_interface_t + reverse-mode flag
and accept REVMII and REVRMII as a pecularity? That's probably
going to be a very painful change.

Andrew, any views?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!