netdev - Re: [PATCH] net: phy: marvell: add special handling of Finisar modules with 81E1111

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]

Date:   Mon, 19 Oct 2020 22:26:30 +0000
From:   Robert Hancock <robert.hancock@...ian.com>
To:     "andrew@...n.ch" <andrew@...n.ch>
CC:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: phy: marvell: add special handling of Finisar
 modules with 81E1111

On Tue, 2020-10-20 at 00:12 +0200, Andrew Lunn wrote:
> > I think in my case those extra modes only supported in SGMII mode,
> > like
> > 10 and 100Mbps modes, effectively get filtered out because the MAC
> > doesn't support them in the 1000BaseX mode either.
> 
> There are different things here. What ethtool reports, and what is
> programmed into the advertise register. Clearly, you don't want it
> advertising 10 and 100 modes. If somebody connects it to a 10Half
> link
> partner, you need auto-get to fail. You don't want auto-neg to
> succeed, and then all the frames get thrown away with bad CRCs,
> overruns etc.
> 

Right, I don't know that we have direct control over what the PHY is
advertising to the copper side in this case. I think it's based on its
auto-magical translation of the 1000BaseX advertisements from the
PCS/PMA PHY in this case, where we only ever advertise 1000 modes in
1000BaseX mode (not sure if any other speeds are even defined for those
messages). Presumably the 88E1111 is smart enough to only advertise
1000 modes on the copper side when in 1000BaseX mode.

> > The auto-negotiation is a bit of a weird thing in this case, as
> > there
> > are two negotiations occurring, the 1000BaseX between the PCS/PMA
> > PHY
> > and the module PHY, and the 1000BaseT between the module PHY and
> > the
> > copper link partner. I believe the 88E1111 has some smarts to delay
> > the
> > copper negotiation until it gets the advertisement over 1000BaseX,
> > uses
> > those to figure out its advertisement, and then uses the copper
> > link
> > partner's response to determine the 1000BaseX response.
> 
> But as far as i know you can only report duplex and pause over
> 1000BaseX, not speed, since it is always 1G.
> 
> It would be interesting to run ethtool on the link partner to see
> what
> it thinks the SFP is advertising. If it just 1000BaseT/Full?

Well the device is plugged into a Linux PC on the other end, but
unfortunately ethtool doesn't seem to report the link partner
advertisements on that adapter, only the host advertisements (Intel
82574L, e1000e).

-- 
Robert Hancock
Senior Hardware Designer, Advanced Technologies 
www.calian.com