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

[Russell King - ARM Linux admin]

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!