On Sunday 03 January 2021 03:41:32 Pali Rohár wrote:

Hello!

On Sunday 03 January 2021 03:25:23 Thomas Schreiber wrote:

quoted

Hi Pali,
I have a CarlitoxxPro module and I reported an issue about RX_LOS pin
to the manufacturer.
It looks to me that the module asserts "inverted LOS" through EEPROM
but does not implement it.

So, it is broken :-( But I'm not surprised.

Anyway, I think you could be interested in this discussion about my
patch series, but I forgot to CC you on the first patch/cover letter.
You can read whole discussion on public archive available at:

https://lore.kernel.org/netdev/20201230154755.14746-1-pali@kernel.org/t/#u (local)

If you have any comments, let me know so I can fix it for V2.

Those RTL8672/RTL9601C SFP are extremely broken and I do not think that
"rebrander" CarlitoxxPro would do anything with it.

quoted

Consequently, the SFP state machine of my
host router stays in check los state and link is not set up for the
host interface.

So link does not work at all?

quoted

Below is a dump of the module's EEPROM:

[root@clearfog-gt-8k ~]# ethtool -m eth0
Identifier                                : 0x03 (SFP)
Extended identifier                       : 0x04 (GBIC/SFP defined by
2-wire interface ID)
Connector                                 : 0x01 (SC)
Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
Encoding                                  : 0x03 (NRZ)
BR, Nominal                               : 1200MBd
Rate identifier                           : 0x00 (unspecified)
Length (SMF,km)                           : 20km
Length (SMF)                              : 20000m
Length (50um)                             : 0m
Length (62.5um)                           : 0m
Length (Copper)                           : 0m
Length (OM3)                              : 0m
Laser wavelength                          : 1310nm
Vendor name                               : VSOL
Vendor OUI                                : 00:00:00
Vendor PN                                 : V2801F
Vendor rev                                : 1.0
Option values                             : 0x00 0x1c
Option                                    : RX_LOS implemented, inverted
Option                                    : TX_FAULT implemented
Option                                    : TX_DISABLE implemented
BR margin, max                            : 0%
BR margin, min                            : 0%
Vendor SN                                 : CP202003180377
Date code                                 : 200408
Optical diagnostics support               : Yes
Laser bias current                        : 0.000 mA
Laser output power                        : 0.0000 mW / -inf dBm
Receiver signal average optical power     : 0.0000 mW / -inf dBm
Module temperature                        : 31.00 degrees C / 87.80 degrees F
Module voltage                            : 0.0000 V
Alarm/warning flags implemented           : Yes
Laser bias current high alarm             : Off
Laser bias current low alarm              : On
Laser bias current high warning           : Off
Laser bias current low warning            : Off
Laser output power high alarm             : Off
Laser output power low alarm              : On
Laser output power high warning           : Off
Laser output power low warning            : Off
Module temperature high alarm             : Off
Module temperature low alarm              : Off
Module temperature high warning           : Off
Module temperature low warning            : Off
Module voltage high alarm                 : Off
Module voltage low alarm                  : Off
Module voltage high warning               : Off
Module voltage low warning                : Off
Laser rx power high alarm                 : Off
Laser rx power low alarm                  : Off
Laser rx power high warning               : Off
Laser rx power low warning                : Off
Laser bias current high alarm threshold   : 74.752 mA
Laser bias current low alarm threshold    : 0.000 mA
Laser bias current high warning threshold : 0.000 mA
Laser bias current low warning threshold  : 0.000 mA
Laser output power high alarm threshold   : 0.0000 mW / -inf dBm
Laser output power low alarm threshold    : 0.0000 mW / -inf dBm
Laser output power high warning threshold : 0.0000 mW / -inf dBm
Laser output power low warning threshold  : 0.0000 mW / -inf dBm
Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold    : 0.00 degrees C / 32.00 degrees F
Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
Module temperature low warning threshold  : 0.00 degrees C / 32.00 degrees F
Module voltage high alarm threshold       : 0.0000 V
Module voltage low alarm threshold        : 0.0000 V
Module voltage high warning threshold     : 0.0000 V
Module voltage low warning threshold      : 0.0000 V
Laser rx power high alarm threshold       : 0.1536 mW / -8.14 dBm
Laser rx power low alarm threshold        : 0.0000 mW / -inf dBm
Laser rx power high warning threshold     : 0.0000 mW / -inf dBm
Laser rx power low warning threshold      : 0.0000 mW / -inf dBm


Le sam. 2 janv. 2021 à 02:49, Pali Rohár [off-list ref] a écrit :

quoted

On Thursday 31 December 2020 18:13:38 Andrew Lunn wrote:

quoted

quoted

quoted

Looking at sfp_module_info(), adding a check for i2c_block_size < 2
when determining what length to return. ethtool should do the right
thing, know that the second page has not been returned to user space.

But if we limit length of eeprom then userspace would not be able to
access those TX_DISABLE, LOS and other bits from byte 110 at address A2.

Have you tested these bits to see if they actually work? If they don't
work...

On Ubiquiti module that LOS bit does not work.

I think that on CarlitoxxPro module LOS bit worked. But I cannot test it
right now as I do not have access to testing OLT unit.

On my tested CarlitoxxPro module is:

        Option values                             : 0x00 0x1c
        Option                                    : RX_LOS implemented, inverted
        Option                                    : TX_FAULT implemented
        Option                                    : TX_DISABLE implemented

When cable is disconnected then in EEPROM at position 0x16e is value
0x82. If I call 'ip link set eth1 up' then value changes to 0x02, module
itself has a link and I can connect to its internal telnet/webserver to
configure it.

When cable is connected but connection is not established by OLT then
this value is 0x80. If I call 'ip link set eth1 up' then value changes
to 0x00 and kernel does not see a link (no carrier).

So it seems that RX_LOS (bit 1 of 0x16e EEPROM) and also TX_DISABLE (bit
7 of 0x16e EEPROM) is implemented and working properly.

And therefore we should allow access to these bits.


I also tested UBNT module and result is:

        Option values                             : 0x00 0x06
        Option                                    : RX_LOS implemented
        Option                                    : RX_LOS implemented, inverted

Which means that those bits are not implemented.

Anyway I check position 0x16e and value on its value is randomly either
0x79 or 0xff independently of the state of the GPON module.

So it is really not implemented on UBNT.

quoted

quoted

Adding Thomas to loop. Can you check if CarlitoxxPro GPON ONT module
supports LOS or other bits at byte offset 110 at address A2?