Message-ID:
 <BEZP281MB27764168226DAC7547D7AD6990EB2@BEZP281MB2776.DEUP281.PROD.OUTLOOK.COM>
Date: Wed, 22 May 2024 21:14:06 +0000
From: Daniel Glinka <daniel.glinka@...ntys.de>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: net: dsa: mv88e6xxx: Help needed: Serdes with SFP not working with
 mv88e6320 on Linux 5.4

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. The link is reported as down but is directly wired to the SFP which reports the link is up. Therefore I forced the link up in the port control register.
I know this behavior could be due to a hardware issue but I am fairly new to this topic and I want to rule out all misconfigurations before getting back to the hardware guys.

Below are the switch port registers, statistics and the device tree nodes of port2 and port0. The c_mode of the port is configured to 1000BASE-X without PHY detect. In the mv88e6xxx driver I did not find anything SERDES related for the mv88e6320 chip. Is this even supported? The SERDES related functions in the driver do not seem to apply to our setup because we have no PHY and cannot set any register values (switching to the fiber/SERDES page in register 22 does not work).

If it is a general misdesign of our setup, please let me know.

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

This is the register dump:
88E6320  Switch Port Registers
------------------------------
00:                                        0x0e09
01:                                        0x003e
02:                                        0x0000
03:                                        0x1152
04:                                        0x043f
05:                                        0x0000
06:                                        0x0024
07:                                        0x0000
08:                                        0x2080
09:                                        0x0001
10:                                        0x0000
11:                                        0x0001
12:                                        0x0000
13:                                        0x0000
14:                                        0x0000
15:                                        0x9100
16:                                        0x0000
17:                                        0x0000
18:                                        0x0000
19:                                        0x0000
20:                                        0x0000
21:                                        0x0000
22:                                        0x0000
23:                                        0x0001
24:                                        0x3210
25:                                        0x7654
26:                                        0x0000
27:                                        0x8000
28:                                        0x0000
29:                                        0x0000
30:                                        0x0000
31:                                        0xf000

And this is reported by ethtool:
NIC statistics:
     tx_packets: 77
     tx_bytes: 10288
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 0
     in_bad_octets: 0
     in_unicast: 0
     in_broadcasts: 0
     in_multicasts: 0
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 6830
     out_unicast: 0
     out_broadcasts: 18
     out_multicasts: 27
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 6
     hist_65_127bytes: 27
     hist_128_255bytes: 0
     hist_256_511bytes: 12
     hist_512_1023bytes: 0
     hist_1024_max_bytes: 0
     in_discards: 0
     in_filtered: 0
     in_accepted: 0
     in_bad_accepted: 0
     in_good_avb_class_a: 0
     in_good_avb_class_b: 0
     in_bad_avb_class_a: 0
     in_bad_avb_class_b: 0
     tcam_counter_0: 0
     tcam_counter_1: 0
     tcam_counter_2: 0
     tcam_counter_3: 0
     in_da_unknown: 0
     in_management: 0
     out_queue_0: 39
     out_queue_1: 6
     out_queue_2: 0
     out_queue_3: 0
     out_queue_4: 0
     out_queue_5: 0
     out_queue_6: 0
     out_queue_7: 0
     out_cut_through: 0
     out_octets_a: 0
     out_octets_b: 0
     out_management: 16
     atu_member_violation: 0
     atu_miss_violation: 0
     atu_full_violation: 0
     vtu_member_violation: 0
     vtu_miss_violation: 0

Device Tree config:
port@0 {
    reg = <0>;
    label = "port0";
    phy-mode = "1000base-x";
    sfp = <&sfp0>;
};
port@2 {
     reg = <2>;
     label = "port2";
     phy-mode = "rgmii-id";
     fixed-link {
         speed = <1000>;
         full-duplex;
     };
};

During testing I also configured the fixed-link full duplex for port0, without success.

I'm not sure what else I can do to debug this issue further or if I overlooked something. I would appreciate any pointers to make sure the issue is not software related.

Best Regards,
Daniel Glinka

Powered by blists - more mailing lists