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: <5AB26714.18645.4958BE60@Frantisek.Rysanek.post.cz>
Date:   Wed, 21 Mar 2018 15:07:16 +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?

...
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