[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1f3243e15a8600dd9876b97410b450029674c50c.camel@calian.com>
Date: Mon, 19 Oct 2020 21:59:09 +0000
From: Robert Hancock <robert.hancock@...ian.com>
To: "andrew@...n.ch" <andrew@...n.ch>
CC: "linux@...linux.org.uk" <linux@...linux.org.uk>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: phy: marvell: add special handling of Finisar
modules with 81E1111
On Mon, 2020-10-19 at 23:45 +0200, Andrew Lunn wrote:
> > I have a local patch that just falls back to trying 1000BaseX mode
> > if the driver reports SGMII isn't supported and it seems like it
> > might be a copper module, but that is a bit of a hack that may need
> > to be handled differently.
>
> Do you also modify what the PHY is advertising to remove the modes
> your cannot support?
I think in my case those extra modes only supported in SGMII mode, like
10 and 100Mbps modes, effectively get filtered out because the MAC
doesn't support them in the 1000BaseX mode either. But yes, that
probably should be fixed up in the PHY capabilities in a "proper"
solution.
The auto-negotiation is a bit of a weird thing in this case, as there
are two negotiations occurring, the 1000BaseX between the PCS/PMA PHY
and the module PHY, and the 1000BaseT between the module PHY and the
copper link partner. I believe the 88E1111 has some smarts to delay the
copper negotiation until it gets the advertisement over 1000BaseX, uses
those to figure out its advertisement, and then uses the copper link
partner's response to determine the 1000BaseX response.
--
Robert Hancock
Senior Hardware Designer, Advanced Technologies
www.calian.com
Powered by blists - more mailing lists