Re: [PATCH net-next 2/2] net: sfp: add quirk for 2.5G copper SFP

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Mar 28, 2023 at 07:28:53PM +0100, Daniel Golle wrote:
> Hi Russell,
> 
> On Tue, Mar 28, 2023 at 04:10:58PM +0100, Russell King (Oracle) wrote:
> > Hi Daniel,
> > 
> > Any feedback with this patch applied? Can't move forward without that.
> 
> Sorry for the delay, I only got back to it today.
> I've tried your patch and do not see any additional output on the
> kernel log, just like it is the case for Frank's 2.5G SFP module as
> well. I conclude that the PHY is inaccessible.
> 
> I've tried with and without the sfp_quirk_oem_2_5g.
> 
> With the quirk:
> [   55.111856] mt7530 mdio-bus:1f sfp2: Link is Up - Unknown/Unknown - flow control off
> 
> Without the quirk:
> [   44.603495] mt7530 mdio-bus:1f sfp2: unsupported SFP module: no common interface modes

This is all getting really very messy, and I have no idea what's going
on and which modules you're testing from report to report.

The patch was to be used with the module which you previously reported
earlier in this thread:

[   17.344155] sfp sfp2: module TP-LINK          TL-SM410U        rev 1.0  sn    12154J6000864    dc 210606
...
[   21.653812] mt7530 mdio-bus:1f sfp2: selection of interface failed, advertisement 00,00000000,00000000,00006440

That second message - "selection of interface failed" only appears in
two places:

1) in phylink_ethtool_ksettings_set() which will be called in response
to ethtool being used, but you've said it isn't, so this can't be it.
2) in phylink_sfp_config_phy(), which will be called when we have
detected a PHY on the SFP module and we're trying to set it up.
This means we must have discovered a PHY on the TL-SM410U module.

This new message you report:

	"unsupported SFP module: no common interface modes"

is produced by phylink_sfp_config_optical(), which is called when we
think we have an optical module (in other words when sfp_may_have_phy()
returns false) or it returns true but we start the module without
having discovered a PHY.

So we can only get to this message if we think the module does not
have a PHY detected.

If it's the exact same module, that would suggest that the module does
have an accessible PHY, but there could be a hardware race between the
PHY becoming accessible and our probing for it. However, we do retry
probing for the PHY up to 12 times at 50ms intervals.

Maybe you could shed some light on what's going on? Is it the exact
same module? Maybe enable debugging in both sfp.c

At the moment I'm rather confused.

Thanks.

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