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: <d75c2138-76c6-49fe-96c3-39401f18b831@lunn.ch>
Date: Sat, 6 May 2023 02:03:32 +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

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

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

   Andrew