netdev - Re: [PATCH] phy: phylink: Fix CuSFP issue in phylink

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201115121921.GI1551@shell.armlinux.org.uk>
Date:   Sun, 15 Nov 2020 12:19:21 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Bjarni Jonasson <bjarni.jonasson@...rochip.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        UNGLinuxDriver <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH] phy: phylink: Fix CuSFP issue in phylink

On Wed, Nov 11, 2020 at 09:52:18AM +0100, Bjarni Jonasson wrote:
> 
> Russell King - ARM Linux admin writes:
> 
> > On Tue, Nov 10, 2020 at 03:16:34PM +0100, Bjarni Jonasson wrote:
> >>
> >> Russell King - ARM Linux admin writes:
> >>
> >> > On Tue, Nov 10, 2020 at 11:06:42AM +0100, Bjarni Jonasson wrote:
> >> >> There is an issue with the current phylink driver and CuSFPs which
> >> >> results in a callback to the phylink validate function without any
> >> >> advertisement capabilities.  The workaround (in this changeset)
> >> >> is to assign capabilities if a 1000baseT SFP is identified.
> >> >
> >> > How does this happen?  Which PHY is being used?
> >>
> >> This occurs just by plugging in the CuSFP.
> >> None of the CuSFPs we have tested are working.
> >> This is a dump from 3 different CuSFPs, phy regs 0-3:
> >> FS SFP: 01:40:79:49
> >> HP SFP: 01:40:01:49
> >> Marvel SFP: 01:40:01:49
> >> This was working before the delayed mac config was implemented (in dec
> >> 2019).
> >
> > You're dumping PHY registers 0 and 1 there, not 0 through 3, which
> > the values confirm. I don't recognise the format either. PHY registers
> > are always 16-bit.
> Sorry about that. Here is it again:
> Marvell SFP : 0x0140 0x0149 0x0141 0x0cc1
> FS SFP      : 0x1140 0x7949 0x0141 0x0cc2
> Cisco SFP   : 0x0140 0x0149 0x0141 0x0cc1
> I.e. its seems to be a Marvell phy (0x0141) in all cases.
> And this occurs when phylink_start() is called.

So they're all 88E1111 devices, which is the most common PHY for
CuSFPs.

Do you have the Marvell PHY driver either built-in or available as a
module? I suspect the problem is you don't. You will need the Marvell
PHY driver to correctly drive the PHY, you can't rely on the fallback
driver for SFPs.

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