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. -- Bjarni Jonasson, Microchip
