Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

Hi all,

i'm trying to make link up of a VSOL V2810F into a MacchiatoBIN
double-shot on port SFP@2.5GbE (rif
https://www.spinics.net/lists/arm-kernel/msg857257.html)

The current situation is this one (putting some logs into sfp.c):

root@mcbin:~# dmesg | grep eth3
[ 3.035066] mvpp2 f4000000.ethernet eth3: Using firmware node mac
address 00:51:82:11:22:03
 [ 11.873853] sfp sfp-eth3: Host maximum power 2.0W
[ 11.878594] sfp sfp-eth3: SFP_S_DOWN
[ 11.882513] sfp sfp-eth3: SFP_MOD_PROBE
[ 11.886367] sfp sfp-eth3: SFP_S_DOWN
 [ 12.189648] sfp sfp-eth3: SFP_MOD_PROBE
[ 12.201279] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
[ 12.208182] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
[ 12.255376] sfp sfp-eth3: module OEM V2801F rev 1.0 sn 202101195032 dc 210119
[ 12.265160] sfp sfp-eth3: module_t_start_up
[ 12.269361] sfp sfp-eth3: SFP_MOD_WAITDEV
[12.273396] mvpp2 f4000000.ethernet eth3: switched to
inband/1000base-x link mode
[ 12.280912] sfp sfp-eth3: SFP_S_DOWN
[ 12.284503] sfp sfp-eth3: skipping hwmon device registration due to
broken EEPROM
[ 12.292018] sfp sfp-eth3: diagnostic EEPROM area cannot be read
atomically to guarantee data coherency
[ 493.248711] mvpp2 f4000000.ethernet eth3: configuring for
inband/1000base-x link mode
[ 493.257761] sfp sfp-eth3: SFP_MOD_PRESENT
[ 493.261796] sfp sfp-eth3: SFP_MOD_ERROR
[ 493.265648] sfp sfp-eth3: SFP_S_DOWN
[ 493.319654] sfp sfp-eth3: SFP_MOD_PRESENT
[ 493.323685] sfp sfp-eth3: SFP_MOD_ERROR
[ 493.327535] sfp sfp-eth3: SFP_S_WAIT
[ 493.331133] sfp sfp-eth3: event == SFP_E_TIMEOUT
[ 493.335795] sfp sfp-eth3: SFP_F_TX_FAULT bit basso
[ 493.340634] sfp sfp-eth3: sfp_sm_link_check_los
[ 493.345183] sfp sfp-eth3: los ok

the SFP reaches the RX_LOS state and there should be a link up (i've
forced los=true on the sfp.c), but nothing happens :(

here is the current EEPROM dump, if needed I can provide eeprom raw.
The SFP works on my MCL220 and Ubiquiti switch

root@mcbin:~# ethtool -m eth3
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                               : OEM
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                                 : 202101195032
Date code                                 : 210119
Optical diagnostics support               : Yes
Laser bias current                        : 16.574 mA
Laser output power                        : 1.4542 mW / 1.63 dBm
Receiver signal average optical power     : 0.0408 mW / -13.89 dBm
Module temperature                        : 61.15 degrees C / 142.07 degrees F
Module voltage                            : 3.3241 V
Alarm/warning flags implemented           : Yes
Laser bias current high alarm             : Off
Laser bias current low alarm              : Off
Laser bias current high warning           : Off
Laser bias current low warning            : Off
Laser output power high alarm             : Off
Laser output power low alarm              : Off
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   : 75.000 mA
Laser bias current low alarm threshold    : 1.000 mA
Laser bias current high warning threshold : 70.000 mA
Laser bias current low warning threshold  : 3.000 mA
Laser output power high alarm threshold   : 3.1622 mW / 5.00 dBm
Laser output power low alarm threshold    : 1.1220 mW / 0.50 dBm
Laser output power high warning threshold : 2.8183 mW / 4.50 dBm
Laser output power low warning threshold  : 1.2589 mW / 1.00 dBm
Module temperature high alarm threshold   : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold    : -10.00 degrees C / 14.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold  : -5.00 degrees C / 23.00 degrees F
Module voltage high alarm threshold       : 3.6000 V
Module voltage low alarm threshold        : 3.0000 V
Module voltage high warning threshold     : 3.4700 V
Module voltage low warning threshold      : 3.1299 V
Laser rx power high alarm threshold       : 0.1584 mW / -8.00 dBm
Laser rx power low alarm threshold        : 0.0015 mW / -28.24 dBm
Laser rx power high warning threshold     : 0.1258 mW / -9.00 dBm
Laser rx power low warning threshold      : 0.0019 mW / -27.21 dBm

Thanks in advance

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

Hi,

On Mon, Mar 07, 2022 at 05:18:18PM +0100, Giammarco lynx wrote:
> Hi all,
> 
> i'm trying to make link up of a VSOL V2810F into a MacchiatoBIN
> double-shot on port SFP@2.5GbE (rif
> https://www.spinics.net/lists/arm-kernel/msg857257.html)
> 
> The current situation is this one (putting some logs into sfp.c):

sfp.c already has debugging present (see the dev_dbg() statements).
Those in sfp_sm_event() will show you the complete state machine
state and events at entry and exit from each state machine run and
is superior to the output provided below, which I can't really make
too much sense of.

> the SFP reaches the RX_LOS state and there should be a link up (i've
> forced los=true on the sfp.c), but nothing happens :(

So what state did SFP end up in?

There's two ways to know that - either via the debugfs "state" file
for the SFP (which should be /sys/kernel/debug/sfp-eth3/state) or
by using the provided debug in sfp.c which can be enabled by adding
#define DEBUG at the stop of sfp.c.

Also defining DEBUG at the top of phylink.c to get further debugging
output that will be useful to see what's going on at the MAC side.

I suspect you are getting to the "SFP_S_LINK_UP" state, but for some
reason the link between the host and the module isn't coming up.

Is the PON module connected to the PON network?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

adding

linux-arm-kernel@lists.infradead.org

Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx
<stich86@gmail.com> ha scritto:
>
> ok, doing in the way that you suggest, the link is bringing up.
> Here is the logs (without ifconfig eth3 up and module plugged):
>
> [    3.035643] mvpp2 f4000000.ethernet eth3: Using firmware node mac
> address 00:51:82:11:22:03
> [   11.872410] sfp sfp-eth3: Host maximum power 2.0W
> [   11.877149] sfp sfp-eth3: tx disable 1 -> 1
> [   11.877155] sfp sfp-eth3: SM: enter empty:detached:down event insert
> [   11.877159] sfp sfp-eth3: SM: exit probe:detached:down
> [   11.877410] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach
> [   11.877414] sfp sfp-eth3: SM: exit probe:down:down
> [   12.180129] sfp sfp-eth3: SM: enter probe:down:down event timeout
> [   12.187906] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> [   12.194814] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> [   12.242005] sfp sfp-eth3: module OEM              V2801F
> rev 1.0  sn 202101195032     dc 210119
> [   12.251800] mvpp2 f4000000.ethernet eth3: requesting link mode
> inband/1000base-x with support 0000000,00000200,00000440
> [   12.251804] mvpp2 f4000000.ethernet eth3: switched to
> inband/1000base-x link mode
> [   12.259318] sfp sfp-eth3: SM: exit present:down:down
> [   12.270123] sfp sfp-eth3: skipping hwmon device registration due to
> broken EEPROM
> [   12.277636] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> atomically to guarantee data coherency
> [   35.174143] mvpp2 f4000000.ethernet eth3: configuring for
> inband/1000base-x link mode
> [   35.182026] mvpp2 f4000000.ethernet eth3: major config 1000base-x
> [   35.188158] mvpp2 f4000000.ethernet eth3: phylink_mac_config:
> mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440
> pause=04 link=0 an=1
> [   35.202945] sfp sfp-eth3: SM: enter present:down:down event dev_up
> [   35.209152] sfp sfp-eth3: tx disable 1 -> 0
> [   35.213387] sfp sfp-eth3: SM: exit present:up:wait
> [   35.280129] sfp sfp-eth3: SM: enter present:up:wait event timeout
> [   35.286253] sfp sfp-eth3: SM: exit present:up:link_up
> [   56.097724] sfp sfp-eth3: los 0 -> 1
> [   56.101324] sfp sfp-eth3: SM: enter present:up:link_up event los_high
> [   56.107792] sfp sfp-eth3: SM: exit present:up:link_up
> [   56.112876] sfp sfp-eth3: mod-def0 1 -> 0
> [   56.116903] sfp sfp-eth3: tx-fault 0 -> 1
> [   56.120933] sfp sfp-eth3: SM: enter present:up:link_up event remove
>
> Then after "ifconfig eth3 up" i've removed and reinserted the SFP,
> this is the log:
>
> [   56.127227] sfp sfp-eth3: module removed
> [   56.131175] sfp sfp-eth3: tx disable 0 -> 1
> [   56.135432] sfp sfp-eth3: SM: exit empty:up:down
> [   56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault
> [   56.146103] sfp sfp-eth3: SM: exit empty:up:down
> [   59.350731] sfp sfp-eth3: mod-def0 0 -> 1
> [   59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert
> [   59.360619] sfp sfp-eth3: SM: exit probe:up:down
> [   59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   59.686185] sfp sfp-eth3: SM: exit probe:up:down
> [   59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   59.806179] sfp sfp-eth3: SM: exit probe:up:down
> [   59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   59.926179] sfp sfp-eth3: SM: exit probe:up:down
> [   60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.046178] sfp sfp-eth3: SM: exit probe:up:down
> [   60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.166178] sfp sfp-eth3: SM: exit probe:up:down
> [   60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.276177] sfp sfp-eth3: SM: exit probe:up:down
> [   60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.386178] sfp sfp-eth3: SM: exit probe:up:down
> [   60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.506177] sfp sfp-eth3: SM: exit probe:up:down
> [   60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.626176] sfp sfp-eth3: SM: exit probe:up:down
> [   60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   60.746177] sfp sfp-eth3: please wait, module slow to respond
> [   60.751982] sfp sfp-eth3: SM: exit probe:up:down
> [   65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   65.846262] sfp sfp-eth3: SM: exit probe:up:down
> [   70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   70.876192] sfp sfp-eth3: SM: exit probe:up:down
> [   75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   75.926196] sfp sfp-eth3: SM: exit probe:up:down
> [   80.896801] mvpp2 f4000000.ethernet eth3: mac link up
> [   80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   80.966183] sfp sfp-eth3: SM: exit probe:up:down
> [   81.330385] sfp sfp-eth3: los 1 -> 0
> [   81.333978] sfp sfp-eth3: tx-fault 1 -> 0
> [   81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear
> [   81.344044] sfp sfp-eth3: SM: exit probe:up:down
> [   81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low
> [   81.354629] sfp sfp-eth3: SM: exit probe:up:down
> [   86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout
> [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> [   86.067758] sfp sfp-eth3: module OEM              V2801F
> rev 1.0  sn 202101195032     dc 210119
> [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> inband/1000base-x with support 0000000,00000200,00000440
> [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> [   86.092636] sfp sfp-eth3: SM: exit present:up:wait
> [   86.097448] sfp sfp-eth3: skipping hwmon device registration due to
> broken EEPROM
> [   86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> atomically to guarantee data coherency
> [   86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout
> [   86.166252] sfp sfp-eth3: SM: exit present:up:link_up
> [   86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full -
> flow control off
> [   86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
>
> In that way it goes up. So how can we avoid this behaviour?
>
> Thanks
>
> Il giorno lun 7 mar 2022 alle ore 20:13 Russell King (Oracle)
> <linux@armlinux.org.uk> ha scritto:
> >
> > Please keep follow-ups on the mailing list.
> >
> > On Mon, Mar 07, 2022 at 08:04:21PM +0100, Giammarco lynx wrote:
> > > ok may be i've enabled it, here is the output:
> > >
> > > root@mcbin:~# dmesg | grep eth3
> > > [    3.035655] mvpp2 f4000000.ethernet eth3: Using firmware node mac
> > > address 00:51:82:11:22:03
> > > [   11.759569] sfp sfp-eth3: Host maximum power 2.0W
> > > [   11.764323] sfp sfp-eth3: tx disable 1 -> 1
> > > [   11.764329] sfp sfp-eth3: SM: enter empty:detached:down event insert
> > > [   11.764333] sfp sfp-eth3: SFP_S_DOWN
> > > [   11.767925] sfp sfp-eth3: SM: exit probe:detached:down
> > > [   11.768259] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach
> > > [   11.768263] sfp sfp-eth3: SFP_MOD_PROBE
> > > [   11.772123] sfp sfp-eth3: SFP_S_DOWN
> > > [   11.775715] sfp sfp-eth3: SM: exit probe:down:down
> > > [   12.080088] sfp sfp-eth3: SM: enter probe:down:down event timeout
> > > [   12.080093] sfp sfp-eth3: SFP_MOD_PROBE
> > > [   12.091720] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > > [   12.098622] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > [   12.145814] sfp sfp-eth3: module OEM              V2801F
> > > rev 1.0  sn 202101195032     dc 210119
> > > [   12.155598] sfp sfp-eth3: module_t_start_up
> > > [   12.159799] sfp sfp-eth3: SFP_MOD_WAITDEV
> > > [   12.163834] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > inband/1000base-x with support 0000000,00000200,00000440
> > > [   12.163838] mvpp2 f4000000.ethernet eth3: switched to
> > > inband/1000base-x link mode
> > > [   12.171354] sfp sfp-eth3: SFP_S_DOWN
> > > [   12.174944] sfp sfp-eth3: SM: exit present:down:down
> > > [   12.174949] sfp sfp-eth3: skipping hwmon device registration due to
> > > broken EEPROM
> > > [   12.182465] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> > > atomically to guarantee data coherency
> > > [   58.634098] mvpp2 f4000000.ethernet eth3: configuring for
> > > inband/1000base-x link mode
> > > [   58.641979] mvpp2 f4000000.ethernet eth3: major config 1000base-x
> > > [   58.648113] mvpp2 f4000000.ethernet eth3: phylink_mac_config:
> > > mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440
> > > pause=04 link=0 an=1
> > > [   58.662900] sfp sfp-eth3: SM: enter present:down:down event dev_up
> > > [   58.669107] sfp sfp-eth3: SFP_MOD_PRESENT
> > > [   58.673137] sfp sfp-eth3: SFP_MOD_ERROR
> > > [   58.677019] sfp sfp-eth3: SFP_S_DOWN
> > > [   58.680643] sfp sfp-eth3: tx disable 1 -> 0
> > > [   58.684852] sfp sfp-eth3: SM: exit present:up:wait
> > > [   58.740088] sfp sfp-eth3: SM: enter present:up:wait event timeout
> > > [   58.746210] sfp sfp-eth3: SFP_MOD_PRESENT
> > > [   58.750243] sfp sfp-eth3: SFP_MOD_ERROR
> > > [   58.754094] sfp sfp-eth3: SFP_S_WAIT
> > > [   58.757682] sfp sfp-eth3: event == SFP_E_TIMEOUT
> > > [   58.762322] sfp sfp-eth3: SFP_F_TX_FAULT bit basso
> > > [   58.767164] sfp sfp-eth3: sfp_sm_link_check_los
> > > [   58.771715] sfp sfp-eth3: los ok
> > > [   58.774988] sfp sfp-eth3: SM: exit present:up:link_up
> > > root@mcbin:~#
> >
> > So yes, here we believe that the module is operational, but there
> > appears to be nothing from the MAC, meaning the 1000base-X link
> > didn't establish.
> >
> > If the module supports 2500base-x and 1000base-x, the problem could
> > be that the module is trying to use 2500base-x but is indicating
> > 1000base-x in its EEPROM.
> >
> > It could be trying to detect the speed at power-on time - have you
> > tried unplugging and re-plugging it after bringing the interface up?
> >
> > GPON modules seem to always be a pain to get working.
> >
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Mon, Mar 07, 2022 at 09:12:45PM +0100, Giammarco lynx wrote:
> Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx
> <stich86@gmail.com> ha scritto:
> > Then after "ifconfig eth3 up" i've removed and reinserted the SFP,
> > this is the log:
> >
> > [   56.127227] sfp sfp-eth3: module removed
> > [   56.131175] sfp sfp-eth3: tx disable 0 -> 1

TX_DISABLE asserted.

> > [   56.135432] sfp sfp-eth3: SM: exit empty:up:down
> > [   56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault
> > [   56.146103] sfp sfp-eth3: SM: exit empty:up:down
> > [   59.350731] sfp sfp-eth3: mod-def0 0 -> 1

Module inserted, and starts booting...

> > [   59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert
> > [   59.360619] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.686185] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.806179] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.926179] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.046178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.166178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.276177] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.386178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.506177] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.626176] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.746177] sfp sfp-eth3: please wait, module slow to respond
> > [   60.751982] sfp sfp-eth3: SM: exit probe:up:down
> > [   65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   65.846262] sfp sfp-eth3: SM: exit probe:up:down
> > [   70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   70.876192] sfp sfp-eth3: SM: exit probe:up:down
> > [   75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   75.926196] sfp sfp-eth3: SM: exit probe:up:down
> > [   80.896801] mvpp2 f4000000.ethernet eth3: mac link up

Link established with the host MAC at 1G, probably as part of the
module detecting what speed the host is operating at.

> > [   80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   80.966183] sfp sfp-eth3: SM: exit probe:up:down
> > [   81.330385] sfp sfp-eth3: los 1 -> 0
> > [   81.333978] sfp sfp-eth3: tx-fault 1 -> 0

Some of the modules IOs change state.

> > [   81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear
> > [   81.344044] sfp sfp-eth3: SM: exit probe:up:down
> > [   81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low
> > [   81.354629] sfp sfp-eth3: SM: exit probe:up:down
> > [   86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM

Module emulated EEPROM becomes readable about 27 seconds after
insertion Firmware probably almost finished booting.

> > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > rev 1.0  sn 202101195032     dc 210119
> > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > inband/1000base-x with support 0000000,00000200,00000440
> > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0

We've now detected what the module is, and we configure for it, which
the EEPROM indicates it supports 1200Mbaud, which is 1G speed.

> > [   86.092636] sfp sfp-eth3: SM: exit present:up:wait
> > [   86.097448] sfp sfp-eth3: skipping hwmon device registration due to
> > broken EEPROM
> > [   86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> > atomically to guarantee data coherency
> > [   86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout
> > [   86.166252] sfp sfp-eth3: SM: exit present:up:link_up

sfp.c determines link up...

> > [   86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full -
> > flow control off
> > [   86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready

Network device now indicates that link has been established at 1G
speed.

> > In that way it goes up. So how can we avoid this behaviour?

Very difficult to avoid it. My guess is that when you power up the
system with the module inserted, it sees the interface operating at
2.5G speed and locks itself to 2.5G speed.

Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
indicates that it supports 1G speed, so we switch the host interface
to 1000base-X, and that causes link to be lost (although I don't see
any sign of that happening in your debug.)

That means that the module has decided to use 2.5G speed, but its
reporting it supports 1G speed in the EEPROM... so its doing something
different. No surprises that the link fails to come up.

We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
module using the sfp_quirk_2500basex function to also indicate it
supports 2.5G speed:

	}, {
		// VSOL/CarlitoxxPro SFP can also work at 2.5G speed
		.part = "V2801F",
		.modes = sfp_quirk_2500basex,

However, we are always going to be stuck in the situation that this is
going to be unreliable. Whatever speed the network interface is in when
this module is inserted, it's going to lock to that speed. If we then
change it later, we'll never link.

A switch will likely only ever use one speed on its SFP port, meaning
it will always present 1000base-X, or it will always present 2500base-X,
so it will always work with a switch, but not a more capable MAC
interface that can switch between these at will.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

Hi Russell,

i've tried to change quirks on the sfp-bus.c, but without success:

root@mcbin:~# dmesg | grep eth3
[    3.035613] mvpp2 f4000000.ethernet eth3: Using firmware node mac
address 00:51:82:11:22:03
[   12.115130] sfp sfp-eth3: Host maximum power 2.0W
[   12.119867] sfp sfp-eth3: tx disable 1 -> 1
[   12.119873] sfp sfp-eth3: SM: enter empty:detached:down event insert
[   12.119877] sfp sfp-eth3: SM: exit probe:detached:down
[   12.120155] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach
[   12.120159] sfp sfp-eth3: SM: exit probe:down:down
[   12.420121] sfp sfp-eth3: SM: enter probe:down:down event timeout
[   12.427901] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
[   12.434811] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
[   12.482001] sfp sfp-eth3: module OEM              V2801F
rev 1.0  sn 202101195032     dc 210119
[   12.491796] mvpp2 f4000000.ethernet eth3: requesting link mode
inband/2500base-x with support 0000000,00000200,00008440
[   12.491799] sfp sfp-eth3: SM: exit present:down:down
[   12.520104] sfp sfp-eth3: skipping hwmon device registration due to
broken EEPROM
[   12.527618] sfp sfp-eth3: diagnostic EEPROM area cannot be read
atomically to guarantee data coherency
[   34.635760] mvpp2 f4000000.ethernet eth3: configuring for
inband/2500base-x link mode
[   34.643644] mvpp2 f4000000.ethernet eth3: major config 2500base-x
[   34.649768] mvpp2 f4000000.ethernet eth3: phylink_mac_config:
mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,00008440
pause=04 link=0 an=1
[   34.663452] sfp sfp-eth3: SM: enter present:down:down event dev_up
[   34.669658] sfp sfp-eth3: tx disable 1 -> 0
[   34.673893] sfp sfp-eth3: SM: exit present:up:wait
[   34.740110] sfp sfp-eth3: SM: enter present:up:wait event timeout
[   34.746236] sfp sfp-eth3: SM: exit present:up:link_up
[   57.613403] sfp sfp-eth3: los 0 -> 1
[   57.616998] sfp sfp-eth3: SM: enter present:up:link_up event los_high
[   57.623474] sfp sfp-eth3: SM: exit present:up:link_up
[   57.628555] sfp sfp-eth3: mod-def0 1 -> 0
[   57.632587] sfp sfp-eth3: tx-fault 0 -> 1
[   57.636615] sfp sfp-eth3: SM: enter present:up:link_up event remove
[   57.642912] sfp sfp-eth3: module removed
[   57.647018] sfp sfp-eth3: tx disable 0 -> 1
[   57.651236] sfp sfp-eth3: SM: exit empty:up:down
[   57.655872] sfp sfp-eth3: SM: enter empty:up:down event tx_fault
[   57.661940] sfp sfp-eth3: SM: exit empty:up:down
[   59.404709] sfp sfp-eth3: tx-fault 1 -> 0
[   59.408737] sfp sfp-eth3: SM: enter empty:up:down event tx_clear
[   59.414775] sfp sfp-eth3: SM: exit empty:up:down
[   59.419417] sfp sfp-eth3: mod-def0 0 -> 1
[   59.423445] sfp sfp-eth3: tx-fault 0 -> 1
[   59.427471] sfp sfp-eth3: SM: enter empty:up:down event insert
[   59.433333] sfp sfp-eth3: SM: exit probe:up:down
[   59.437968] sfp sfp-eth3: SM: enter probe:up:down event tx_fault
[   59.444003] sfp sfp-eth3: SM: exit probe:up:down
[   59.740106] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   61.836667] sfp sfp-eth3: SM: exit probe:up:down
[   61.940105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   61.946161] sfp sfp-eth3: SM: exit probe:up:down
[   62.050106] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.056159] sfp sfp-eth3: SM: exit probe:up:down
[   62.160105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.166158] sfp sfp-eth3: SM: exit probe:up:down
[   62.270105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.276159] sfp sfp-eth3: SM: exit probe:up:down
[   62.380105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.386159] sfp sfp-eth3: SM: exit probe:up:down
[   62.490105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.496160] sfp sfp-eth3: SM: exit probe:up:down
[   62.600105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.606160] sfp sfp-eth3: SM: exit probe:up:down
[   62.710105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.716159] sfp sfp-eth3: SM: exit probe:up:down
[   62.820105] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   62.826159] sfp sfp-eth3: please wait, module slow to respond
[   62.831965] sfp sfp-eth3: SM: exit probe:up:down
[   67.910109] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   67.916168] sfp sfp-eth3: SM: exit probe:up:down
[   72.950108] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   72.956167] sfp sfp-eth3: SM: exit probe:up:down
[   77.990111] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   77.996175] sfp sfp-eth3: SM: exit probe:up:down
[   81.427524] sfp sfp-eth3: los 1 -> 0
[   81.431121] sfp sfp-eth3: tx-fault 1 -> 0
[   81.435148] sfp sfp-eth3: SM: enter probe:up:down event tx_clear
[   81.441185] sfp sfp-eth3: SM: exit probe:up:down
[   81.445820] sfp sfp-eth3: SM: enter probe:up:down event los_low
[   81.451767] sfp sfp-eth3: SM: exit probe:up:down
[   83.030114] sfp sfp-eth3: SM: enter probe:up:down event timeout
[   83.043617] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
[   83.050525] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
[   83.097713] sfp sfp-eth3: module OEM              V2801F
rev 1.0  sn 202101195032     dc 210119
[   83.107507] mvpp2 f4000000.ethernet eth3: requesting link mode
inband/2500base-x with support 0000000,00000200,00008440
[   83.118375] sfp sfp-eth3: tx disable 1 -> 0
[   83.122621] sfp sfp-eth3: SM: exit present:up:wait
[   83.127435] sfp sfp-eth3: skipping hwmon device registration due to
broken EEPROM
[   83.134954] sfp sfp-eth3: diagnostic EEPROM area cannot be read
atomically to guarantee data coherency
[   83.180105] sfp sfp-eth3: SM: enter present:up:wait event timeout
[   83.186242] sfp sfp-eth3: SM: exit present:up:link_up
root@mcbin:~#

Please note that this stick should supporto HiSGMII (2500base-x), but
currently the firmware on-top seems stuck so link only at 1000base-x

At the moment we don't have any other solution than put interface UP
and then un-plug/plug module again?

Thanks,
Giammarco

Il giorno mar 8 mar 2022 alle ore 00:01 Russell King (Oracle)
<linux@armlinux.org.uk> ha scritto:
>
> On Mon, Mar 07, 2022 at 09:12:45PM +0100, Giammarco lynx wrote:
> > Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx
> > <stich86@gmail.com> ha scritto:
> > > Then after "ifconfig eth3 up" i've removed and reinserted the SFP,
> > > this is the log:
> > >
> > > [   56.127227] sfp sfp-eth3: module removed
> > > [   56.131175] sfp sfp-eth3: tx disable 0 -> 1
>
> TX_DISABLE asserted.
>
> > > [   56.135432] sfp sfp-eth3: SM: exit empty:up:down
> > > [   56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault
> > > [   56.146103] sfp sfp-eth3: SM: exit empty:up:down
> > > [   59.350731] sfp sfp-eth3: mod-def0 0 -> 1
>
> Module inserted, and starts booting...
>
> > > [   59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert
> > > [   59.360619] sfp sfp-eth3: SM: exit probe:up:down
> > > [   59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   59.686185] sfp sfp-eth3: SM: exit probe:up:down
> > > [   59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   59.806179] sfp sfp-eth3: SM: exit probe:up:down
> > > [   59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   59.926179] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.046178] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.166178] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.276177] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.386178] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.506177] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.626176] sfp sfp-eth3: SM: exit probe:up:down
> > > [   60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   60.746177] sfp sfp-eth3: please wait, module slow to respond
> > > [   60.751982] sfp sfp-eth3: SM: exit probe:up:down
> > > [   65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   65.846262] sfp sfp-eth3: SM: exit probe:up:down
> > > [   70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   70.876192] sfp sfp-eth3: SM: exit probe:up:down
> > > [   75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   75.926196] sfp sfp-eth3: SM: exit probe:up:down
> > > [   80.896801] mvpp2 f4000000.ethernet eth3: mac link up
>
> Link established with the host MAC at 1G, probably as part of the
> module detecting what speed the host is operating at.
>
> > > [   80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   80.966183] sfp sfp-eth3: SM: exit probe:up:down
> > > [   81.330385] sfp sfp-eth3: los 1 -> 0
> > > [   81.333978] sfp sfp-eth3: tx-fault 1 -> 0
>
> Some of the modules IOs change state.
>
> > > [   81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear
> > > [   81.344044] sfp sfp-eth3: SM: exit probe:up:down
> > > [   81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low
> > > [   81.354629] sfp sfp-eth3: SM: exit probe:up:down
> > > [   86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
>
> Module emulated EEPROM becomes readable about 27 seconds after
> insertion Firmware probably almost finished booting.
>
> > > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > > rev 1.0  sn 202101195032     dc 210119
> > > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > inband/1000base-x with support 0000000,00000200,00000440
> > > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
>
> We've now detected what the module is, and we configure for it, which
> the EEPROM indicates it supports 1200Mbaud, which is 1G speed.
>
> > > [   86.092636] sfp sfp-eth3: SM: exit present:up:wait
> > > [   86.097448] sfp sfp-eth3: skipping hwmon device registration due to
> > > broken EEPROM
> > > [   86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> > > atomically to guarantee data coherency
> > > [   86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout
> > > [   86.166252] sfp sfp-eth3: SM: exit present:up:link_up
>
> sfp.c determines link up...
>
> > > [   86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full -
> > > flow control off
> > > [   86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
>
> Network device now indicates that link has been established at 1G
> speed.
>
> > > In that way it goes up. So how can we avoid this behaviour?
>
> Very difficult to avoid it. My guess is that when you power up the
> system with the module inserted, it sees the interface operating at
> 2.5G speed and locks itself to 2.5G speed.
>
> Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
> indicates that it supports 1G speed, so we switch the host interface
> to 1000base-X, and that causes link to be lost (although I don't see
> any sign of that happening in your debug.)
>
> That means that the module has decided to use 2.5G speed, but its
> reporting it supports 1G speed in the EEPROM... so its doing something
> different. No surprises that the link fails to come up.
>
> We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
> module using the sfp_quirk_2500basex function to also indicate it
> supports 2.5G speed:
>
>         }, {
>                 // VSOL/CarlitoxxPro SFP can also work at 2.5G speed
>                 .part = "V2801F",
>                 .modes = sfp_quirk_2500basex,
>
> However, we are always going to be stuck in the situation that this is
> going to be unreliable. Whatever speed the network interface is in when
> this module is inserted, it's going to lock to that speed. If we then
> change it later, we'll never link.
>
> A switch will likely only ever use one speed on its SFP port, meaning
> it will always present 1000base-X, or it will always present 2500base-X,
> so it will always work with a switch, but not a more capable MAC
> interface that can switch between these at will.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Tue, Mar 08, 2022 at 11:08:34AM +0100, Giammarco lynx wrote:
> Hi Russell,
> 
> i've tried to change quirks on the sfp-bus.c, but without success:

Thanks for trying.

> Please note that this stick should supporto HiSGMII (2500base-x), but
> currently the firmware on-top seems stuck so link only at 1000base-x

I've seen that with some of the other modules (the alcatel/lucent ones)
where they won't switch to 2.5G unless they are on the PON network and
have been configured.

So this brings up a question - if it isn't switching to 2500base-X then
why doesn't it link when we're in 1000base-X mode. The only other
possibility I can think of would be SGMII, which will sync, but won't
complete the negotiation. The only way to know that would be to read
the GMAC STATUS0 register to see if bit 14 is set (meaning it has
gained sync) without bit 0 (link up.)

If you have devmem2, boot without the sfp-bus.c patch applied, bring
eth3 up, and then run:

# devmem2 0xf4133e10

which should dump the status0 register for eth3.

> At the moment we don't have any other solution than put interface UP
> and then un-plug/plug module again?

At the moment, sadly, yes.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

Hi Russell,

here is the output of devmem without sfp-bus.c quirk:

root@mcbin:~# devmem 0xf4133e10
0x0000600A
root@mcbin:~#

Thanks

Il giorno mar 8 mar 2022 alle ore 12:15 Russell King (Oracle)
<linux@armlinux.org.uk> ha scritto:
>
> On Tue, Mar 08, 2022 at 11:08:34AM +0100, Giammarco lynx wrote:
> > Hi Russell,
> >
> > i've tried to change quirks on the sfp-bus.c, but without success:
>
> Thanks for trying.
>
> > Please note that this stick should supporto HiSGMII (2500base-x), but
> > currently the firmware on-top seems stuck so link only at 1000base-x
>
> I've seen that with some of the other modules (the alcatel/lucent ones)
> where they won't switch to 2.5G unless they are on the PON network and
> have been configured.
>
> So this brings up a question - if it isn't switching to 2500base-X then
> why doesn't it link when we're in 1000base-X mode. The only other
> possibility I can think of would be SGMII, which will sync, but won't
> complete the negotiation. The only way to know that would be to read
> the GMAC STATUS0 register to see if bit 14 is set (meaning it has
> gained sync) without bit 0 (link up.)
>
> If you have devmem2, boot without the sfp-bus.c patch applied, bring
> eth3 up, and then run:
>
> # devmem2 0xf4133e10
>
> which should dump the status0 register for eth3.
>
> > At the moment we don't have any other solution than put interface UP
> > and then un-plug/plug module again?
>
> At the moment, sadly, yes.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Tue, Mar 08, 2022 at 12:54:09PM +0100, Giammarco lynx wrote:
> Hi Russell,
> 
> here is the output of devmem without sfp-bus.c quirk:
> 
> root@mcbin:~# devmem 0xf4133e10
> 0x0000600A

So yes, bit 14 is set, meaning it's in sync, but negotiation has not
completed. I think that probably means my theory that the module is
operating in SGMII mode is likely to be correct.

I would need to check, but I would guess that u-boot configures eth3
for SGMII at boot (despite it always being connected to a SFP cage
which doesn't actually make that much sense) and the SFP module
detects that the host is in SGMII mode at boot, and locks itself to
that.

When the kernel boots, it reconfigures the interface to be in
1000base-X mode, which would be way more sensible for the SFP cage
given that SFPs are normally used for fibre, and the GPON module
no longer links.

If we were to add hacks so that this module caused the mcbin to stay
in SGMII mode, this would break existing systems where the host
boots in 1000base-X mode, causing the module to lock to 1000base-X.
So, there is no solution here for the kernel that will work for
everyone.

This also means that what mode the module is in will depend on what
module was _previously_ inserted in the SFP cage, since that will
determine the host configuration at the point when the module is
inserted.

I guess the module has been designed with the assumption that the
host it is plugged into will only be capable of operating with a
single protocol.

I can't see a clean solution to this one that will work for everyone.
Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Fwd: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

so correct me if i'm wrong (and i haven't understood correctly):

the MCBIN seems to configure the interface on SGMII mode (and the GPON
switch on this mode), when the kernel starts it move the interface
mode in 1000base-X.
When i'm doing the unplug/plug, basically the GPON module see that
host is advertising 1000base-X and it negotiates in this way instead
of SGMII.

Is it right?

Thanks

Il giorno mar 8 mar 2022 alle ore 16:36 Russell King (Oracle)
<linux@armlinux.org.uk> ha scritto:
>
> On Tue, Mar 08, 2022 at 04:29:15PM +0100, Giammarco lynx wrote:
> > for "hack" you mean to force phy in SGMII into DTS?
>
> No, I meant to basically bodge the sfp/phylink layer detect this
> module and use SGMII mode for it. That's not easy to do with the way
> the code is presently structured.
>
> As I also mentioned, doing so will only end up causing other issues.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Pali Rohár]

On Tuesday 08 March 2022 11:15:08 Russell King (Oracle) wrote:
> I've seen that with some of the other modules (the alcatel/lucent ones)
> where they won't switch to 2.5G unless they are on the PON network and
> have been configured.

Those Alcatel/Lucent GPON SFP modules (including Nokia rebrands) choose
1000base-x vs 2500base-x speed on LAN port based on settings done via
OMCI from OLT.

With advanced OLT you can "force" that speed, even when SFP is already
plugged and running.

So if ISP decide that your LAN port is 1G-only then those Alcatel/Lucent
GPON SFP modules would never switch to 2500base-x mode with user CPU.

Russell, is there any option to ignore speed information stored in SFP
EEPROM and try to choose speed at linux runtime?

And how to correctly handle behavior of SFP module which changes speed
during usage time?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Sun, May 08, 2022 at 06:51:59PM +0200, Pali Rohár wrote:
> Russell, is there any option to ignore speed information stored in SFP
> EEPROM and try to choose speed at linux runtime?

If sfp_parse_support() fills in a support mask containing both
1000base-X and 2500base-X, then yes. By default, phylink will choose
2500base-X because that's the fastest speed. ethtool will report that
both 1000base-X and 2500base-X is supported, and 2500base-X is being
advertised.

If you change the advertisement to 1000base-X, then phylink will switch
to 1000base-X, and vice versa.

> And how to correctly handle behavior of SFP module which changes speed
> during usage time?

I know of no way that a SFP module can signal to the host that its host
interface has changed in some way. There is no provision for a module to
state what the host interface actually is of the module - most of what
the kernel does is heuristics based on modules that I've had available.

SFPs suck in this regard. GPON SFPs suck way harder because they claim
SFP MSA compliance but they always seem to be violating the SFP MSA in
some regard.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Pali Rohár]

On Monday 09 May 2022 16:41:14 Russell King (Oracle) wrote:
> On Sun, May 08, 2022 at 06:51:59PM +0200, Pali Rohár wrote:
> > Russell, is there any option to ignore speed information stored in SFP
> > EEPROM and try to choose speed at linux runtime?
> 
> If sfp_parse_support() fills in a support mask containing both
> 1000base-X and 2500base-X, then yes. By default, phylink will choose
> 2500base-X because that's the fastest speed. ethtool will report that
> both 1000base-X and 2500base-X is supported, and 2500base-X is being
> advertised.
> 
> If you change the advertisement to 1000base-X, then phylink will switch
> to 1000base-X, and vice versa.

I see...

> > And how to correctly handle behavior of SFP module which changes speed
> > during usage time?
> 
> I know of no way that a SFP module can signal to the host that its host
> interface has changed in some way. There is no provision for a module to
> state what the host interface actually is of the module - most of what
> the kernel does is heuristics based on modules that I've had available.

One GPON module which I tested, signals TX_FAULT when CPU tried to link
at wrong speed. This is just my observation, nor sure if it is
coincidence...

So when kernel set phylink to 2500base-x and GPON SFP module expected
CPU to set phylink to 1000base-x then kernel received TX_FAULT. After I
switched 2500base-x to 1000base-x TX_FAULT stopped and link started
working.

Btw, what does TX_FAULT signal means?

> SFPs suck in this regard. GPON SFPs suck way harder because they claim
> SFP MSA compliance but they always seem to be violating the SFP MSA in
> some regard.

Yes, this sucks. Importance is that GPON ONU/ONT box (either in media
box form factor or SFP form factor) is compliant to GPON standards and
then that is also compliant to the vendor OMCI extension for correct
provisioning from vendor OLT. For SFP the last importance is that it
works in vendor's media box with SFP cage. And that is all. Nobody care
about SFF standards compliance.

I do not know what we can done here. Maybe SFP subsystem should cycle
between phy modes returned by sfp_parse_support() until one start
working?

Dedicated GPON media boxes are in better shape because they have RJ45
with copper ethernet over twisted pair and this has standardized
autonegotiation of speed. So here if provisioning force speed 1Gbps then
on LAN RJ45 port is mode changed to 1000base-t.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Mon, May 09, 2022 at 07:08:32PM +0200, Pali Rohár wrote:
> One GPON module which I tested, signals TX_FAULT when CPU tried to link
> at wrong speed. This is just my observation, nor sure if it is
> coincidence...
> 
> So when kernel set phylink to 2500base-x and GPON SFP module expected
> CPU to set phylink to 1000base-x then kernel received TX_FAULT. After I
> switched 2500base-x to 1000base-x TX_FAULT stopped and link started
> working.

If that's what that GPON module does, that's another invention by a
GPON SFP manufacturer.

> Btw, what does TX_FAULT signal means?

In the SFP MSA, an asserted TX_FAULT means that there is some kind of
laser fault with the module.

So, using TX_FAULT to signal "host, you got the interface speed wrong"
is very much some GPON module manufacturers invention.

> Yes, this sucks. Importance is that GPON ONU/ONT box (either in media
> box form factor or SFP form factor) is compliant to GPON standards and
> then that is also compliant to the vendor OMCI extension for correct
> provisioning from vendor OLT. For SFP the last importance is that it
> works in vendor's media box with SFP cage. And that is all. Nobody care
> about SFF standards compliance.
> 
> I do not know what we can done here. Maybe SFP subsystem should cycle
> between phy modes returned by sfp_parse_support() until one start
> working?
> 
> Dedicated GPON media boxes are in better shape because they have RJ45
> with copper ethernet over twisted pair and this has standardized
> autonegotiation of speed. So here if provisioning force speed 1Gbps then
> on LAN RJ45 port is mode changed to 1000base-t.

Maybe the right answer is we just stop trying to support GPON modules
with all their random manufacturer specific quirks and odd behaviours.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Pali Rohár]

Hello!

On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote:
> > > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > > rev 1.0  sn 202101195032     dc 210119
> > > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > inband/1000base-x with support 0000000,00000200,00000440
> > > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> 
> We've now detected what the module is, and we configure for it, which
> the EEPROM indicates it supports 1200Mbaud, which is 1G speed.
...
> > > In that way it goes up. So how can we avoid this behaviour?
> 
> Very difficult to avoid it. My guess is that when you power up the
> system with the module inserted, it sees the interface operating at
> 2.5G speed and locks itself to 2.5G speed.
> 
> Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
> indicates that it supports 1G speed, so we switch the host interface
> to 1000base-X, and that causes link to be lost (although I don't see
> any sign of that happening in your debug.)
> 
> That means that the module has decided to use 2.5G speed, but its
> reporting it supports 1G speed in the EEPROM... so its doing something
> different. No surprises that the link fails to come up.
> 
> We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
> module using the sfp_quirk_2500basex function to also indicate it
> supports 2.5G speed:
> 
> 	}, {
> 		// VSOL/CarlitoxxPro SFP can also work at 2.5G speed
> 		.part = "V2801F",
> 		.modes = sfp_quirk_2500basex,

RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP
cannot operate on CPU side at 2500base-x nor in other way at 2.5G.

Trying to "force" mode to 2500base-x would not work.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Giammarco lynx]

Hi Pali,

no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support
HiSGMII mode. I’m currently running another stick (DFP-34X-C2C) at
2.5GbE with my FTTH line here in Italy :)

the problem seems related only to SFP driver of macchiato-bin, into a
BCM57810s, the stick is working as expected ;)

Il giorno dom 8 mag 2022 alle ore 18:31 Pali Rohár <pali@kernel.org> ha scritto:
>
> Hello!
>
> On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote:
> > > > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > > > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > > > rev 1.0  sn 202101195032     dc 210119
> > > > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > > inband/1000base-x with support 0000000,00000200,00000440
> > > > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> >
> > We've now detected what the module is, and we configure for it, which
> > the EEPROM indicates it supports 1200Mbaud, which is 1G speed.
> ...
> > > > In that way it goes up. So how can we avoid this behaviour?
> >
> > Very difficult to avoid it. My guess is that when you power up the
> > system with the module inserted, it sees the interface operating at
> > 2.5G speed and locks itself to 2.5G speed.
> >
> > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
> > indicates that it supports 1G speed, so we switch the host interface
> > to 1000base-X, and that causes link to be lost (although I don't see
> > any sign of that happening in your debug.)
> >
> > That means that the module has decided to use 2.5G speed, but its
> > reporting it supports 1G speed in the EEPROM... so its doing something
> > different. No surprises that the link fails to come up.
> >
> > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
> > module using the sfp_quirk_2500basex function to also indicate it
> > supports 2.5G speed:
> >
> >       }, {
> >               // VSOL/CarlitoxxPro SFP can also work at 2.5G speed
> >               .part = "V2801F",
> >               .modes = sfp_quirk_2500basex,
>
> RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP
> cannot operate on CPU side at 2500base-x nor in other way at 2.5G.
>
> Trying to "force" mode to 2500base-x would not work.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Pali Rohár]

On Monday 09 May 2022 13:13:04 Giammarco lynx wrote:
> Hi Pali,
> 
> no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support
> HiSGMII mode.

Hello! That is really interesting, because I was told that RTL8672 and
RTL9601C support only 1000base-x.

Maybe RTL9601CI and RTL9601D chips are new version with support for
2500base-x? I have no idea.

Anyway, if you have some datasheet or source of information that it
supports 2500base-x mode, I would really like to see it.

> I’m currently running another stick (DFP-34X-C2C) at
> 2.5GbE with my FTTH line here in Italy :)
> 
> the problem seems related only to SFP driver of macchiato-bin, into a
> BCM57810s, the stick is working as expected ;)
> 
> Il giorno dom 8 mag 2022 alle ore 18:31 Pali Rohár <pali@kernel.org> ha scritto:
> >
> > Hello!
> >
> > On Monday 07 March 2022 23:01:18 Russell King (Oracle) wrote:
> > > > > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > > > > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > > > > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > > > > rev 1.0  sn 202101195032     dc 210119
> > > > > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > > > > inband/1000base-x with support 0000000,00000200,00000440
> > > > > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> > >
> > > We've now detected what the module is, and we configure for it, which
> > > the EEPROM indicates it supports 1200Mbaud, which is 1G speed.
> > ...
> > > > > In that way it goes up. So how can we avoid this behaviour?
> > >
> > > Very difficult to avoid it. My guess is that when you power up the
> > > system with the module inserted, it sees the interface operating at
> > > 2.5G speed and locks itself to 2.5G speed.
> > >
> > > Eventually, our kernel boots, and sfp reads the EEPROM. The EEPROM
> > > indicates that it supports 1G speed, so we switch the host interface
> > > to 1000base-X, and that causes link to be lost (although I don't see
> > > any sign of that happening in your debug.)
> > >
> > > That means that the module has decided to use 2.5G speed, but its
> > > reporting it supports 1G speed in the EEPROM... so its doing something
> > > different. No surprises that the link fails to come up.
> > >
> > > We could add an entry to the sfp_quirks[] table in sfp-bus.c for this
> > > module using the sfp_quirk_2500basex function to also indicate it
> > > supports 2.5G speed:
> > >
> > >       }, {
> > >               // VSOL/CarlitoxxPro SFP can also work at 2.5G speed
> > >               .part = "V2801F",
> > >               .modes = sfp_quirk_2500basex,
> >
> > RTL8672/RTL9601C chips support only 1000base-x mode and therefore SFP
> > cannot operate on CPU side at 2500base-x nor in other way at 2.5G.
> >
> > Trying to "force" mode to 2500base-x would not work.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Russell King (Oracle)]

On Mon, May 09, 2022 at 01:09:52PM +0200, les stich wrote:
> Hi Pali,
> 
> no, the stick can do 2.5GbE. Both RTL9601CI and RTL 9601D support HiSGMII mode. I’m currently running another stick (DFP-34X-C2C) at 2.5GbE with my FTTH line here in Italy :)
> 
> the problem seems related only to SFP driver of macchiato-bin, into a BCM57810s, the stick is working as expected ;)

It's entirely possible that the problem is not software, but hardware.
GPON modules have a dying gasp signal on one of the pins, which if
memory serves me correctly, is set to the wrong logic sense on the
SolidRun Clearfog A388 and Macchiatobin platforms.

I seem to remember that the GPON modules I have don't work in either
of these machines for this reason.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)

[Pali Rohár]

On Monday 07 March 2022 21:12:45 Giammarco lynx wrote:
> adding
> 
> linux-arm-kernel@lists.infradead.org
> 
> Il giorno lun 7 mar 2022 alle ore 21:09 Giammarco lynx
> <stich86@gmail.com> ha scritto:
> >
> > ok, doing in the way that you suggest, the link is bringing up.
> > Here is the logs (without ifconfig eth3 up and module plugged):
> >
> > [    3.035643] mvpp2 f4000000.ethernet eth3: Using firmware node mac
> > address 00:51:82:11:22:03
> > [   11.872410] sfp sfp-eth3: Host maximum power 2.0W
> > [   11.877149] sfp sfp-eth3: tx disable 1 -> 1
> > [   11.877155] sfp sfp-eth3: SM: enter empty:detached:down event insert
> > [   11.877159] sfp sfp-eth3: SM: exit probe:detached:down
> > [   11.877410] sfp sfp-eth3: SM: enter probe:detached:down event dev_attach
> > [   11.877414] sfp sfp-eth3: SM: exit probe:down:down
> > [   12.180129] sfp sfp-eth3: SM: enter probe:down:down event timeout
> > [   12.187906] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > [   12.194814] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > [   12.242005] sfp sfp-eth3: module OEM              V2801F
> > rev 1.0  sn 202101195032     dc 210119
> > [   12.251800] mvpp2 f4000000.ethernet eth3: requesting link mode
> > inband/1000base-x with support 0000000,00000200,00000440
> > [   12.251804] mvpp2 f4000000.ethernet eth3: switched to
> > inband/1000base-x link mode
> > [   12.259318] sfp sfp-eth3: SM: exit present:down:down
> > [   12.270123] sfp sfp-eth3: skipping hwmon device registration due to
> > broken EEPROM
> > [   12.277636] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> > atomically to guarantee data coherency
> > [   35.174143] mvpp2 f4000000.ethernet eth3: configuring for
> > inband/1000base-x link mode
> > [   35.182026] mvpp2 f4000000.ethernet eth3: major config 1000base-x
> > [   35.188158] mvpp2 f4000000.ethernet eth3: phylink_mac_config:
> > mode=inband/1000base-x/Unknown/Unknown adv=0000000,00000200,00000440
> > pause=04 link=0 an=1
> > [   35.202945] sfp sfp-eth3: SM: enter present:down:down event dev_up
> > [   35.209152] sfp sfp-eth3: tx disable 1 -> 0
> > [   35.213387] sfp sfp-eth3: SM: exit present:up:wait
> > [   35.280129] sfp sfp-eth3: SM: enter present:up:wait event timeout
> > [   35.286253] sfp sfp-eth3: SM: exit present:up:link_up
> > [   56.097724] sfp sfp-eth3: los 0 -> 1
> > [   56.101324] sfp sfp-eth3: SM: enter present:up:link_up event los_high
> > [   56.107792] sfp sfp-eth3: SM: exit present:up:link_up
> > [   56.112876] sfp sfp-eth3: mod-def0 1 -> 0
> > [   56.116903] sfp sfp-eth3: tx-fault 0 -> 1
> > [   56.120933] sfp sfp-eth3: SM: enter present:up:link_up event remove
> >
> > Then after "ifconfig eth3 up" i've removed and reinserted the SFP,
> > this is the log:
> >
> > [   56.127227] sfp sfp-eth3: module removed
> > [   56.131175] sfp sfp-eth3: tx disable 0 -> 1
> > [   56.135432] sfp sfp-eth3: SM: exit empty:up:down
> > [   56.140067] sfp sfp-eth3: SM: enter empty:up:down event tx_fault
> > [   56.146103] sfp sfp-eth3: SM: exit empty:up:down
> > [   59.350731] sfp sfp-eth3: mod-def0 0 -> 1
> > [   59.354757] sfp sfp-eth3: SM: enter empty:up:down event insert
> > [   59.360619] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.680123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.686185] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.800122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.806179] sfp sfp-eth3: SM: exit probe:up:down
> > [   59.920122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   59.926179] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.040122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.046178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.160123] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.166178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.270122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.276177] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.380122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.386178] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.500122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.506177] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.620121] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.626176] sfp sfp-eth3: SM: exit probe:up:down
> > [   60.740122] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   60.746177] sfp sfp-eth3: please wait, module slow to respond
> > [   60.751982] sfp sfp-eth3: SM: exit probe:up:down
> > [   65.840198] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   65.846262] sfp sfp-eth3: SM: exit probe:up:down
> > [   70.870128] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   70.876192] sfp sfp-eth3: SM: exit probe:up:down
> > [   75.920133] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   75.926196] sfp sfp-eth3: SM: exit probe:up:down
> > [   80.896801] mvpp2 f4000000.ethernet eth3: mac link up
> > [   80.960124] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   80.966183] sfp sfp-eth3: SM: exit probe:up:down
> > [   81.330385] sfp sfp-eth3: los 1 -> 0
> > [   81.333978] sfp sfp-eth3: tx-fault 1 -> 0
> > [   81.338004] sfp sfp-eth3: SM: enter probe:up:down event tx_clear
> > [   81.344044] sfp sfp-eth3: SM: exit probe:up:down
> > [   81.348680] sfp sfp-eth3: SM: enter probe:up:down event los_low
> > [   81.354629] sfp sfp-eth3: SM: exit probe:up:down
> > [   86.000154] sfp sfp-eth3: SM: enter probe:up:down event timeout
> > [   86.013661] sfp sfp-eth3: Detected broken RTL8672/RTL9601C emulated EEPROM
> > [   86.020569] sfp sfp-eth3: Switching to reading EEPROM to one byte at a time
> > [   86.067758] sfp sfp-eth3: module OEM              V2801F
> > rev 1.0  sn 202101195032     dc 210119
> > [   86.077555] mvpp2 f4000000.ethernet eth3: requesting link mode
> > inband/1000base-x with support 0000000,00000200,00000440
> > [   86.088390] sfp sfp-eth3: tx disable 1 -> 0
> > [   86.092636] sfp sfp-eth3: SM: exit present:up:wait
> > [   86.097448] sfp sfp-eth3: skipping hwmon device registration due to
> > broken EEPROM
> > [   86.104965] sfp sfp-eth3: diagnostic EEPROM area cannot be read
> > atomically to guarantee data coherency
> > [   86.160128] sfp sfp-eth3: SM: enter present:up:wait event timeout
> > [   86.166252] sfp sfp-eth3: SM: exit present:up:link_up
> > [   86.171404] mvpp2 f4000000.ethernet eth3: Link is Up - 1Gbps/Full -
> > flow control off
> > [   86.179193] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
> >
> > In that way it goes up. So how can we avoid this behaviour?
> >
> > Thanks

Hello! This looks like that your GPON ONT/ONU SFP module is incompatible
with GPON OLT to which it is connected. All GPON ONT/ONU units must be
fully configurable from OLT, including LAN part of ONU (link between SFP
module and your CPU) and therefore it is up to the OLT when it says that
LAN part is up. Mostly I saw these issues with GPON ONT/ONU modules from
vendor A connected to GPON OLT from vendor B.

Generally, you cannot do nothing :-( just replace SFP module by another
one which would be from the same vendor as your ISP's OLT. Sometimes may
help changing some settings in SFP module or on OLT side, but both
changes can be done only via OMCI protocol and only from OLT management
console / web interface.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel