netdev - Re: [PATCH RFC] Providing a helper for PCS inband negotiation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230515220833.up43pd76zne2suy2@skbuf>
Date: Tue, 16 May 2023 01:08:33 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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:45:21PM +0100, Russell King (Oracle) wrote:
> Clause 73.1:
> 
> 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.)

Having said that copper backplane link modes should be treated "the
same" as fiber link modes w.r.t. ethtool -s autoneg, it should also be
said that there are significant differences between clause 37 and 73
autoneg too.

Clause 73 negotiates the actual use of 10GBase-KR as a SERDES protocol
through the copper backplane in favor of other "Base-K*" alternative
link modes, so it's not quite proper to say that 10GBase-KR is a clause
73 using protocol.

To me, the goals of clause 73 autoneg are much more similar to those of
the twisted pair autoneg process - clause 28, which similarly selects
between different media side protocols in the PHY, using a priority
resolution function. For those, we use phylib and the phy_device
structure. What are the merits of using phylink_pcs for copper backplanes
and not phylib?