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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGJRCaR2gQqEt2+L@shell.armlinux.org.uk>
Date: Mon, 15 May 2023 16:34:33 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: 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, Vladimir Oltean <olteanv@...il.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 03:58:09PM +0200, Andrew Lunn wrote:
> > 2. XLGMII.. Looking at the XPCS driver, it's unclear whether Clause 73
> >    AN gets used for this. A quick scan of IEEE 802.3 suggests that
> >    XLGMII doesn't have any support for any inband signalling, and it's
> >    just an intermediary protocol between the MAC (more specifically the
> >    RS, but for the purposes of this I'll just refer to MAC) and the
> >    attached PCS, and any autonegotiation happens after the XLGMII link.
> 
> So isn't XLGMII then a generic PHY thing, not a phylink thing?

Honestly, I'm really not sure. It feels more like an internal-SoC
thing. See my last diagram why I think this.

> Or am i not correctly understanding how
> drivers/phy/marvell/phy-*-comphy.c and
> drivers/phy/microchip/*_serdev.c fit into the overall picture?

In the case of serdes-based protocols with an external PHY, the general
structure we have is:

------------------------------+
  SoC                         |
+-----+   +-----+  +--------+ |          +--------------+
| MAC +---+ PCS +--+ SERDES +------------+ Ethernet PHY +---- Media
+-----+   +-----+  +--------+ |    ^     +--------------+
------------------------------+    |
                                   |
PHY_INTERFACE_MODE_xxx has referred to this bit, and this is the bit
where inband can occur.

In the case of multi-rate implementations, there can be one of many
different PCS that can be placed there, and the SERDES handles
converting the data stream from the PCS into its appropriate
electrical form, essentially covering the PMA and PMD functions.
(That same SERDES block generally can also handle PCIe and SATA.)

In the case of non-serdes based protocols, then it's essentially the
same as the above, but with the PCS and SERDES blocks removed.

For Fibre based connections:

------------------------------+
  SoC                         |
+-----+   +-----+  +--------+ |
| MAC +---+ PCS +--+ SERDES +------------ Media
+-----+   +-----+  +--------+ |    ^
------------------------------+    |
                                   |
PHY_INTERFACE_MODE_xxx has referred to this bit, and 1000BASE-X runs
negotiation on this. 10GBASE-R also used for fibre has no negotiation,
but there's still the 10GBASE-R PCS and the 802.3 PMA/PMD are subsumed
by the SERDES block.

What I think seems to be the case with XPCS is:

------------------------------+
  SoC                         |
+-----+   +-----+  +--------+ |
| MAC +---+ PCS +--+ SERDES +----------- Media
+-----+ ^ +-----+  +--------+ |
--------|---------------------+
        |
PHY_INTERFACE_MODE_xxx seems to be referring to this bit. When clause 73
negotiation is used, that happens where I've stated "media" above, and
that's involved with negotiating backplane protocols e.g. 40GBASE-KR4,
40GBASE-CR4, 25GBASE-KR, 10GBASE-KR, 1000BASE-KX etc on the bit I've
called "Media" above.

However, we can also have this for a fibre link:

------------------------------+
  SoC                         |
+-----+   +-----+  +--------+ |
| MAC +---+ PCS +--+ SERDES +----------- Fibre
+-----+ ^ +-----+  +--------+ |    ^
--------|---------------------+    |
        |                          |
     XLGMII                    40GBASE-R

Given that in this case, we'd want PHY_INTERFACE_MODE_xxx to say
40GBASE-R, using the existing PHY_INTERFACE_MODE_xxx to specify at
where I've pointed XLGMII just makes things confused... but in the
case above with clause 73 negotiation, we wouldn't have a standard
PHY_INTERFACE_MODE_xxx specifier for the external "media" side
because that's dependent on the result of the negotiation.

So... this seems to be a right can of wriggly things.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!