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