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: <DVN7UR.QEVJPHB8FG6I1@brun.one>
Date: Sat, 06 May 2023 02:26:01 +0200
From: Lorenz Brun <lorenz@...n.one>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: Quirks for exotic SFP module




Am Sa, 6. Mai 2023 um 02:03:32 +02:00:00 schrieb Andrew Lunn 
<andrew@...n.ch>:
>>  >
>>  > >  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 tested and I got a bunch of addresses showing up on i2c master 
connected to the module. 1b, 30, 31, 34, 35, 36, 50 and 53. But I'm 
still not sure why we'd want to talk MDIO with this module. AFAIK MDIO 
is an Ethernet thing, the module is talking G.fast to the outside which 
is a completely different protocol from a completely different family 
of protocols. It has its own management protocol which runs over 
Ethernet.

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

TX disable works, but in a quite drastic way by just putting the entire 
SoC into reset.
LOS is wired up, but I am currently not able to test its behavior.

> Russell King will be interested in a binary dump from ethtool -m.
The output of that command is already included in the top post.

OT but my messages to Russell King cannot be delivered
mx0.armlinux.org.uk: <lorenz@...n.one> is locally blocked. If this is 
incorrect, please contact the postmaster.

I haven't knowingly sent any messages to him before so I have no idea 
why I'd be blocked. My sender IP isn't on any public blacklist MultiRBL 
knows about. My DKIM/DMARC setup is also working.

Regards,
Lorenz
>