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]
Date: Mon, 15 May 2023 16:44:53 +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 04:34:33PM +0100, Russell King (Oracle) wrote:
> 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.

I should point out that in many of these cases, this may also be true:

--------+   +---------------------+
  SoC   |   |        PHY          |
+-----+ |   | +-----+  +--------+ |
| MAC +-------+ PCS +--+ SERDES +------------ Media
+-----+ | ^ | +-----+  +--------+ |    ^
--------+ | +---------------------+    |
          |                            |
        GMII                       1000BASE-X
        XGMII                       10GBASE-R
       XLGMII                       40GBASE-R

One would expect PHY_INTERFACE_MODE_xxx to refer to the first in this
case. If we decide that is the right model, then we shouldn't have
added PHY_INTERFACE_MODE_1000BASEX!

Then we get to the fun that is SGMII, which if we think the above is
the right model, we get GMII, a PHY that converts GMII to SGMII, and
then another PHY that converts SGMII to whatever the media wants.

In all of these cases, the interface mode on the left has no bearing
on whether the PHY block in the above (whether its separate or part
of the SoC) performs any kind of negotiation.

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