SFP OEM SFP-2.5G-T kernel PHY?

Besides, you could change your patches to set actual register/bit names according to datasheet here rather than using magic numbers.

No problem, if you can point out where the magic numbers are in this datasheet.

I’ll save you from searching through it, the nummers are not in this datasheet. They are in another document, also as magic numbers, not labeled.

Thanks for checking.

Seems this version of datasheet is the only version I could find while searching… So we have to still use magic numbers.

Hi,

No “rollball” is found on my OEM SFP-2.5G-T device. The SFP works fine if i undo the rollball fixup back to the quirk. Maybe my SFP uses a different phy?

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 which PHY 0x4f51ea19 is.

It seems to be the YT8821.

@jcdutton what is the output of ethtool -m <interfaceX>

ethtool -m eth1
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x00 0x01 0x00 0x00 0x00 0x00 0x02 0x00 0x00
        Transceiver type                          : SONET: OC-48, short reach
        Encoding                                  : 0x05 (SONET Scrambled)
        BR, Nominal                               : 2500MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF,km)                           : 0km
        Length (SMF)                              : 0m
        Length (50um)                             : 300m
        Length (62.5um)                           : 200m
        Length (Copper)                           : 0m
        Length (OM3)                              : 0m
        Laser wavelength                          : 850nm
        Vendor name                               : OEM
        Vendor OUI                                : 00:00:00
        Vendor PN                                 : SFP-2.5G-T
        Vendor rev                                : 1.0
        Option values                             : 0x00 0x1a
        Option                                    : RX_LOS implemented
        Option                                    : TX_FAULT implemented
        Option                                    : TX_DISABLE implemented
        BR margin, max                            : 0%
        BR margin, min                            : 0%
        Vendor SN                                 : REDACTED
        Date code                                 : REDACTED

Hi, How did you know 0x4f51ea19 was a Motorcomm YT8821 ? Is there a list of IDs somewhere? Please can you point me to the url?

This is what my SFP looks like: https://www.aliexpress.com/item/1005005529894356.html?spm=a2g0o.productlist.main.3.2869d556zJf4Gf&algo_pvid=206d1e8b-182b-4005-94c7-392cacb00e42&algo_exp_id=206d1e8b-182b-4005-94c7-392cacb00e42-1&pdp_npi=4%40dis!GBP!13.87!9.71!!!123.36!86.35!%40210385bb17119018061353789e48a5!12000035891714140!sea!UK!3021760511!&curPageLogUid=5OC5aStfMlxU&utparam-url=scene%3Asearch|query_from%3A

Does anyone know how to do a teardown on that, so I can look at the chips? I cannot get the thing apart.

Flip open lid with knife at the pins end.

The problem is that this sfp is also recognized as OEM SFP-2.5G-T where your current quirk breaks functionality.

See SFP interface does not work on you 6.9-rc branch · Issue #118 · frank-w/BPI-Router-Linux · GitHub

I will have a look, maybe do a different quirk / fixup based on seeing 0x4f51ea19 or not.

Google,…

Horrible…

Are you sure it is the aocclink one? There is another user on the forum with one of this brand, but it has a slightly different ID.

Perhaps they are messing with the ID string, depending on the equipment you order it for…

Its not the aocclink one, but the metal casing looks identical, with no screws on it, or under the label.

No brand at all? No other label?

Where did you buy it?

What does/did the label look like?

New image is also working fine with my SFP. Thanks.

Thanks.

Because of the OEM SFP more then one type of PHY under the same vendor name/PN problem, I have submitted the patch-set, but only with 1 original module, not for OEM modules.

Anyway, first see if the patch-set gets accepted, then it is always possible to add fixups for other modules.

So I have received also a SFP module with the YT8821. However it is recognized with a different Vendor PN string:

Vendor name                               : OEM
Vendor PN                                 : 2.5G-T-Y-RM

So the vendor is messing with the Vendor PN strings, using different values.

It would seem that it is only sometimes the same as other vendor and other hardware.