...
yes I've just noticed Russell's patch mentioning mvneta,
and found the phylink patches to mvneta in net-next (until then I'd
been reading the vanilla, where they haven't landed yet).
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tre
e/drivers/net/ethernet/marvell/mvneta.c
phylink_create() looks clear enough, but I got stuck once I looked at
phylink_register_sfp(). Which IMO asks the device tree to enumerate
driver "sfp" or some such. I'm lost again. Thanks for hinting that
the existing style of the Intel driver and the Linux "device tree"
don't mix well or readily.
It's sad. Mr. King's code is so obvious and easy to follow (except
maybe for the indirections through the device tree).
As for Intel software and support... that's a bit of love and hate on
my part :-) The more I get involved, the more intensive the mix.
On 21 Mar 2018 at 13:58, Andrew Lunn wrote:
> > 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.
>
thanks for that explanation :-) You have saved me some time.
Frankly I see no chance of my code getting accepted to upstream - I'm
critical to my own capabilities here.
int phylink_callback(char* msg)
{
printk(msg);
}
"Hello there, there's an SGMII SFP plugged into the port that you
have registered earlier, on the mdio-i2c bus you have set up,
we have configured the PHY for you, all you need to do is tuck this
leash up your MAC and tell it to try a handshake."
It would be lovely to add SFP hot-swap support and PHY auto-config to
the Intel driver, and it would possibly result in quite a voluminous
crapectomy in the Intel driver, but in my position the effort
required is clearly over my head, and, as you correctly say, I'm not
in the position to push this back upstream :-)
I'll see how far I can go, "low hanging fruit /halfway there" style.
For instance, the "previous-generation" API starting from
mdiobus_alloc() looks "bounded" in terms of effort.
(Example in drivers/net/ethernet/broadcom/tg3.c)
If I understand this correctly, it should allow me to tap into
phylib, only I'd have to give up the SFP EEPROM understanding
and PHY hot-swap (available from the phylink with SFP support).
I'll probably become silent now, for a while.
Thanks for all your polite explanations Andrew :-)
Frank
