Re: MacchiatoBin SingleShot 2500BASE-X port (eth3) with GPON SFP on mvpp2x

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

Hi Marc,

Sorry I haven't been back to you yet, I've been struggling with some
other issues.

On Wed, Mar 13, 2019 at 11:45:47AM -0400, Marc Micalizzi wrote:
> So for testing I patched sfp-bus.c with the special case for the
> module (not sure if the patch would conform to good form for the
> kernel or not, but it seems functional)--shows up on ethtool as 2500
> now, and seems to work--but I'm not able to fully test it
> unfortunately (so I'm not sure if there would need to be additional
> changes to have it working or not).
> 
> ------
> diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
> index ad9db65..079ee5c 100644
> --- a/drivers/net/phy/sfp-bus.c
> +++ b/drivers/net/phy/sfp-bus.c
> @@ -233,6 +233,11 @@ void sfp_parse_support(struct sfp_bus *bus, const
> struct sfp_eeprom_id *id,
>                         phylink_set(modes, 1000baseX_Full);
>         }
> 
> +       if (!memcmp(id->base.vendor_name, "HUAWEI          ", 16) &&
> +           !memcmp(id->base.vendor_pn  , "MA5671A         ", 16)) {
> +               phylink_set(modes, 2500baseX_Full);
> +       }
> +
>         bitmap_or(support, support, modes, __ETHTOOL_LINK_MODE_MASK_NBITS);
> 
>         phylink_set(support, Autoneg);

That is good enough.

> ------
> 
> What I've discovered though, when I went to test it, is while the 2
> SFPs that I bought do come up eventually (between 120-300 seconds or
> so after plug/cold boot for the eeprom to be readable, followed by mac
> link up), my ISP provided SFP, despite being the same model number and
> revision, actually does never come up (or at least not over 10 minutes
> or so). No EEPROM read and no mac link up. It does, however, still
> work in my server with the modified (to support SC modules and link at
> 2500BaseX) bnx2x, and also with ixgbe (albeit not at 2500BaseX).

Presumably when the module is plugged into these other cards, it comes
up faster, and the EEPROM is readable before the 120-300 seconds it
seems to take on the mcbin?  Maybe if we knew why it takes that long
we may have a clue why the other module never comes up.

> I'll see if I can find any useful information off the SFP for figuring
> out why one works and the other doesn't, maybe it's a different
> software version running on the SFP? But at this point I'm at a bit of
> a loss again. Unfortunately, I'd have to have my ISP switch the SLIC
> ID to the other SFP to test with it, if they were even willing to, and
> then there would be no guarantee that a software update pushed over
> OMCI wouldn't break it too.

There are two different initialisation scenarios that the SFP
specifications permit - powering on/hotplugging with TX_DISABLE
asserted (which is what we do) and powering on/hotplugging with
TX_DISABLE negated.

I really don't want to change to the negated style because it means
that an optical modules laser will become active as soon as the module
is plugged in, and if you happen to be looking into the module while
plugging it in (eg, it's at eye-level height) that wouldn't be good.
LED based modules (as opposed to laser modules) aren't a concern of
course.

If you want to try the "other" style of initialisation, towards the
top of sfp_sm_event(), change:

                if (event == SFP_E_INSERT && sfp->attached) {
-                       sfp_module_tx_disable(sfp);
+                       sfp_module_tx_enable(sfp);
                        sfp_sm_ins_next(sfp, SFP_MOD_PROBE, T_PROBE_INIT);

and see whether that makes a difference.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

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