[PATCH net-next 13/14] net: stmmac: remove obsolete pcs methods and associated code

[Andrew Halaney]

On Fri, Aug 02, 2024 at 08:22:42PM GMT, Russell King (Oracle) wrote:
> On Fri, Aug 02, 2024 at 02:02:25PM -0500, Andrew Halaney wrote:
> > On Fri, Aug 02, 2024 at 11:47:32AM GMT, Russell King (Oracle) wrote:
> > > The pcs_ctrl_ane() method is no longer required as this will be handled
> > > by the mac_pcs phylink_pcs instance. Remove these methods, their common
> > > implementation, the pcs_link, pcs_duplex and pcs_speed members of
> > > struct stmmac_extra_stats, and stmmac_has_mac_phylink_select_pcs().
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> >
> > ...
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > > index 3c8ae3753205..799af80024d2 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > > @@ -321,48 +321,6 @@ static int stmmac_ethtool_get_link_ksettings(struct net_device *dev,
> > >  {
> > >  	struct stmmac_priv *priv = netdev_priv(dev);
> > >
> > > -	if (!(priv->plat->flags & STMMAC_FLAG_HAS_INTEGRATED_PCS) &&
> >
> > This change effectively makes the INTEGRATED_PCS flag useless, I think
> > we should remove it entirely.
>
> I'm hoping the ethqos folk are going to test this patch series and tell
> me whether it works for them - specifically Sneh Shah who added
>
> 	net: stmmac: dwmac-qcom-ethqos: Add support for 2.5G SGMII
>
> which directly configures the PCS bypassing phylink. Specifically,
> if this in stmmac_check_pcs_mode():
>
> 	priv->dma_cap.pcs && interface == PHY_INTERFACE_MODE_SGMII
>
> is true for this device, then we may be in for problems. Since
> priv->dma_cap.pcs comes from hardware, it's impossible to tell
> unless one has that hardware.

Hopefully we get a response there. For what its worth I have a
access to the sa8775p-ride.dts board in a remote lab and
dma_cap.pcs is definitely set for this integration of the IP
on sa8775p. The only upstream described boards are:

    1) sa8775p-ride
    2) sa8775p-ride-r3

The difference is that "r3" is the latest spin of the board, with some
Aquantia phys attached to the 2 stmmac MACs on the board instead of the
Marvell 88EA1512 phys on the former. My understanding is that's to
evaluate 2500 Mbps speeds (the 88EA1512 only goes up to 1000 Mbps).

The "r3" board's Aquantia aqr115c's are capable of 2500 Mbps, but are
"overclock SGMII". The "r3" describes the phy interface as 2500base-x,
with no in-band signalling (since the "OCSGMII" is hacked up and doesn't
really do the in-band signalling you've described in the past). That's
all based on Bart's commit message adding support for that in:

    0ebc581f8a4b7 net: phy: aquantia: add support for aqr115c

I think Sneh also had access to a board with the sa8775p in a fixed-link
configuration doing 2500 Mbps, but that's not described upstream at the
moment. I believe that was the board that originally motivated the patch
you highlighted from him.

At the very least Bartosz and I tested this and things didn't break
noticeably for the 2 boards I listed above... so that's good :)

Hope that helps,
Andrew