On 09/01/2020 17:43, Russell King - ARM Linux admin wrote:

On Thu, Jan 09, 2020 at 05:35:23PM +0000, ѽ҉ᶬḳ℠ wrote:

quoted

Thank you for the extensive feedback and explanation.

Pardon for having mixed up the semantics on module specifications vs. EEPROM
dump...

The module (chipset) been designed by Metanoia, not sure who is the actual
manufacturer, and probably just been branded Allnet.
The designer provides some proprietary management software (called EBM) to
their wholesale buyers only

I have one of their early MT-V5311 modules, but it has no accessible
EEPROM, and even if it did, it would be of no use to me being
unapproved for connection to the BT Openreach network.  (BT SIN 498
specifies non-standard power profile to avoid crosstalk issues with
existing ADSL infrastructure, and I believe they regularly check the
connected modem type and firmware versions against an approved list.)

I haven't noticed the module I have asserting its TX_FAULT signal,
but then its RJ45 has never been connected to anything.

The curious (and sort of inexplicable) thing is that the module in 
general works, i.e. at some point it must pass the sm checks or 
connectivity would be failing constantly and thus the module being 
generally unusable.

The reported issues however are intermittent, usually reliably 
reproducible with

ifdown <iface> && ifup <iface>

or rebooting the router that hosts the module.

If some times passes, not sure but seems in excess of 3 minutes, between 
ifdown and ifup the sm checks mostly are not failing.
It somehow "feels" that the module is storing some link signal 
information in a register which does not suit the sm check routine and 
only when that register clears the sm check routine passes and 
connectivity is restored.
____

Since there are probably other such SFP modules, xDSL and g.fast, out 
there that do not provide laser safety circuitry by design (since not 
providing connectivity over fibre) would it perhaps not make sense to 
try checking for the existence of laser safety circuitry first prior 
getting to the sm checks?
____

Sometime in the past sfp.c was not available in the distro and the issue 
never exhibited. Back then the module's operations mode been set through 
a py script - see bottom - but it would appear that it did not implement 
any sm checks.

---py script

class SFP:
     def __init__(self, i2cbus):
         self.i2cbus = i2cbus

     @staticmethod
     def detect_metanoia_xdsl(eeprom):
         return ['X', 'C', 'V', 'R', '-', '0', '8', '0', 'Y', '5',
             '5',] == eeprom[40:51]

     @staticmethod
     def detect_zisa_gpon(eeprom):
         return ['T', 'W', '2', '3', '6', '2', 'H'] == eeprom[40:47]

     @staticmethod
     def detect_sgmii(eeprom):
         if ord(eeprom[6]) & 0x08:
             d("Mode selected: generic SGMII")
             return True
         else:
             d("Mode selected: generic 1000BASE-X")

         return False


     def decide_sfpmode(self):
         ec = []
         try:
             ec = list(EEPROM(self.i2cbus).read_eeprom())
             d("SFP EEPROM: %s" % str(ec))
         except Exception as e:
             l("EEPROM read error: " + str(e))
             return 'phy-sfp'

         # special case: Metanoia xDSL SFP, 1000BASE-X, no link 
autonegotiation
         if self.detect_metanoia_xdsl(ec):
             l("Metanoia DSL SFP detected. Switching to phy-sfp-noneg 
mode.")
             return 'phy-sfp-noneg'

         # special case: Zisa GPON SFP, SGMII
         if self.detect_zisa_gpon(ec):
             l("Zisa GPON SFP detected. Switching to phy-sfp-sgmii mode.")
             return 'phy-sfp-sgmii'

         # SGMII detection
         if self.detect_sgmii(ec):
             return 'phy-sfp-sgmii'

         # default 1000BASE-X
         return 'phy-sfp'