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 03:52:08 +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

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

Russel is better at reading these things, but...

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

Why is it saying 10G, but 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.

If you are willing to Maintain the feature, you might be able to bring
it back. You could try submitting a patch adding it back, and include
a change to MAINTAINERS listing yourself. It does however require you
to actually look after it for the next decade...

   Andrew