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

Powered by blists - more mailing lists