netdev - Re: Quirks for exotic SFP module

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]

Message-ID: <ZFYj8oMU+g+x7BxU@shell.armlinux.org.uk>
Date: Sat, 6 May 2023 10:57:06 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Lorenz Brun <lorenz@...n.one>, netdev@...r.kernel.org
Subject: Re: Quirks for exotic SFP module

On Fri, May 05, 2023 at 08:53:43PM +0200, Andrew Lunn wrote:
> On Fri, May 05, 2023 at 07:39:12PM +0200, Lorenz Brun wrote:
> > Hi netdev members,
> 
> For SFP matters, please Cc: SFP maintainer, and the PHY
> maintainers. See the MAINTAINERS file.

... and it doesn't help that $author is using a *.one vanity domain
(all the new TLDs that were announced a number of years back quickly
became brand new sources of nothing but spam, so I blocked them when
the first spams came through on the assumption that no one would be
silly enough to originate email from any of them.)

> > I have some SFP modules which contain a G.fast modem (Metanoia MT5321). In
> > my case I have ones without built-in flash, which means that they come up in
> > bootloader mode. Their EEPROM is emulated by the onboard CPU/DSP and is
> > pretty much completely incorrect, the claimed checksum is 0x00. Luckily
> > there seems to be valid vendor and part number information to quirk off of.
> 
> It is amazing how many SFP manufactures cannot get the simple things
> like CRC right. 
> 
> > I've implemented a detection mechanism analogous to the Cotsworks one, which
> > catches my modules. Since the bootloader is in ROM, we sadly cannot
> > overwrite the bad data, so I just made it skip the CRC check if this is an
> > affected device and the expected CRC is zero.
> 
> Sounds sensible. Probably pointless, because SFP manufactures don't
> seem to care about quality, but please do print an warning that the
> bad checksum is being ignored.
> 
> > There is also the issue of the module advertising 1000BASE-T:
> 
> Probably something for Russell, but what should be advertised?
> 1000Base-X? 
> 
> > But the module internally has an AR8033 1000BASE-X to RGMII converter which
> > is then connected to the modem SoC, so as far as I am aware this is
> > incorrect and could cause Linux to do things like autonegotiation which
> > definitely does not work here.
> 
> Is there anything useful to be gained by talking to the PHY? Since it
> appears to be just a media converter, i guess the PHY having link is
> not useful. Does the LOS GPIO tell you about the G.Fast modem status?

AR803x PHYs don't support I2C directly unlike the MV88E1111, and tend
not to be accessible. Only though additional hardware to convert I2C to
MDIO would it be accessible.

If it's programmed to use 1000base-X on the host side, then that's what
it will be using.

I'm not sure what the original author is talking about when referring to
autonegotiation - autonegotiation for _which_ part of the link?

There's 1000base-X autonegotiation, and then there's RGMII in-band
signalling that is sometimes called (imho incorrectly) autonegotiation.

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