Message-ID: <20201019220354.GY1551@shell.armlinux.org.uk>
Date:   Mon, 19 Oct 2020 23:03:54 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Robert Hancock <robert.hancock@...ian.com>
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, Oct 19, 2020 at 09:32:56PM +0000, Robert Hancock wrote:
> 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.

Hmm, okay.

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

I have worked on patches that implement a replacement system of
working out which interface mode to use, not only for optical
modules, but also for PHYs as well. It needs network drivers and
PHYs to advertise a bitmap of which PHY_INTERFACE_MODE_xxx each
support, and we use an ordered list of preferred modes to find the
most suitable interface mode supported by both the network driver
and the module/PHY. I never fully finished the patches though.

PHYs need to fill in this bitmap before they are bound to a
network driver, because we need to work out which interface mode
to use before we can attach the PHY.

The patches for this are in my net-queue branch on
git://git.armlinux.org.uk/~rmk/linux-arm.git/

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists