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] [day] [month] [year] [list]

Message-ID: <20180321130809.GB11206@lunn.ch>
Date:   Wed, 21 Mar 2018 14:08:09 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Frantisek Rysanek <Frantisek.Rysanek@...t.cz>
Cc:     netdev@...r.kernel.org
Subject: Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY
 to MDIO requests?

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

It avoids if for a very good reason. This driver exports a standard
Linux MDIO bus. The core phylib code will then probe the bus, read the
IDs, find the correct PHY driver and loads it.

It is probably good that you spend some time looking at a driver other
than igb. Picking one i know a little, say the Freescale FEC. It has
functions to perform MDIO read and MDIO write. These are then exported
as an MDIO bus to the linux common code. And there are a few calls to
phy_connect(), phy_start(), phy_stop(). That is how you build a driver
which uses the code in drivers/net/phy. mvneta shows how you can use
phylink. Study these two far a while.

      Andrew