All of lore.kernel.org
 help / color / mirror / Atom feed
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&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!

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.