From: Andrew Lunn <andrew@lunn.ch>
To: Robert Hancock <robert.hancock@calian.com>
Cc: "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: phy: marvell: add special handling of Finisar modules with 81E1111
Date: Tue, 20 Oct 2020 00:12:32 +0200 [thread overview]
Message-ID: <20201019221232.GB139700@lunn.ch> (raw)
In-Reply-To: <1f3243e15a8600dd9876b97410b450029674c50c.camel@calian.com>
> 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.
There are different things here. What ethtool reports, and what is
programmed into the advertise register. Clearly, you don't want it
advertising 10 and 100 modes. If somebody connects it to a 10Half link
partner, you need auto-get to fail. You don't want auto-neg to
succeed, and then all the frames get thrown away with bad CRCs,
overruns etc.
> 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.
But as far as i know you can only report duplex and pause over
1000BaseX, not speed, since it is always 1G.
It would be interesting to run ethtool on the link partner to see what
it thinks the SFP is advertising. If it just 1000BaseT/Full?
Andrew
next prev parent reply other threads:[~2020-10-19 22:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 20:49 [PATCH] net: phy: marvell: add special handling of Finisar modules with 81E1111 Robert Hancock
2020-10-19 21:00 ` Andrew Lunn
2020-10-19 21:43 ` Robert Hancock
2020-10-19 21:59 ` Andrew Lunn
2020-10-19 22:11 ` Robert Hancock
2020-10-19 21:06 ` Andrew Lunn
2020-10-19 21:09 ` Russell King - ARM Linux admin
2020-10-19 21:08 ` Russell King - ARM Linux admin
2020-10-19 21:32 ` Robert Hancock
2020-10-19 21:45 ` Andrew Lunn
2020-10-19 21:59 ` Robert Hancock
2020-10-19 22:12 ` Andrew Lunn [this message]
2020-10-19 22:21 ` Russell King - ARM Linux admin
2020-10-19 22:26 ` Robert Hancock
2020-10-19 22:03 ` Russell King - ARM Linux admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019221232.GB139700@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=robert.hancock@calian.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).