[Macchiato] SFP+ ports - any config needed?

[Baruch Siach]

Hi Steve,

Steve McIntyre writes:
> On Tue, Dec 18, 2018 at 08:42:05PM +0200, Baruch Siach wrote:
>>Steve McIntyre writes:
>>>
>>> So I've found the problem (I think!) - in the Debian kernel we have
>>> CONFIG_MARVELL_10G_PHY=m and AFAICS there's nothing triggering
>>> autoloading of the module. Without it, things just don't work. Forcing
>>> the system to load it at boot time on the 4.18 backports kernel (via
>>> listing in /etc/modules) makes things work for me:
>>>
>>> [   14.576557] mvpp2 f2000000.ethernet eth0: PHY [f212a600.mdio-mii:00] driver [mv88x3310]
>>> [   14.596758] mvpp2 f2000000.ethernet eth0: configuring for phy/10gbase-kr link mode
>>> [   14.605163] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [   15.617114] mvpp2 f2000000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
>>> [   15.625016] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> It clearly needs to be loaded before mvpp2, but there's something more
>>> awkward here too. If I unload mvpp2 then modprobe marvell10g and mvpp2
>>> I still don't get any traffic on the SFP+. There's a dependency order
>>> that's not obvious, to me at least! Should the mvpp2 driver be
>>> declaring a dependency on marvell10g here?
>>
>>I don't think so. The Armada 8K MAC can work with other PHYs. The kernel
>>messages indicate that the MAC correctly identified the PHY (mv88x3310).
>>so the right kernel module should have been loaded. Not sure what is
>>missing here.
>
> Ah, but this is in the case where I've already loaded the marvell10g
> module before the mvpp2 module. So if the MAC works fine with other
> PHYs too (as you'd expect!), shouldn't the DTB be triggering
> auto-loading of the PHY then? I'll admit I'm a bit hazy about the
> exact logic of how to do that! :-)

The DTB can't trigger the PHY driver load because there is no
identification of the specific PHY in the DTB. There is only a
"ethernet-phy-ieee802.3-c45" compatible string. The MAC detects the PHY
at run time. This ID should be matched against the list given in an
mdio_device_id struct array to the MODULE_DEVICE_TABLE()
macro. Something is evidently still missing here because it does not
currently work as expected.

>>> I'm also trying a current build of 4.20.0-rc7 using the same kernel
>>> config inherited from Debian, and I see the same behaviour as with
>>> 4.18.6. So your fix in 01b3fd5ac97c wasn't needed for me, at least.
>>
>>Maybe that's because your kernel is missing commit 24205e4e62dd ("net:
>>phy: phylink: fix SFP interface autodetection") from the -stable
>>linux-4.18.y branch (upstream commit 7e41837527). It only appeared in
>>v4.18.15. Without this patch the PHY mode set in the device-tree takes
>>over.
>
> Right, OK.
>
>>> I'm still seeing oddness from ethtool, with both kernels. With the
>>> SFP+ plugged in and running I'm seeing:
>>>
>>> root at mjolnir:/home/steve# ethtool eth0
>>> Settings for eth0:
>>>         Supported ports: [ TP ]
>>>         Supported link modes:   10baseT/Half 10baseT/Full
>>>                                 100baseT/Half 100baseT/Full
>>>                                 1000baseT/Full
>>>                                 10000baseT/Full
>>>         Supported pause frame use: Symmetric Receive-only
>>>         Supports auto-negotiation: Yes
>>>         Advertised link modes:  10baseT/Half 10baseT/Full
>>>                                 100baseT/Half 100baseT/Full
>>>                                 1000baseT/Full
>>>                                 10000baseT/Full
>>>         Advertised pause frame use: Symmetric Receive-only
>>>         Advertised auto-negotiation: Yes
>>>         Speed: 10000Mb/s
>>>         Duplex: Full
>>>         Port: MII
>>>         PHYAD: 0
>>>         Transceiver: internal
>>>         Auto-negotiation: on
>>>         Link detected: yes
>>>
>>> so I'm guessing there's something not quite right in the mvpp2 ethtool
>>> backend?
>>
>>What is it that you find odd in this output?
>
> On other machines with SFP+, I'm seeing "FIBRE" in the "Supported
> Ports" list, is the main thing. Maybe "[ TP FIBRE ]" would be right?
> The list for eth2 looks very bogus:
>
> # ethtool eth2
> Settings for eth2:
>         Supported ports: [ TP AUI BNC MII FIBRE Backplane ]
>
> I *really* don't think we have BNC! :-)

One more thing that occurred to me only now. Do you see messages like
this one from the sfp driver:

[   90.186000] sfp sfp-cp1-eth0: module Intel Corp       FTLX8571D3BCV-IT rev A    sn INSSRI44328      dc 13-09-10

If not, your SFP module has not been really detected.

Also, what do you get for 'ethtool -m eth0'?

baruch

--
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -