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!