UISP Fiber Instant SFP GPON support

For Developers
1

I ended up with an ER-X-SFP with an Ubiquity Fiber Instant SFP GPON stick in my hands and I would like to check the support for the GPON stick. This post is mainly a call for help to understand technical information.

As of OpenWRT 22.0.3, it seems like it is not supported, as dmesg shows:

[   19.440306] sfp sfp_eth5: Detected broken RTL8672/RTL9601C emulated EEPROM
[   19.454024] sfp sfp_eth5: Switching to reading EEPROM to one byte at a time
[   23.970313] sfp sfp_eth5: EEPROM base structure checksum failure: 0xe6 != 0xff
[   23.984722] sfp EE: 00000000: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8  ................
[   24.002046] sfp EE: 00000010: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20  ....UBNT
[   24.019360] sfp EE: 00000020: 20 20 20 20 00 74 ac b9 55 46 2d 49 4e 53 54 41      .t..UF-INSTA
[   24.036677] sfp EE: 00000030: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 ff  NT      4   ....
[   24.053996] sfp EE: 00000040: 64 be 47 81 00 5d 01 81 c0 5c 01 81 80 9a 77 80  d.G..]...\....w.
[   24.071320] sfp EE: 00000050: fe ff ff ff 80 c6 43 81 00 00 78 80 c0 5c 01 81  ......C...x..\..

On December 2019 a user of this forum wrote:

RTL8672 = Lexra architecture => unsupported

On december 30, 2020 a series of patches named net: sfp: add support for GPON RTL8672/RTL9601C and Ubiquiti U-Fiber have been submitted to the kernel. I don't really understand the content of the patches, but the name and description look promising.

The patches have been merged on January 28, 2021 1 2 3 and included in the kernel since v5.12. They have been backported in OpenWRT on July 25, 2021 and are included in OpenWRT 22:

git tag --contains f032601ed7d70fe1f468219b68750230b6ea1906
v22.03.0
...
v22.03.3
  • Should those patches bring support for the Ubiquity Fiber Instant stick, or is more work needed to achieve before this?.
  • If so, why dmesg is displaying an error message with OWRT 22.0.3, as it looks v22 includes the patches ?

Related links: Amine4000/RTL960x, zry98/SFP-GPON-ONU

1 Like
2

In OpenWrt 23.05, with kernel 5.15.134, dmesg still displays the same error message:

[    0.841313] gpio-487 (sfp_i2c_clk_gate): hogged as output/high
[   16.232191] sfp sfp_eth5: Host maximum power 1.0W
[   16.242199] sfp sfp_eth5: No tx_disable pin: SFP modules will always be emitting.
[   16.551112] sfp sfp_eth5: Detected broken RTL8672/RTL9601C emulated EEPROM
[   16.564859] sfp sfp_eth5: Switching to reading EEPROM to one byte at a time
[   16.614444] sfp sfp_eth5: EEPROM base structure checksum failure: 0xe6 != 0xff
[   16.628845] sfp EE: 00000000: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8  ................
[   16.646163] sfp EE: 00000010: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20  ....UBNT
[   16.663489] sfp EE: 00000020: 20 20 20 20 00 74 ac b9 55 46 2d 49 4e 53 54 41      .t..UF-INSTA
[   16.680808] sfp EE: 00000030: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 ff  NT      4   ....
[   16.698122] sfp EE: 00000040: 00 00 00 00 40 3d 7f 81 40 8f 01 81 00 8f 01 81  ....@=..@.......
[   16.715438] sfp EE: 00000050: 6c fe ce 82 00 00 00 00 01 00 00 00 a0 4f 45 81  l............OE.
3

Mmmh you get a checksum error (see https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/sfp.c#L2218 ):

The question is, why?

4

No idea what can be the causes, this is why I am trying to understand if this kind of error message is expected due to a lack of support for the Fiber Instant, or if there is something wrong somewhere.

5

This does not look like the lack of the kernel support for this module.
Your dump looks right - I see the vendor name, product name and the serial number are in the expected places.
The checksums of the module do not look right - the byte at 0x3f should be 0xe6 instead of 0xff and the byte at 0x5f should be 0xce instead of 0x81.
You can try adding an easy hack to your kernel - patch out the checksum verification code by commenting out return -EINVAL; and memset(&id.ext, 0, sizeof(id.ext)); lines in the function sfp_sm_mod_probe which is located in drivers/net/phy/sfp.c. If it resolves the issue, then the right way to fix that would be adding a quirk in a similar way as it is done for Cotsworks modules.