Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 3 Jan 2021 03:41:32 +0100
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali@kernel.org>
To:     Thomas Schreiber <tschreibe@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Russell King - ARM Linux admin <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Marek =?utf-8?B?QmVow7pu?= <kabel@kernel.org>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and
 RTL9601C chips
Message-ID: <20210103024132.fpvjumilazrxiuzj@pali>
References: <20201230170546.GU1551@shell.armlinux.org.uk>
 <X+y1K21tp01GpvMy@lunn.ch>
 <20201230174307.lvehswvj5q6c6vk3@pali>
 <20201230190958.GW1551@shell.armlinux.org.uk>
 <20201231121410.2xlxtyqjelrlysd2@pali>
 <X+3ume1+wz8HXHEf@lunn.ch>
 <20201231170039.zkoa6mij3q3gt7c6@pali>
 <X+4GwpFnJ0Asq/Yj@lunn.ch>
 <20210102014955.2xv27xla65eeqyzz@pali>
 <CALQZrspktLr3SfVRhBrVK2zhjFzJMm9tQjWXU_07zjwJytk7Cg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALQZrspktLr3SfVRhBrVK2zhjFzJMm9tQjWXU_07zjwJytk7Cg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

Hello!

On Sunday 03 January 2021 03:25:23 Thomas Schreiber wrote:
> 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

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.

> 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?

> 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 <pali@kernel.org> a écrit :
> >
> > On Thursday 31 December 2020 18:13:38 Andrew Lunn wrote:
> > > > > 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.
> >
> > Adding Thomas to loop. Can you check if CarlitoxxPro GPON ONT module
> > supports LOS or other bits at byte offset 110 at address A2?