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]

Message-ID: <0d5cfd1d-f3a8-485c-944d-f2d193633aa7@lunn.ch>
Date: Wed, 22 May 2024 23:57:14 +0200
From: Andrew Lunn <andrew@...n.ch>
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.

> 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?

> 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.

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