[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<BEZP281MB277651F9154F2814398038C790F42@BEZP281MB2776.DEUP281.PROD.OUTLOOK.COM>
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
Powered by blists - more mailing lists