netdev - Re: QUSGMII control word

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] [day] [month] [year] [list]

Date: Mon, 5 Jun 2023 15:25:23 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: QUSGMII control word

On Mon, Jun 05, 2023 at 08:13:34AM +0200, Maxime Chevallier wrote:
> Hello Russell,
> 
> On Fri, 2 Jun 2023 13:18:03 +0100
> "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> 
> > Hi Maxime,
> > 
> > Looking at your commit which introduced QUSGMII -
> > 5e61fe157a27 ("net: phy: Introduce QUSGMII PHY mode"), are you sure
> > your decoding of the control word is correct?
> > 
> > I've found some information online which suggests that QUSGMII uses a
> > slightly different format to the control word from SGMII. Most of the
> > bits are the same, but the speed bits occupy the three bits from 11:9,
> > and 10M, 100M and 1G are encoded using bits 10:9, whereas in SGMII
> > they are bits 11:10. In other words, in QUSGMII they are shifted one
> > bit down. In your commit, you used the SGMII decoder for QUSGMII,
> > which would mean we'd be picking out the wrong bits for decoding the
> > speed.
> > 
> > QUSGMII also introduces EEE information into bits 8 and 7 whereas
> > these are reserved in SGMII.
> > 
> > Please could you take a look, because I think we need a different
> > decoder for the QUSGMII speed bits.
> 
> I've taken a look at it, back when I sent that patch I didn't have
> access to the full documentation and used a vendor reference
> implementation as a basis... I managed to get my hands on the proper
> doc and the control word being used looks to be the usxgmii control
> word, which matches with the offset you are seeing.

Just to be on the same page with everyone regarding what Q-USGMII is.

Commit 5e61fe157a27 ("net: phy: Introduce QUSGMII PHY mode") says that
phy-mode "qusgmii" is a derivative of phy-mode "usxgmii". I don't think
that wording was particularly helpful.

I've downloaded the 3 specifications at
https://developer.cisco.com/site/usgmii-usxgmii/, and it says that
4-port Q-USGMII is capable of speeds 10/100/1000 over each port, with
a maximum SERDES speed of 10 Gbps, and with the 8b/10b coding. But
phylink_interface_max_speed() lists PHY_INTERFACE_MODE_QUSGMII as
supporting 10G per port, which is also incorrect in addition to what
Russell already noticed about the in-band autoneg code word.

The autoneg message is indeed structurally similar to the autoneg
message from USXGMII, save for the fact that speed encodings (bits 11:9)
higher than 1G are reserved. Also (big difference), USXGMII uses the
64b/66b coding scheme rather than the 8b/10b of USGMII / Q-USGMII.

I hope there is no confusion between Q-USGMII and the quad-port variant
of USXGMII: 10G-QXGMII! The latter also uses a SERDES speed of 10.3125
Gbps, but individual port speeds are 10/100/1000/2500, and the coding
scheme is 64b/66b. 10G-QXGMII is what I would think of as the quad-port
derivative of USXGMII...