netdev - Re: SFP support with RGMII MAC via RGMII to SERDES/SGMII PHY?

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

Date:   Wed, 18 Sep 2019 23:04:04 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     George McCollister <george.mccollister@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: SFP support with RGMII MAC via RGMII to SERDES/SGMII PHY?

On Wed, Sep 18, 2019 at 01:44:33PM -0500, George McCollister wrote:
> Russell,
> 
> On Mon, Sep 16, 2019 at 10:40 AM George McCollister
> <george.mccollister@...il.com> wrote:
> >
> > On Sat, Sep 14, 2019 at 3:49 AM Russell King - ARM Linux admin
> > <linux@...linux.org.uk> wrote:
> > >
> > > On Fri, Sep 13, 2019 at 08:31:18PM -0700, Florian Fainelli wrote:
> > > > +Russell, Andrew, Heiner,
> > > >
> > > > On 9/13/2019 9:44 AM, George McCollister wrote:
> > > > > Every example of phylink SFP support I've seen is using an Ethernet
> > > > > MAC with native SGMII.
> > > > > Can phylink facilitate support of Fiber and Copper SFP modules
> > > > > connected to an RGMII MAC if all of the following are true?
> > > >
> > > > I don't think that use case has been presented before, but phylink
> > > > sounds like the tool that should help solve it. From your description
> > > > below, it sounds like all the pieces are there to support it. Is the
> > > > Ethernet MAC driver upstream?
> > >
> > > It has been presented, and it's something I've been trying to support
> > > for the last couple of years - in fact, I have patches in my tree that
> > > support a very similar scenario on the Macchiatobin with the 88x3310
> > > PHYs.
> > >
> > > > > 1) The MAC is connected via RGMII to a transceiver/PHY (such as
> > > > > Marvell 88E1512) which then connects to the SFP via SERDER/SGMII. If
> > > > > you want to see a block diagram it's the first one here:
> > > > > https://www.marvell.com/transceivers/assets/Alaska_88E1512-001_product_brief.pdf
> > >
> > > As mentioned above, this is no different from the Macchiatobin,
> > > where we have:
> > >
> > >                   .-------- RJ45
> > > MAC ---- 88x3310 PHY
> > >                   `-------- SFP+
> > >
> > > except instead of the MAC to PHY link being 10GBASE-R, it's RGMII,
> > > and the PHY to SFP+ link is 10GBASE-R instead of 1000BASE-X.
> 
> Did you test with an SFP+ module that has a PHY?

I think you mean SFP module - SFP+ is for >1G.  No, that won't work for
two reasons.

1. The copper SFP module requires SGMII not 1000BASE-X.
2. netdev/phylib doesn't support stacking two PHYs on a single
   network device.

(1) can be worked around if the intermediary PHY can be configured for
it, but (2) is a lot harder to resolve, because phylib wants to put
the PHY into the netdev->phydev pointer, and you can't have two of
them.

I think fixing this properly is going to require quite a lot of
re-work, and as I don't have a setup that electrically supports SFP
modules in this setup (only SFP+ modules) it isn't something I'm
able to test.

> In my setup, nothing connects/attaches to the PHY (88E1111) in the
> RJ45 SFP module I'm testing with (is this intended?). Apparently since
> sfp_upstream_ops in the PHY driver used for the first PHY doesn't
> provide a .connect_phy.

Yep, because there's no way to stack phylib managed PHYs.

> This leaves .phy_link_change NULL. Eventually
> phy_link_down tries to call .phy_link_change resulting in a NULL
> pointer deference OOPs. If phy_link_change doesn't need to be called
> for the second PHY I can just send a patch that doesn't call it if
> it's NULL.

SGMII provides a way to discover the negotiated speed and duplex,
but not the pause settings back to the MAC - so in this setup, we
really do need to read the 88E1111 negotiation results (for the
pause settings) and communicate them back to the MAC for things
to work correctly.

It's something that we need to work out how to do...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up