[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGKn8c2W1SI2CPq4@shell.armlinux.org.uk>
Date: Mon, 15 May 2023 22:45:21 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Daniel Machon <daniel.machon@...rochip.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Felix Fietkau <nbd@....name>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Horatiu Vultur <horatiu.vultur@...rochip.com>,
Ioana Ciornei <ioana.ciornei@....com>,
Jakub Kicinski <kuba@...nel.org>, John Crispin <john@...ozen.org>,
Jose Abreu <Jose.Abreu@...opsys.com>,
Lars Povlsen <lars.povlsen@...rochip.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Marcin Wojtas <mw@...ihalf.com>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Paolo Abeni <pabeni@...hat.com>, Sean Wang <sean.wang@...iatek.com>,
Steen Hegelund <Steen.Hegelund@...rochip.com>,
Taras Chornyi <taras.chornyi@...ision.eu>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
UNGLinuxDriver@...rochip.com, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] Providing a helper for PCS inband negotiation
On Mon, May 15, 2023 at 10:56:16PM +0300, Vladimir Oltean wrote:
> Hello,
>
> On Mon, May 15, 2023 at 01:22:50PM +0100, Russell King (Oracle) wrote:
> > 1. Should 10GBASE-KR be included in the SGMII et.al. case in the code?
> > Any other interface modes that should be there? Obviously,
> > PHYLINK_PCS_NEG_NONE is not correct for 10GBASE-KR since it does use
> > inband AN. Does it make sense for the user to disable inband AN for
> > 10GBASE-KR? If so, maybe it should be under the 1000base-X case.
>
> What physical process (reference to IEEE 802.3 clause is fine) would be
> controlled by the phylink_pcs_neg_mode() function for the so-called
> 10GBASE-KR phy-mode?
Clause 73.1:
"While implementation of Auto-Negotiation is mandatory for Backplane
Ethernet PHY s, the use of Auto-Negotiation is optional."
"The Auto-Negotiation function allows the devices to switch between
the various operational modes in an orderly fashion, permits
management to disable or enable the Auto-Negotiation function, and
allows management to select a specific operational mode."
"The Auto-Negotiation function also provides a parallel detection
function to allow Backplane Ethernet devices to connect to other
Backplane Ethernet devices that have Auto-Negotiation disabled and
interoperate with legacy devices that do not support Clause 73
Auto-Negotiation."
So, my reading of these statements is that the _user_ should be
able to control via ethtool whether Clause 73 negotiation is
performed on a 10GBASE-KR (or any other backplane link that
uses clause 73 negotiation.) Having extracted that from 802.3,
I now believe it should be treated the same as 1000BASE-X, and
the Autoneg bit in ethtool should determine whether Clause 73
negotiation is used for 10GBASE-KR (and any other Clause 73
using protocol.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists