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

Message-ID: <20201019221232.GB139700@lunn.ch>
Date:   Tue, 20 Oct 2020 00:12:32 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Robert Hancock <robert.hancock@...ian.com>
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

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

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

   Andrew