SFP interface does not work on you 6.9-rc branch

[jcdutton]

Board: BPI-R3
sfp sfp-1: module OEM SFP-2.5G-T rev 1.0 sn REDACTED dc REDACTED
ethtool looks like something it connected, but the link is always down:
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether 7a:3b:38:39:40:41 brd ff:ff:ff:ff:ff:ff
root@bpi-r3:/etc/hostapd# ethtool eth1
Settings for eth1:
Supported ports: [ MII ]
Supported link modes: 2500baseX/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: off
Port: MII
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no

By comparison. The SFP works on openwrt.
Also, commands take a long time to execute, so something is blocking.

[frank-w]

Make sure the pcs driver (lynxi on r3/r4,xfi on r4 for 10g) is selected.

[jcdutton]

The lynxi is selected.
But no link is established.

[jcdutton]

The attached patch fixes the SFP for me.
sfp-fix1.diff.txt

[frank-w]

So you use the oem 2g5 sfp i also have?

Your patch basicly reverts erics patch right?

dd3dd75

Have you added realtek phy driver from him?

[jcdutton]

I don't think my transceiver uses a realtek phy. What command do I use to identify the phy?

[jcdutton]

The SFP transceiver presents I2C interface on 0x50, 0x51, 0x56.
So, it looks to me that it supports multiple different protocols over I2C.
For example, 0x51 has this:
CNS8TUTAAC30-1410-04V04 and GLC-T
which looks strangely similar to:
Cisco GLC-T 1000BASE-T SFP Module - 30-1410-04 CNS8TUTAAC

I don't think it supports MDIO.
I think this confuses the sfp.c probing, that results in it choosing the swphy. A software emulation for a phy.

[jcdutton]

i2cdump -y 0 0x56
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 10 00 79 49 4f 51 ea 19 11 e1 00 00 00 64 20 01    ?.yIOQ????...d ?
10: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 20 00    ..?........... .
20: 00 62 00 00 00 00 00 00 08 2c 00 00 00 00 00 00    .b......?,......
30: 00 00 00 00 00 00 00 00 00 00 00 00 a0 00 00 00    ............?...
40: 09 40 41 c9 4f 51 ea 19 00 20 00 00 00 00 00 00    ?@A?OQ??. ......
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00    ..............?.
60: 00 00 20 02 00 04 00 00 70 28 00 00 00 00 00 00    .. ?.?..p(......
70: 00 00 00 00 00 00 00 00 00 00 00 00 30 fc 80 01    ............0???
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

Whereas someone else saw this:
At offset 4 it has: 0x001cc849 , which means that we have this PHY at 0x56:

		PHY_ID_MATCH_EXACT(0x001cc849),
		.name           = "RTL8221B-VB-CG 2.5Gbps PHY",

I see offset 4 has: 0x4f51ea19 instead of 0x001cc849 so I need to find with PHY 0x4f51ea19 is.

[frank-w]

You should post this to bpi-forum where eric can take a look at it. I'm no phy specialist :p but 0x56 looks like rollball protocol and good you can access this address...sometimes it is 0xff only

You have quoted eric above from here: https://forum.banana-pi.org/t/sfp-oem-sfp-2-5g-t-kernel-phy/15872/13?u=frank-w

[jcdutton]

I tried with the rollball and I added some debug. It comes back saying rollball not found.

[jcdutton]

@frank-w
Apparently the 0x4f51ea19 is a motorcomm YT8821 PHY.

[frank-w]

Have you deleted the post with the mii patch?

[jcdutton]

Yes, I did delete it. It did not actually work. I am working on a different patch.
Just trying to work out where exactly the *2 needs to happen in the code between C22 reg and i2c messages.

[jcdutton]

Well, on the positive side, I have the yt8821 phy working using C22.
Notice the added "<< 1" to do the reg * 2.
On the negative side, I have not worked out how to do the force auto neg off, so that the interface passes traffic.
The remote side is seeing link up.

static int i2c_mii_read_default_c22(struct mii_bus *bus, int phy_id, int reg)
{
        return i2c_mii_read_default_c45(bus, phy_id, -1, reg << 1);
}

static int i2c_mii_write_default_c22(struct mii_bus *bus, int phy_id, int reg,
                                     u16 val)
{
        return i2c_mii_write_default_c45(bus, phy_id, -1, reg << 1, val);
}

Here is the output from the C22:

ethtool sfp1                                                                                                                                                            
Settings for sfp1:                                                                                                                                                                     
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full     
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 22
        Transceiver: external                                                              
        MDI-X: Unknown
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: no                       

[jcdutton]

In C22 mode, the motorcomm yt8821 phy is setting link up in phydev->link = 1.
I have not yet found out how to propagate that to the ethtool "Link detected" status.
Does anyone have an idea how?

[ericwoud]

I2c is byte oriented, mii is word oriented, so this is where the
difference comes from.