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]

Date: Fri, 5 May 2023 20:53:43 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Lorenz Brun <lorenz@...n.one>
Cc: netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: Quirks for exotic SFP module

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.

> 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?

    Andrew