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: <30161ca241d03c201e801af7089dada5b6481c24.camel@calian.com>
Date:   Mon, 19 Oct 2020 21:32:56 +0000
From:   Robert Hancock <robert.hancock@...ian.com>
To:     "linux@...linux.org.uk" <linux@...linux.org.uk>
CC:     "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "andrew@...n.ch" <andrew@...n.ch>
Subject: Re: [PATCH] net: phy: marvell: add special handling of Finisar
 modules with 81E1111

On Mon, 2020-10-19 at 22:08 +0100, Russell King - ARM Linux admin
wrote:
> On Mon, Oct 19, 2020 at 02:49:13PM -0600, Robert Hancock wrote:
> > The Finisar FCLF8520P2BTL 1000BaseT SFP module uses a Marvel
> > 81E1111 PHY
> 
> You mean 88E1111 here.
> 

Whoops, will fix in an updated version.

> > with a modified PHY ID, and by default does not have 1000BaseX
> > auto-negotiation enabled, which is not generally desirable with
> > Linux
> > networking drivers. Add handling to enable 1000BaseX auto-
> > negotiation.
> > Also, it requires some special handling to ensure that 1000BaseT
> > auto-
> > negotiation is enabled properly when desired.
> > 
> > Based on existing handling in the AMD xgbe driver and the
> > information in
> > the Finisar FAQ:
> > https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.finisar.com%2Fsites%2Fdefault%2Ffiles%2Fresources%2Fan-2036_1000base-t_sfp_faqreve1.pdf&amp;data=04%7C01%7Crobert.hancock%40calian.com%7C6eda7d636fbf4a70ff2408d8747332a2%7C23b57807562f49ad92c43bb0f07a1fdf%7C0%7C0%7C637387385403382018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cfChA4TBw3f70alrANXPR0HHgNg3Vs%2FNeEYhzZc%2BF9A%3D&amp;reserved=0
> 
> There's lots of modules that have the 88E1111 PHY on, and we switch
> it to SGMII mode if it's not already in SGMII mode if we have access
> to it. Why is your setup different?

This is in our setup using the Xilinx axienet driver, which is stuck
with whatever interface mode the FPGA logic is set up for at synthesis
time. In our case since we need to support fiber modules, that means we
are stuck with 1000BaseX mode with the copper modules as well.

Note that there is some more work that needs to be done for this to
work completely, as phylink currently will only attempt to use SGMII
with copper modules and fails out if that's not supported. I have a
local patch that just falls back to trying 1000BaseX mode if the driver
reports SGMII isn't supported and it seems like it might be a copper
module, but that is a bit of a hack that may need to be handled
differently.

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