* Re: QUSGMII control word
2023-06-05 6:13 ` Maxime Chevallier
@ 2023-06-05 10:45 ` Russell King (Oracle)
2023-06-05 12:25 ` Vladimir Oltean
1 sibling, 0 replies; 4+ messages in thread
From: Russell King (Oracle) @ 2023-06-05 10:45 UTC (permalink / raw)
To: Maxime Chevallier; +Cc: Andrew Lunn, netdev
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@armlinux.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.
>
> Do you have a patch or should I send a followup ?
I don't have a patch.
> Out of curiosity, on which hardware did you find this ?
No, it's something I noticed when reviewing some documentation I have.
> I still have some patches of PCH extensions around, but didn't get any
> room in my schedule to move forward with it. Is it something that you
> plan on using ?
No plans, sorry! :D
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: QUSGMII control word
2023-06-05 6:13 ` Maxime Chevallier
2023-06-05 10:45 ` Russell King (Oracle)
@ 2023-06-05 12:25 ` Vladimir Oltean
1 sibling, 0 replies; 4+ messages in thread
From: Vladimir Oltean @ 2023-06-05 12:25 UTC (permalink / raw)
To: Maxime Chevallier; +Cc: Russell King (Oracle), Andrew Lunn, netdev
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@armlinux.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...
^ permalink raw reply [flat|nested] 4+ messages in thread