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
