[Macchiato] SFP+ ports - any config needed?

[Steve McIntyre]

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! :-)

>> 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! :-)

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross