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-next>] [day] [month] [year] [list]
Message-ID: <5AB2470E.24728.48DBA909@Frantisek.Rysanek.post.cz>
Date:   Wed, 21 Mar 2018 12:50:38 +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?

On 21 Mar 2018 at 11:47, Andrew Lunn , netdev@...r.ker wrote:
> 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.
> 

I was also wondering if someone has written any kernel-space support 
for the SFP's. Sure enough, I've found lots of code by Russell King 
under drivers/net/phy. I started reading from sfp.c, went on to 
sfp-bus.c, next the phylink stuff... Answers lots of my questions. 
Clearly someone has "been there and done that" - I mean how to 
interpret SFP EEPROM bits and act upon them in the PHY 
initialization. 
And I keep wondering where to start :-)
If I grep phylink recursively in drivers/net/ethernet, I get no 
hits... Any chance of hooking this up to the igb driver in a clean 
way? There are notes in the phylib drivers that this is "platform" 
stuff - a keyword which speaks to me of stuff hardwired onboard in 
embedded motherboards (is Russell King the father of Linux on ARM ?), 
rather than general-purpose PnP and addon boards. I'd love to use 
existing code of the phylib to talk to the SFP PHY's, maybe extend 
the phylib a bit (with the phy's I have), rather than cobble together 
something crude and private on my own, inside the igb driver. 
If you have any pointers, let me know.

Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ