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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 28 Mar 2023 21:56:14 +0100
From:   Daniel Golle <daniel@...rotopia.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 2/2] net: sfp: add quirk for 2.5G copper SFP

On Tue, Mar 28, 2023 at 08:16:09PM +0100, Russell King (Oracle) wrote:
> 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

Yes, this is all TL-SM410U. Just one time with the qurik added and one
time without. It can be that OpenWrt's netifd issues some ethtool
ioctls...

> 
> 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!