Re: [PATCH net-next 2/2] net: pcs: xpcs: select operating mode for 10G-baseR capable PCS

[Andrew Lunn <andrew@lunn.ch>]

I don't know this PCS driver, so maybe dumb questions....

> Currently the XPCS found on Toshiba TC9564 is unable to operate at
> 2500base-X and slower with a PHY connected using SGMII/2500base-X
> (in our case a Qualcomm QCA8081).

Is the PHY actually relevant here? What about SGMII/2500base-X for an
SFP?

Is this purely a PCS problem, or does what the PCS connect to make a
difference?

> The problem arises because this XPCS supports 10Gbase-R. That means
> that the reset value of SR_XS_PCS_CTRL2:PCS_TYPE_SEL (0) is valid and
> this suppresses the modal switching based on bit 13 of SR_PMA_CTRL1
> or SR_XS_PCS_CTRL1.

~/linux/drivers/net/pcs$ grep SR_XS_PCS_CTRL1 *
~/linux/drivers/net/pcs$ grep SR_PMA_CTRL1 *
~/linux/drivers/net/pcs$

This is not helping me understand what is going on here.

> +	if (mdio_stat2 & MDIO_PCS_STAT2_10GBR) {
> +		switch (interface) {
> +		case PHY_INTERFACE_MODE_SGMII:
> +		case PHY_INTERFACE_MODE_1000BASEX:
> +		case PHY_INTERFACE_MODE_2500BASEX:
> +			/*
> +			 * Why are we writing MDIO_PCS_CTRL2_TYPE + 1? We want
> +			 * the modal behaviour that comes when we pick a
> +			 * reserved value. XPCS allocates extra bits to this
> +			 * field and allocates values from 15 down so
> +			 * MDIO_PCS_CTRL2_TYPE + 1 is the value likely to be
> +			 * allocated last (and hopefully never).

MDIO_PCS_CTRL2_TYPE is 3. Looking at 802.3, the value 4 is
40GBASE-R. The 2022 version of the standard has values defined up to
10011b, for speeds up to 400G,

Alex added support for 25G, 50G, 100G.

Is this an issue?

	Andrew