From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Lorenz Brun <lorenz@brun.one>, netdev@vger.kernel.org
Subject: Re: Quirks for exotic SFP module
Date: Sat, 6 May 2023 10:57:06 +0100 [thread overview]
Message-ID: <ZFYj8oMU+g+x7BxU@shell.armlinux.org.uk> (raw)
In-Reply-To: <7ed07d2e-ef0e-4e27-9ac6-96d60ae0e630@lunn.ch>
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!
prev parent reply other threads:[~2023-05-06 9:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 17:39 Quirks for exotic SFP module Lorenz Brun
2023-05-05 18:53 ` Andrew Lunn
2023-05-05 21:30 ` Lorenz Brun
2023-05-06 0:03 ` Andrew Lunn
2023-05-06 0:26 ` Lorenz Brun
2023-05-06 1:05 ` Andrew Lunn
2023-05-06 1:15 ` Lorenz Brun
2023-05-06 13:35 ` Andrew Lunn
2023-05-06 13:54 ` Russell King (Oracle)
2023-05-06 14:04 ` Lorenz Brun
2023-05-06 10:02 ` Russell King (Oracle)
2023-05-06 10:01 ` Russell King (Oracle)
2023-05-06 9:57 ` Russell King (Oracle) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFYj8oMU+g+x7BxU@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=lorenz@brun.one \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).