netdev - RE: Clause 73 and USXGMII

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: <BN8PR12MB32664B2DE18A30311A19E5B8D3D60@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Fri, 9 Aug 2019 18:42:39 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Jose Abreu <Jose.Abreu@...opsys.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: RE: Clause 73 and USXGMII

From: Russell King - ARM Linux admin <linux@...linux.org.uk>
Date: Aug/08/2019, 13:09:03 (UTC+00:00)

> On Thu, Aug 08, 2019 at 11:45:29AM +0000, Jose Abreu wrote:
> > From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> > Date: Aug/08/2019, 10:23:13 (UTC+00:00)
> > 
> > > On Thu, Aug 08, 2019 at 09:02:57AM +0000, Jose Abreu wrote:
> > > > From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> > > > Date: Aug/08/2019, 09:26:26 (UTC+00:00)
> > > > 
> > > > > Hi,
> > > > > 
> > > > > Have you tried enabling debug mode in phylink (add #define DEBUG at the
> > > > > top of the file) ?
> > > > 
> > > > Yes:
> > > > 
> > > > [ With > 2.5G modes removed ]
> > > > # dmesg | grep -i phy
> > > > libphy: stmmac: probed
> > > > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > > > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported 
> > > > 00,00000000,0002e040 advertising 00,00000000,0002e040
> > > > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config: 
> > > > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,0002e040 pause=10 
> > > > link=0 an=1
> > > > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
> > > 
> > > This shows that the PHY isn't reporting that the link came up.  Did
> > > the PHY negotiate link?  If so, why isn't it reporting that the link
> > > came up?  Maybe something is mis-programming the capability bits in
> > > the PHY?  Maybe disabling the 10G speeds disables everything faster
> > > than 1G?
> > 
> > Autoneg was started but never finishes and disabling 10G modes is 
> > causing autoneg to fail.
> > 
> > > 
> > > > [ Without any limit ]
> > > > # dmesg | grep -i phy
> > > > libphy: stmmac: probed
> > > > stmmaceth 0000:04:00.0 enp4s0: PHY [stmmac-1:00] driver [Synopsys 10G]
> > > > stmmaceth 0000:04:00.0 enp4s0: phy: setting supported 
> > > > 00,00000000,000ee040 advertising 00,00000000,000ee040
> > > > stmmaceth 0000:04:00.0 enp4s0: configuring for phy/usxgmii link mode
> > > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config: 
> > > > mode=phy/usxgmii/Unknown/Unknown adv=00,00000000,000ee040 pause=10 
> > > > link=0 an=1
> > > > stmmaceth 0000:04:00.0 enp4s0: phy link down usxgmii/Unknown/Unknown
> > > > stmmaceth 0000:04:00.0 enp4s0: phy link up usxgmii/2.5Gbps/Full
> > > > stmmaceth 0000:04:00.0 enp4s0: phylink_mac_config: 
> > > > mode=phy/usxgmii/2.5Gbps/Full adv=00,00000000,00000000 pause=0f link=1 
> > > > an=0
> > > > 
> > > > I'm thinking on whether this can be related with USXGMII. As link is 
> > > > operating in 10G but I configure USXGMII for 2.5G maybe autoneg outcome 
> > > > should always be 10G ?
> > > 
> > > As I understand USXGMII (which isn't very well, because the spec isn't
> > > available) I believe that it operates in a similar way to SGMII where
> > > data is replicated the appropriate number of times to achieve the link
> > > speed.  So, the USXGMII link always operates at a bit rate equivalent
> > > to 10G, but data is replicated twice for 5G, four times for 2.5G, ten
> > > times for 1G, etc.
> > > 
> > > I notice that you don't say that you support any copper speeds, which
> > > brings up the question about what the PHY's media is...
> > 
> > I just added the speeds that XPCS supports within Clause 73 
> > specification:
> > Technology Ability field. Indicates the supported technologies:
> > 	A0: When this bit is set to 1, the 1000BASE-KX technology is supported
> > 	A1: When this bit is set to 1, the 10GBASE-KX4 technology is supported
> > 	A2: When this bit is set to 1, the 10GBASE-KR technology is supported
> > 	A11: When this bit is set to 1, the 2.5GBASE-KX technology is supported
> > 	A12: When this bit is set to 1, the 5GBASE-KR technology is supported
> > 
> > And, within USXGMII, XPCS supports the following:
> > 	Single Port: 10G-SXGMII, 5G-SXGMII, 2.5G-SXGMII
> > 	Dual Port: 10G-DXGMII, 5G-DXGMII
> > 	Quad Port: 10G-XGMII
> > 
> > My HW is currently fixed for USXGMII at 2.5G.
> 
> So what do you actually have?
> 
> +-----+              +----------+
> | STM |    USXGMII   | Synopsis |   ????????
> | MAC | <----------> |   PHY    | <----------> ????
> |     |     link     |          |
> +-----+              +----------+ (media side)
> 
> Does the above refer to what the STM MAC and Synopsis PHY support for
> the USXGMII link?  What about the media side?

This is my setup:

XGMAC <-> XPCS <-> Xilinx SERDES <-> SFP

I'm not sure about the media side. I use a passive SFP cable if that 
helps ...

> 
> If you just tell phylink what the USXGMII part is capable of, there's
> no way for the media side to do anything unless it also supports the
> capabilities that the USXGMII link supports.
> 
> phylink doesn't do any kind of translation of capabilities of the
> MAC-PHY link to media capabilities; this is why the documentation for
> the validate callback has this note:
> 
>  * Note that the PHY may be able to transform from one connection
>  * technology to another, so, eg, don't clear 1000BaseX just
>  * because the MAC is unable to BaseX mode. This is more about
>  * clearing unsupported speeds and duplex settings.
> 
> To put it another way - if the link between the MAC and PHY supports
> 10G speed, the MAC should indicate that _all_ 10G ethtool link modes
> that support 10G speed are set in the supported mask.  If the link
> supports 1G speeds, then all 1G ethtool link modes that can be
> supported irrespective of technology should be set.  This is because
> the capabilities of the overall setup is the logical union of the
> capabilities of each device in the setup.
> 
> So, if, say, the USXGMII link can support 2.5Gbps, and the PHY
> supports copper media at 2.5Gbps via the NBASE-T specifications,
> then the system as a whole can support
> ETHTOOL_LINK_MODE_2500baseT_Full_BIT.  If the MAC decides to clear
> that bit, then the system can't support 2.5Gbps even if the PHY
> does.
> 
> Maybe what we need to do with phylink is move away from exposing
> ethtool link modes to the MAC validate callback, and instead
> devise a way for the MAC to indicate merely the speeds and duplexes
> it supports without any of the technology stuff getting in the way.
> 
> -- 
> RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.armlinux.org.uk_developer_patches_&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=WXDOl4mhp4Xwg4de0KTKH9RNulfBLbkA6MQGZ1G9_FI&s=DbL6asfMKlMoCCeLhWoeBLrUQ0FSIrLkJCKoVbKVEQg&e= 
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up


---
Thanks,
Jose Miguel Abreu