On 10/01/2020 12:53, Russell King - ARM Linux admin wrote:

quoted

quoted

Which is also indicating everything is correct.  When the problem
occurs, check the state of the signals again as close as possible
to the event - it depends how long the transceiver keeps it
asserted.  You will probably find tx-fault is indicating
"in  hi IRQ".

just discovered userland - gpioinfo pca9538 - which seems more verbose

gpiochip2 - 8 lines:
         line   0:      unnamed   "tx-fault"   input  active-high [used]
         line   1:      unnamed "tx-disable"  output  active-high [used]
         line   2:      unnamed "rate-select0" input active-high [used]
         line   3:      unnamed        "los"   input  active-high [used]
         line   4:      unnamed   "mod-def0"   input   active-low [used]
         line   5:      unnamed       unused   input  active-high
         line   6:      unnamed       unused   input  active-high
         line   7:      unnamed       unused   input  active-high

The above is depicting the current state with the module working, i.e. being
online. Will do some testing and report back, not sure yet how to keep a
close watch relating to the failure events.

However, that doesn't give the current levels of the inputs, so it's
useless for the purpose I've asked for.

Fair enough. Operational (online) state

gpiochip2: GPIOs 504-511, parent: i2c/8-0071, pca9538, can sleep:
  gpio-504 ( |tx-fault     ) in  lo IRQ
  gpio-505 ( |tx-disable   ) out lo
  gpio-506 ( |rate-select0 ) in  lo
  gpio-507 ( |los          ) in  lo IRQ
  gpio-508 ( |mod-def0     ) in  lo IRQ

And the same remained (unchanged) during/after the events (as closely I 
was able to monitor) -> module transmit fault indicated

Kept an eye on the link state of the NIC (eth2) as well with - ip mo l 
dev eth2 - and it does not come up either with those transmit faults and 
only gets back online once the transmit faults are cleared.

At loss really, since it seems the SFP is not exhibiting any mischievous 
behaviour. It does not even reproduce reliably, just now it took a 
couple of attempts to invoke the transmit fault and other times it does 
straight away.
Suppose there could be always a hardware defect though it seems somewhat 
unlikely. That said, I do not have another such module available to swap 
for testing.