netdev - Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

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]

Date:   Wed, 21 Mar 2018 11:47:32 +0100
From:   "Frantisek Rysanek" <Frantisek.Rysanek@...t.cz>
To:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?

Just another follow-up:

With specs on SFP MSA, DDM/DMI and MII in hand, I have determined:
0x50 (a.k.a. 0xA0 in SFP MSA spec) = the module's SPD "EEPROM"
0x51 (a.k.a. 0xA2 in SFP MSA spec) = diagnostics (DMI/DDM)
0x56 = MII management access over i2C

Using eeprog (reading each offset twice to get 16bit words, which 
works for both the SFP's), I've been able to get the MII PHY ID's of 
the chips inside both modules:

SFP#1 has PHY ID == 002060C1 == BCM5461S
SFP#2 has PHY ID == 01410c97 == Marvell MV88E111x series.
    I don't know the precise model of the Marvell chip.
    Could be the mythical MV88E1113.

The SPD EEPROM contents are interesting too.

The module ID == 0 is weird, I would expect 0x03 = SFP,
but then again, the SFP MSA doesn't consider SGMII in the socket at 
all, it appears to only consider SERDES, am I right? So skipping the 
module ID makes some limited sense to me.

I haven't calculated the checksums yet, but multiple fields in there 
are filled in according to the SFP MSA spec.

Interestingly, SFP#1 has "Encoding" (byte 11 / 0x0b) set to 0x05
= "SONET scrambled". But has other fields indicating 100Base-FX.
For 100Base-FX I would expect encoding "4b/5b".
Which is what SFP#2 has encoded in its otherwise sparse EEPROM.

SFP#1 has DMI/DDM implemented. Alarm thresholds seem cranked to the 
limit, but some measured values are returned.

SFP#2 does not have DMI/DDM active, yet it decodes the i2c device 
0x51 (a.k.a. 0xA2) and about three bytes are non-empty... but holding 
nonsensical values (some thresholds).

Looking at the i2c dumps, and some past dumps from the igb driver, 
it's dawning on me on me that the igb driver, without much hacking, 
would try to read the PHY ID from the DMI/DDM block - a case which 
the drivers/net/phy/mdio-i2c.c specifically avoids :-)

My current opinion about the matters is, that I don't really need a 
valid SPD EEPROM to initialize the PHY in the SFP.
The question is, if I can make the i210 properly handshake with the 
PHY on the SGMII payload lane.

Another question is, how to write the driver's initialization 
sequence, for it to correctly decide if the SFP is SERDES or SGMII or 
what. I could just follow the config obtained from the i210 EEPROM.
Alternatively, or somehow combined to that, I could try checking if 
something responds to me over i2c, and do a quick check for SPD 
EEPROM. If I find one, do a check for "MII regs over i2c" - at all 
i2c slave addresses between 0x41..0x59  EXCEPT 0x50/0x51.
If I find MII-i2c regs, it's clear that the transceiver contains a 
PHY, and wants to run in SGMII mode - otherwise it's a SERDES thing.
If nothing is found in i2c mode, and inherited i210 config indicates 
SGMII, try external MDIO... if that fails, revert to SERDES.

And then there's the MII PHY internal config, which can be quite 
proprietary...

And if I write all that, there's noone to re-test this after me, as 
my setup is such a special case :-/

No end of fun.

Unfortunately, some other work is interfering at this very moment...

Frank