From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Robert Hancock <robert.hancock@calian.com>
Cc: "hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"andrew@lunn.ch" <andrew@lunn.ch>
Subject: Re: [PATCH] net: phy: marvell: add special handling of Finisar modules with 81E1111
Date: Mon, 19 Oct 2020 23:03:54 +0100 [thread overview]
Message-ID: <20201019220354.GY1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <30161ca241d03c201e801af7089dada5b6481c24.camel@calian.com>
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&data=04%7C01%7Crobert.hancock%40calian.com%7C6eda7d636fbf4a70ff2408d8747332a2%7C23b57807562f49ad92c43bb0f07a1fdf%7C0%7C0%7C637387385403382018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cfChA4TBw3f70alrANXPR0HHgNg3Vs%2FNeEYhzZc%2BF9A%3D&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!
prev parent reply other threads:[~2020-10-19 22:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 20:49 [PATCH] net: phy: marvell: add special handling of Finisar modules with 81E1111 Robert Hancock
2020-10-19 21:00 ` Andrew Lunn
2020-10-19 21:43 ` Robert Hancock
2020-10-19 21:59 ` Andrew Lunn
2020-10-19 22:11 ` Robert Hancock
2020-10-19 21:06 ` Andrew Lunn
2020-10-19 21:09 ` Russell King - ARM Linux admin
2020-10-19 21:08 ` Russell King - ARM Linux admin
2020-10-19 21:32 ` Robert Hancock
2020-10-19 21:45 ` Andrew Lunn
2020-10-19 21:59 ` Robert Hancock
2020-10-19 22:12 ` Andrew Lunn
2020-10-19 22:21 ` Russell King - ARM Linux admin
2020-10-19 22:26 ` Robert Hancock
2020-10-19 22:03 ` Russell King - ARM Linux admin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019220354.GY1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=robert.hancock@calian.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).