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: <ZFYlXFrLl/RdvkFu@shell.armlinux.org.uk>
Date: Sat, 6 May 2023 11:01:00 +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 Sat, May 06, 2023 at 02:03:32AM +0200, Andrew Lunn wrote:
> > > 
> > > >  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?
> 
> > AFAIK you cannot talk to the PHY as there isn't really an Ethernet PHY.
> 
> So i2c-detect does not find anything other than at address 0x50?
> 
> Often the PHY can be access via an MDIO bus over I2C at some other
> address on the bus. The linux SFP code might be trying, even
> succeeding, in instantiating such a bus and finding the PHY. And then
> a PHY driver will be loaded to drive the PHY. This is how Copper SFP
> modules work. However, most Copper SFP use a Marvell PHY, not
> Atheros. And RollBall SFP use a different MDIO over i2c protocol.

Given that the PHY is in 1000base-X to RGMII mode, this is not a usual
setup, and its probably something the PHYLIB driver won't expect. So
we probably don't want to be talking to the PHY, and we probably just
want to talk 1000base-X to the module.

> > I actually haven't checked the LOS GPIO. This thing runs ~1MiB of firmware
> > and two different proprietary management protocols which I've
> > reverse-engineered over which you can get tons of data about the current
> > modem and link status. You need those to boot the SoC anyways. The TX
> > disable GPIO puts the modem SoC into reset state and is used in case you use
> > a host-based watchdog for the module.
> 
> So i guess you are not passing the GPIO for TX disable in your DT
> blob. And maybe not LOS. If you do, it must be doing something
> sensible, because phylink does not allow the carrier to go up if LOS
> is active. Although the EEPROM can indicate LOS is not
> implemented. But that assumes the EEPROM contents are sane.
> 
> Russell King will be interested in a binary dump from ethtool -m.

Definitely.

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