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

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Sat, Sep 14, 2019 at 10:15:26AM -0700, Florian Fainelli wrote:
> 
> 
> On 9/14/2019 1:48 AM, Russell King - ARM Linux admin 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.
> > 
> > Note that you're abusing the term "SGMII".  SGMII is a Cisco
> > modification of the IEEE 802.3 1000BASE-X protocol.  Fiber SFPs
> > exclusively use 1000BASE-X protocol.  However, some copper SFPs
> > (with a RJ45) do use SGMII.
> > 
> >>> 2) The 1G Ethernet driver has been converted to use phylink.
> > 
> > This is not necessary for this scenario.  The PHY driver needs to
> > be updated to know about SFP though.
> > 
> > See:
> > 
> > http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=phy&id=ece56785ee0e9df40dc823fdc39ee74b4a7cd1c4
> 
> Regarding that patch, the SFP attach/detach callbacks do not seem very
> specific to the PHY driver, only the sfp_insert callback which needs to
> check the interface selected by the SFP.
> 
> Do you think it would make sense to move some of that logic into the
> core PHY library and only have PHY drivers can be used to connect a SFP
> cage specify a "sfp_select_interface" callback that is responsible for
> rejecting the mode the SFP has been configured in, if unsupported?

It's not that simple.  The Marvell 1G PHYs which have a fiber interface
re-use the fiber interface for SGMII when configured for such a mode.
It's not as simple as "did the driver specify a callback for this
feature" but "does the PHY support a fiber interface _and_ does the PHY
configuration allow the fiber interface to be used?"  So, I think the
PHY driver needs to have a say (in terms of code) whether there is
support for fiber.

However, it'd be silly to specify a sfp property in a situation where
the fiber interface on a PHY can't be used.

In any case, the callback into the PHY driver needs to be as per the
"sfp_insert" method - some PHYs will only be able to support a limited
number of SFPs.  It seems, for example, the 88x3310 can support more
than just 10G modules - it allegedly can support 2500base-X, 1000base-X
and SGMII modules too if we hit it hard enough.

> Likewise for parsing the "sfp" property, if we parse that property in
> the core and do not have a sfp_select_interface callback defined, then
> it is not going to work.

Today, I've moved parsing the "sfp" property into sfp-bus, so that's no
longer a concern.

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