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

From: "Pali Rohár" <pali@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Giammarco lynx <stich86@gmail.com>, linux-arm-kernel@lists.infradead.org
Subject: Re: Question abount VSOL/CarlitoxxPro SFP Patch on Marvell Armada (MCBIN DS)
Date: Mon, 9 May 2022 19:08:32 +0200	[thread overview]
Message-ID: <20220509170832.4wchp4tje2fvhpyh@pali> (raw)
In-Reply-To: <Ynk2Gij+5C/Hb5Mk@shell.armlinux.org.uk>

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