[PATCH net-next] net: stmmac: dwmac-qcom-ethqos: Add support for 2.5G SGMII

[Russell King (Oracle)]

On Thu, Dec 21, 2023 at 02:23:57PM +0530, Sneh Shah wrote:
> On 12/20/2023 9:29 PM, Andrew Halaney wrote:
> > I'd evaluate if you can update that function to clear the ANE bit when
> > the ane boolean is false. From the usage I see I feel that makes sense,
> > but correct me if you think I'm wrong.
> > At the very least let's use the defines from there, and possibly add a
> > new function if clearing is not acceptable in dwmac_ctrl_ane().
> > 
> > Stepping back, I was asking in general is the need to muck with ANE here
> > is a Qualcomm specific problem, or is that a generic thing that should be
> > handled in the core (and the phy_set_speed() bit stay here)? i.e. would
> > any dwmac5 based IP need to do something like this for SPEED_2500?
> I think disabling ANE for SPEED_2500 is generic not specific to qualcomm.
> Even in dwxgmac2 versions also we need to disable ANE for SPEED_2500.
> Autoneg clause 37 stadard doesn't support 2500 speed. So we need to
> disable autoneg for speed 2500

(Going back over the history of this addition)

What 802.3 Clause 37 says is utterly _irrelevant_ when discussing Cisco
SGMII. Cisco took 802.3 1000base-X and modified it for their own
purposes, changing the format of the 16-bit control word, adding support
for symbol replication to support 100Mbps and 10Mbps, changing the link
timer, etc. SGMII is *not* 802.3 Clause 37.

I guess you are getting caught up in the widespread crud where
manufacturers stupidly abuse "SGMII" to mean maybe "Cisco SGMII" and
maybe "802.3 1000base-X" because both are "serial gigabit MII". Yes,
both are serial in nature, but Cisco SGMII is not 1000base-X and it
also is not 2500base-X.

What makes this even more difficult is that 2500base-X was never
standardised by the 802.3 committees until very late, so we've ended
up with manufacturers doing their own thing for years. We've ended up
with a mess of different implementations described in different ways
many of which boil down to being 2500base-X without inband AN. For
example, one manufacturer talks about "HS-SGMII", but doesn't permit
the interface to operate at the x10 and x100 symbol replications that
conventional Cisco SGMII uses for 100M and 10M speeds respectfully,
making it in effect no different from 2500base-X.

Now through into this mess various implementations that do not support
inband at 2.5G speeds, those that require inband at 2.5G speeds... one
can get into the situation where one pairs a PHY that requires inband
with a PCS that doesn't support it and the result doesn't work. This
is particularly problematical if the PHY is on a hotpluggable module
like a SFP.

It's a total trainwreck.

I do have some work-in-progress patches that attempt to sort this out
in phylink and identify incompatible situations.

See http://git.armlinux.org.uk/cgit/linux-arm.git/log/?h=net-queue

commits (I think)...

net: phylink: clean up phylink_resolve()

to:

net: phylink: switch to MLO_AN_PHY when PCS uses outband

and since I'm converting stmmac's hacky PCS that bypasses phylink to
a real phylink_pcs, the ethqos code as it stands presents a blocker
because of this issue. So, I'm intending to post a series in the next
few days (after the bank holiday) and will definitely need to be
tested on ethqos hardware.

However, first we need to get to the bottom of your latest patch that
only sets PHY_INTERFACE_MODE_2500BASEX when plat_dat->flags has the
STMMAC_FLAG_HAS_INTEGRATED_PCS flag _set_, but the stmmac code very
oddly does _not_ use the built-in PCS if this flag is set. See:

	stmmac_ethtool_get_link_ksettings()
	stmmac_ethtool_set_link_ksettings()

and their use of pcs_link / pcs_duplex / pcs_speed. Also see

	stmmac_common_interrupt()

and its use of pcs_link to control the carrier, the dwmac1000 and
dwmac4 code that reads the status from the GMAC, updating the
pcs_link / pcs_duplex / pcs_speed variables.

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