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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Jan 2021 21:21:25 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Marek Behún <kabel@...nel.org>
Cc:     andrew@...n.ch, netdev@...r.kernel.org, olteanv@...il.com,
        pavana.sharma@...i.com
Subject: Re: mv88e6xxx: 2500base-x inband AN is broken on Amethyst? what to
 do?

On Wed, Jan 13, 2021 at 09:08:39PM +0100, Marek Behún wrote:
> OK, so I did some tests with Peridot and 88X3310:
> 
> On 88E6390 switch, when CMODE in the port register for a port capable of
> SerDes is set to 1000base-x, the switch self-configures the SerDes PHY
> to inband AN:
>   register 4.2000 has value 0x1940
> 
> but when CMODE is set to 2500base-x, the switch self-configure the PHY
> without inband AN:
>   register 4.2000 has value 0x0940
> 
> Also the 88X3310 PHY, when configured with MACTYPE=4
>  (that is the mode that switches host interface between
>   10gbase-r/5gbase-r/2500base-x/sgmii, depending on copper speed)
> and when copper speed is 2500, the PHY self-configures without inband
> AN:
>   register 4.2000 has value 0x0140
> 
> It seems to me that on these Marvell devices, they consider 2500base-x
> not capable of inband AN and disable it by default.
> 
> Moreover when the PHY has disabled inband AN and the Peridot switch has
> it enabled (by software), they won't link. I tried enabling the inband
> AN on the PHY, but it does not seem to work. Peridot can only
> communicate with the PHY in 2500base-x with inband AN disabled.
> 
> This means that the commit
>   a5a6858b793ff ("net: dsa: mv88e6xxx: extend phylink to Serdes PHYs")
> causes a regression, since the code started enabling inband AN on
> 2500base-x mode on the mv88e6390 family, and they stopped working with
> the PHY.
> 
> Russell, could we, for now, just edit the code so that when
>   mv88e6390_serdes_pcs_config
> is being configured with inband mode in 2500base-x, the inband mode
> won't be enabled and the function will print a warning?
> This could come with a Fixes tag so that it is backported to stable.

I don't see any other easy option, so yes, please do that.

> Afterwards we can work on refactoring the phylink code so that either
> the driver can inform phylink whether 2500base-x inband AN is supported,
> or maybe we can determine from some documentation or whatnot whether
> inband AN is supported on 2500base-x at all.

I suspect there is no definitive documentation on exactly what
2500base-x actually is. I suspect it may just be easier to turn off AN
for 2500base-x everywhere, so at least all Linux systems are compatible
irrespective of the hardware.

Yes, it means losing pause negotiation, and people will have to
manually set pause on each end.

One thing that I don't know is whether the GPON SFP ONT modules that
use 2500base-x will still function with AN disabled - although I have
the modules, it appeared that they both needed a connection to the ONU
to switch from 1000base-x to 2500base-x on the host side - and as I
don't have an ONU I can test with, I have no way to check their
behaviour.

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