netdev - Re: net: dsa: mv88e6xxx: Help needed: Serdes with SFP not working with mv88e6320 on Linux 5.4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 May 2024 00:31:45 +0000
From: Daniel Glinka <daniel.glinka@...ntys.de>
To: Andrew Lunn <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: net: dsa: mv88e6xxx: Help needed: Serdes with SFP not working
 with mv88e6320 on Linux 5.4

Hi Andrew, 

>From: Andrew Lunn <andrew@...n.ch>
>Sent: Wednesday, May 22, 2024 17:57
>To: Daniel Glinka <daniel.glinka@...ntys.de>
>Cc: netdev@...r.kernel.org <netdev@...r.kernel.org>
>Subject: Re: net: dsa: mv88e6xxx: Help needed: Serdes with SFP not working with mv88e6320 on Linux 5.4
>
>On Wed, May 22, 2024 at 09:14:06PM +0000, Daniel Glinka wrote:
>> Hi,
>>
>> I've been trying to get the SERDES ports of a Marvell 88E6320 on a custom board working without success. The SERDES ports are connected to SFPs. On the >>board I have connected a network interface (eth2) to switch port 2 via RGMII. The DSA switch is configured to forward the packages to port 0 which is >>connected to an SFP. The forwarding of the DSA switch seems to be fine. I've tested this with forwarding to port 3, which is connected to a RJ45. This works >>fine. I can also see that the tx_packet counter on port 0 is increased, when running e.g. ping. Therefore it seems that the DSA configuration works correctly.
>>
>> The SFPs seem to be initialized correctly as well. The link is reported to be up and I get a link change when disconnecting the cable.
>>
>> [  247.782415] sfp sfp0: SM: exit present:up:link_up
>>
>> The SERDES connection is configured to 1000BASE-X.
>
> What SFP do you have in the SFP cage? Are you sure it needs 1000BaseX?
> Most fibre SFPs do, but if it is copper, it probably wants SGMII.

This is the SFP cage we are using:
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x0b (Optical pigtail)
        Transceiver codes                         : 0x18 0x00 0x00 0x01 0x40 0x08 0x00 0x80 0x00
        Transceiver type                          : 10G Ethernet: 10G Base-SR
        Transceiver type                          : Infiniband: 1X SX
        Transceiver type                          : Ethernet: 1000BASE-SX
        Transceiver type                          : FC: short distance (S)
        Transceiver type                          : Active Cable
        Transceiver type                          : FC: 1200 MBytes/sec
        Encoding                                  : 0x06 (64B/66B)
        Active Cu cmplnce.                        : 0x03 (unknown) [SFF-8472 rev10.4 only]
        Vendor name                               : municom
        Vendor OUI                                : 00:1b:21
        Vendor PN                                 : MUN-AOC-SFP+-001
        Vendor rev                                : Rev1
        Option values                             : 0x00 0x1a
        Option                                    : RX_LOS implemented
        Option                                    : TX_FAULT implemented
        Option                                    : TX_DISABLE implemented
        Vendor SN                                 : SA1708250054
        Date code                                 : 170825
        Optical diagnostics support               : Yes

>> The link is reported as down but is directly wired to the SFP which
>> reports the link is up.
>
> How do you know the SFP reports the link is up?

This is the SFP state:
Module state: present
Module probe attempts: 0 0
Device state: up
Main state: link_up
Fault recovery remaining retries: 5
PHY probe remaining retries: 12
moddef0: 1
rx_los: 0
tx_fault: 0
tx_disable: 0

When I pull the Cable it reports link_down.

>> Therefore I forced the link up in the port control register.

> You should not need to do this. You need to understand why the switch
> thinks it is down.

>> We are using the 5.4 kernel and currently have no option to upgrade to a later version.

> If you have no option to upgrade to a later version it suggests you
> are using a vendor crap tree? If so, you should ask your vendor for
> support. Why else use a vendor crap tree?
>
> What is actually stopping you from using a mainline kernel? Ideally
> you want to debug the issue using net-next, or maybe 6.9. Once you get
> it working and merged to mainline, you can then backport what is
> needed to the vendor crap kernel.

We need a feature which was dropped in 5.15. But to debug this issue I will try to get everything running with the 6.9 kernel.

> So, assuming you can use 6.9...

> mv88e6320_ops does not have a .pcs_ops member. So the SERDES is not
> getting configured. Taking a quick look at the datasheet, the SERDES
> appears to be similar to the 6352 SERDES. However, the 6532 only has a
> single SERDES, where as the 6320 has two of them. And they are at a
> different address, 0xC and 0xD, where as the 6532 uses 0xF.

> You can probably use pcs-6352.c as a template in order to produce
> pcs-6320.c. Actually, you might be able to extend it, adding just
> 6320 specific versions of:
> 
> const struct mv88e6xxx_pcs_ops mv88e6352_pcs_ops = {
>        .pcs_init = mv88e6352_pcs_init,
>        .pcs_teardown = mv88e6352_pcs_teardown,
>        .pcs_select = mv88e6352_pcs_select,
>};
> 
> to the end.
>
>        Andrew

Thanks for the suggestion! I will try this.

Daniel