[PATCH RFC net-next 15/16] net: phylink: add negotiation of in-band capabilities

[Russell King (Oracle)]

On Tue, Nov 26, 2024 at 10:18:56PM +0100, Andrew Lunn wrote:
> > +		if (pcs_ib_caps && pcs_ib_caps != LINK_INBAND_DISABLE) {
> > +			/* PCS supports reporting in-band capabilities, and
> > +			 * supports more than disable mode.
> > +			 */
> > +			if (pcs_ib_caps & LINK_INBAND_DISABLE)
> > +				neg_mode = PHYLINK_PCS_NEG_OUTBAND;
> > +			else if (pcs_ib_caps & LINK_INBAND_ENABLE)
> > +				pcs_ib_only = true;
> > +		}
> > +
> > +		if (phy_ib_caps && phy_ib_caps != LINK_INBAND_DISABLE) {
> > +			/* PHY supports in-band capabilities, and supports
> > +			 * more than disable mode.
> > +			 */
> > +			if (phy_ib_caps & LINK_INBAND_DISABLE)
> > +				pl->phy_ib_mode = LINK_INBAND_DISABLE;
> > +			else if (phy_ib_caps & LINK_INBAND_BYPASS)
> > +				pl->phy_ib_mode = LINK_INBAND_BYPASS;
> > +			else if (phy_ib_caps & LINK_INBAND_ENABLE)
> > +				phy_ib_only = true;
> 
> Looking at the different handling between PCS and PHY, i asked myself,
> does PCS BYPASS exist? If it is invalid, i don't see a check if the
> PCS is reporting it and should we be issuing a warning?

Yes, it does exist - see for example MVNETA_GMAC_AN_BYPASS_ENABLE for
mvneta - but there's complications to using it that need sorting first.

The problem is if SGMII enters bypass mode, then the duplex is
configured according to MVNETA_GMAC_CONFIG_FULL_DUPLEX. In wonderful
Marvell style, it makes no mention about the speed setting. It does
say that it's supported for "SGMII modes". One assumes that it would
do the same thing and fall back to setting described by the two speed
bits, but the documentation doesn't say that. Maybe "SGMII modes" is
referring to Base-X only and not Cisco SGMII.

The problem of what seems to be almost an industry wide abuse of the
"SGMII" term creating a trainwreck strikes again!

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