Date:   Sat, 14 Sep 2019 10:15:26 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     George McCollister <george.mccollister@...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 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?
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.

So far we know that both marvel10g.c and marvell.c, two drivers that
would already justify factoring things in the core, I recall some people
using Broadcom PHYs having the same use cases, so 3 possible drivers
needing that functionality.

> 
> as an example of the 88x3310 supporting a SFP+ cage.  This patch is
> also necessary:
> 
> http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=phy&id=ef2d699397ca28c7f89e01cc9e5037989096a990
> 
> and if anything is going to stand in the way of progress on this, it
> is likely to be that patch.  I'll be attempting to post these after
> the next merge window (i.o.w. probably posting them in three weeks
> time.)


-- 
Florian

Powered by blists - more mailing lists