Re: mv88e6xxx: 2500base-x inband AN is broken on Amethyst? what to do?

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Wed, Jan 13, 2021 at 01:18:23AM +0100, Marek Behún wrote:
> Hello,
> 
> it seems that inband AN is broken on Amethyst when on 2500base-x mode.
> 
> Even SERDES scripts for Amethyst from Marvell has autonegotiation
> disabled for 2500base-x mode. For all the other supported Serdes modes
> autonegotiation is enabled in these scripts.
> 
> The current implementation in mv88e6390_serdes_pcs_config() enables
> autonegotiation if phylink_autoneg_inband(mode) is true:
> 
>   if (phylink_autoneg_inband(mode))
>     bmcr = val | BMCR_ANENABLE;
>   else
>     bmcr = val & ~BMCR_ANENABLE;
> 
> But for PHY_INTERFACE_MODE_2500BASEX this is broken on Amethyst. The
> 2500base-x mode seems to work only with autoneg disabled.
> 
> The result is that when I connect via a passive SFP cable Amethyst
> serdes port with a Peridot serdes port, they will not link. If I
> disable autonegotiation on both sides, they will link, though.
> 
> What is strange is that if I don't use Peridot, but connect the SFP
> directly to Serdes on Armada 3720, where the mvneta driver also enables
> autonegotiation for 2500base-x mode, they will link even if Amethyst
> does not enable 2500base-x.
> 
> To summarize:
> 	Amethyst  <->	Peridot
> 	AN -		AN -		works
> 	AN -		AN +		does not work
> 
> 	Amethyst  <->	Armada 3720 serdes
> 	AN -		AN +		works
> 
> (It is possible that Marvell may find some workaround by touch some
>  undocumented registers, to solve this. I will try to open a bug
>  report.)
> 
> Should we just print an error in the serdes_pcs_config method if inband
> autonegotiation is being requested?
> 
> phylink's code currently allows connecting SFPs in non MLO_AN_INBAND
> mode only for when there is Broadcom BCM84881 PHY inside the SFP (by
> method phylink_phy_no_inband() in phylink.c).
> 
> I wonder whether we can somehow in a sane way implement code to inform
> phylink from the mv88e6xxx driver that inband is not supported for the
> specific mode. Maybe the .mac_config/.pcs_config method could return an
> error indicating this? Or the mv88e6xxx driver can just print an error
> that the mode is not supported, and try to ask the user to disable AN?
> That would need implementing this in ethtool for SFP, though.
> 
> What do you guys think?

It's regrettable that some have decided not to have working in-band
AN for 2500base-X, since it prevents the automatic use of pause modes -
which is essentially the only use of in-band negotiation with
1000base-X since many Gigabit MACs do not support half duplex.

I don't know whether the 88x3310 on the host side uses AN or not for
2500base-X - that detail isn't mentioned in the datasheet, and I don't
have a setup that I could test that with.

I had assumed that most people would implement 2500base-X as merely an
upclocked 1000base-X, as mvneta does - unfortunately, there is /no/
published standard for 2500base-X, so we're left guessing what this
should be from the implementations available at the time.

As you have found, whether AN is supported at 2500base-X appears to be
pretty random.

However, phylib has no way to report whether a PHY wants to use in-band
AN to the MAC. Hence the hack in the phylink code for BCM84881. We
really need a better way for phylib to communicate the capabilities of
the PHY to its user (things like which interface modes are supported,
which interface modes may be dynamically switched between, and whether
they can use in-band AN, and whether in-band AN bypass is supported).
Also similar properties for MAC/PCS drivers, then phylink can work out
what should be done.

That still leaves an issue for SFP modules - when they're capable of
supporting 2500base-X, we have no knowledge of the remote side. This is
where knowing whether the MAC/PCS supports in-band AN bypass or not
matters - if it doesn't then disabling in-band AN for 2500base-X may
make sense, otherwise having in-and AN enabled but with bypass enabled
would probably be sensible.

Right now, we just don't have the information to make the correct
decisions.

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