> 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.
That is all quite new code. It has not spread too far yet. The Marvell
mvneta ethernet driver is using it, and the Clearfog is probably the
first in kernel board to make use of it. A few of us are working on
converting DSA over to using PHYLINK, since we have boards with
Ethernet switches and SFP connected to switch ports.
> 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.
At the moment, PHYLIB pretty much relies on device tree to glue all
the parts together. There is no support for not using device tree at
the moment. It would need somebody to contribute that code.
The other issue is that the igb driver, like most of the intel
Ethernet drivers, ignore much of the Linux common MDIO/PHY and I2C
infrastructure, and does it all themselves. This is probably because
they share code with the Windoze driver.
> 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.
So this is quite a big job, to do it cleanly. You probably need to
retain the intel code for MDIO/PHY/I2C, but add an option to make use
of the Linux common MDIO/PHY/I2C infrastructure. Then you need to
extend PHYLINK with a non device tree way to configure it, and glue
all the parts together.
You can make it a bit easier by just throwing away all the intel
MDIO/PHY/I2C code, replacing it will Linux common code. But i expect
the Intel maintainers would then reject your changes. There is too
high a chance of introducing regressions.
Andrew
