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
| ||
|
Message-ID: <ZCM8+dsOo8c6TRJT@shell.armlinux.org.uk> Date: Tue, 28 Mar 2023 20:16:09 +0100 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Daniel Golle <daniel@...rotopia.org> 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 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!
Powered by blists - more mailing lists