netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Clause 73 and USXGMII
@ 2019-08-07 15:46 Jose Abreu
  2019-08-08  8:17 ` Jose Abreu
  0 siblings, 1 reply; 9+ messages in thread
From: Jose Abreu @ 2019-08-07 15:46 UTC (permalink / raw)
  To: netdev@vger.kernel.org

Hello,

I've some sample code for Clause 73 support using Synopsys based XPCS 
but I would like to clarify some things that I noticed.

I'm using USXGMII as interface and a single SERDES that operates at 10G 
rate but MAC side is working at 2.5G. Maximum available bandwidth is 
therefore 2.5Gbps.

So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
the autoneg abilities to 2.5G max then it never finishes:
# ethtool enp4s0
Settings for enp4s0:
	Supported ports: [ ]
	Supported link modes:   1000baseKX/Full 
	                        2500baseX/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseKX/Full 
	                        2500baseX/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: ug
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: no

When I do not limit autoneg and I say that maximum limit is 10G then I 
get Link Up and autoneg finishes with this outcome:
# ethtool enp4s0
Settings for enp4s0:
	Supported ports: [ ]
	Supported link modes:   1000baseKX/Full 
	                        2500baseX/Full 
	                        10000baseKX4/Full 
	                        10000baseKR/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseKX/Full 
	                        2500baseX/Full 
	                        10000baseKX4/Full 
	                        10000baseKR/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  1000baseKX/Full 
	                                     2500baseX/Full 
	                                     10000baseKX4/Full 
	                                     10000baseKR/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 2500Mb/s
	Duplex: Full
	Port: MII <- Never mind this, it's a SW issue
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: ug
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes

I was expecting that, as MAC side is limited to 2.5G, I should set in 
phylink the correct capabilities and then outcome of autoneg would only 
have up to 2.5G modes. Am I wrong ?

---
Thanks,
Jose Miguel Abreu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Clause 73 and USXGMII
  2019-08-07 15:46 Clause 73 and USXGMII Jose Abreu
@ 2019-08-08  8:17 ` Jose Abreu
  2019-08-08  8:26   ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 9+ messages in thread
From: Jose Abreu @ 2019-08-08  8:17 UTC (permalink / raw)
  To: netdev@vger.kernel.org
  Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, Russell King

++ PHY Experts

From: Jose Abreu <joabreu@synopsys.com>
Date: Aug/07/2019, 16:46:23 (UTC+00:00)

> Hello,
> 
> I've some sample code for Clause 73 support using Synopsys based XPCS 
> but I would like to clarify some things that I noticed.
> 
> I'm using USXGMII as interface and a single SERDES that operates at 10G 
> rate but MAC side is working at 2.5G. Maximum available bandwidth is 
> therefore 2.5Gbps.
> 
> So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
> the autoneg abilities to 2.5G max then it never finishes:
> # ethtool enp4s0
> Settings for enp4s0:
> 	Supported ports: [ ]
> 	Supported link modes:   1000baseKX/Full 
> 	                        2500baseX/Full 
> 	Supported pause frame use: Symmetric Receive-only
> 	Supports auto-negotiation: Yes
> 	Supported FEC modes: Not reported
> 	Advertised link modes:  1000baseKX/Full 
> 	                        2500baseX/Full 
> 	Advertised pause frame use: Symmetric Receive-only
> 	Advertised auto-negotiation: Yes
> 	Advertised FEC modes: Not reported
> 	Speed: Unknown!
> 	Duplex: Unknown! (255)
> 	Port: MII
> 	PHYAD: 0
> 	Transceiver: internal
> 	Auto-negotiation: on
> 	Supports Wake-on: ug
> 	Wake-on: d
> 	Current message level: 0x0000003f (63)
> 			       drv probe link timer ifdown ifup
> 	Link detected: no
> 
> When I do not limit autoneg and I say that maximum limit is 10G then I 
> get Link Up and autoneg finishes with this outcome:
> # ethtool enp4s0
> Settings for enp4s0:
> 	Supported ports: [ ]
> 	Supported link modes:   1000baseKX/Full 
> 	                        2500baseX/Full 
> 	                        10000baseKX4/Full 
> 	                        10000baseKR/Full 
> 	Supported pause frame use: Symmetric Receive-only
> 	Supports auto-negotiation: Yes
> 	Supported FEC modes: Not reported
> 	Advertised link modes:  1000baseKX/Full 
> 	                        2500baseX/Full 
> 	                        10000baseKX4/Full 
> 	                        10000baseKR/Full 
> 	Advertised pause frame use: Symmetric Receive-only
> 	Advertised auto-negotiation: Yes
> 	Advertised FEC modes: Not reported
> 	Link partner advertised link modes:  1000baseKX/Full 
> 	                                     2500baseX/Full 
> 	                                     10000baseKX4/Full 
> 	                                     10000baseKR/Full 
> 	Link partner advertised pause frame use: Symmetric Receive-only
> 	Link partner advertised auto-negotiation: Yes
> 	Link partner advertised FEC modes: Not reported
> 	Speed: 2500Mb/s
> 	Duplex: Full
> 	Port: MII <- Never mind this, it's a SW issue
> 	PHYAD: 0
> 	Transceiver: internal
> 	Auto-negotiation: on
> 	Supports Wake-on: ug
> 	Wake-on: d
> 	Current message level: 0x0000003f (63)
> 			       drv probe link timer ifdown ifup
> 	Link detected: yes
> 
> I was expecting that, as MAC side is limited to 2.5G, I should set in 
> phylink the correct capabilities and then outcome of autoneg would only 
> have up to 2.5G modes. Am I wrong ?
> 
> ---
> Thanks,
> Jose Miguel Abreu


---
Thanks,
Jose Miguel Abreu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Clause 73 and USXGMII
  2019-08-08  8:17 ` Jose Abreu
@ 2019-08-08  8:26   ` Russell King - ARM Linux admin
  2019-08-08  9:02     ` Jose Abreu
  0 siblings, 1 reply; 9+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-08  8:26 UTC (permalink / raw)
  To: Jose Abreu
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

Hi,

Have you tried enabling debug mode in phylink (add #define DEBUG at the
top of the file) ?

Thanks.

On Thu, Aug 08, 2019 at 08:17:29AM +0000, Jose Abreu wrote:
> ++ PHY Experts
> 
> From: Jose Abreu <joabreu@synopsys.com>
> Date: Aug/07/2019, 16:46:23 (UTC+00:00)
> 
> > Hello,
> > 
> > I've some sample code for Clause 73 support using Synopsys based XPCS 
> > but I would like to clarify some things that I noticed.
> > 
> > I'm using USXGMII as interface and a single SERDES that operates at 10G 
> > rate but MAC side is working at 2.5G. Maximum available bandwidth is 
> > therefore 2.5Gbps.
> > 
> > So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
> > the autoneg abilities to 2.5G max then it never finishes:
> > # ethtool enp4s0
> > Settings for enp4s0:
> > 	Supported ports: [ ]
> > 	Supported link modes:   1000baseKX/Full 
> > 	                        2500baseX/Full 
> > 	Supported pause frame use: Symmetric Receive-only
> > 	Supports auto-negotiation: Yes
> > 	Supported FEC modes: Not reported
> > 	Advertised link modes:  1000baseKX/Full 
> > 	                        2500baseX/Full 
> > 	Advertised pause frame use: Symmetric Receive-only
> > 	Advertised auto-negotiation: Yes
> > 	Advertised FEC modes: Not reported
> > 	Speed: Unknown!
> > 	Duplex: Unknown! (255)
> > 	Port: MII
> > 	PHYAD: 0
> > 	Transceiver: internal
> > 	Auto-negotiation: on
> > 	Supports Wake-on: ug
> > 	Wake-on: d
> > 	Current message level: 0x0000003f (63)
> > 			       drv probe link timer ifdown ifup
> > 	Link detected: no
> > 
> > When I do not limit autoneg and I say that maximum limit is 10G then I 
> > get Link Up and autoneg finishes with this outcome:
> > # ethtool enp4s0
> > Settings for enp4s0:
> > 	Supported ports: [ ]
> > 	Supported link modes:   1000baseKX/Full 
> > 	                        2500baseX/Full 
> > 	                        10000baseKX4/Full 
> > 	                        10000baseKR/Full 
> > 	Supported pause frame use: Symmetric Receive-only
> > 	Supports auto-negotiation: Yes
> > 	Supported FEC modes: Not reported
> > 	Advertised link modes:  1000baseKX/Full 
> > 	                        2500baseX/Full 
> > 	                        10000baseKX4/Full 
> > 	                        10000baseKR/Full 
> > 	Advertised pause frame use: Symmetric Receive-only
> > 	Advertised auto-negotiation: Yes
> > 	Advertised FEC modes: Not reported
> > 	Link partner advertised link modes:  1000baseKX/Full 
> > 	                                     2500baseX/Full 
> > 	                                     10000baseKX4/Full 
> > 	                                     10000baseKR/Full 
> > 	Link partner advertised pause frame use: Symmetric Receive-only
> > 	Link partner advertised auto-negotiation: Yes
> > 	Link partner advertised FEC modes: Not reported
> > 	Speed: 2500Mb/s
> > 	Duplex: Full
> > 	Port: MII <- Never mind this, it's a SW issue
> > 	PHYAD: 0
> > 	Transceiver: internal
> > 	Auto-negotiation: on
> > 	Supports Wake-on: ug
> > 	Wake-on: d
> > 	Current message level: 0x0000003f (63)
> > 			       drv probe link timer ifdown ifup
> > 	Link detected: yes
> > 
> > I was expecting that, as MAC side is limited to 2.5G, I should set in 
> > phylink the correct capabilities and then outcome of autoneg would only 
> > have up to 2.5G modes. Am I wrong ?
> > 
> > ---
> > Thanks,
> > Jose Miguel Abreu
> 
> 
> ---
> Thanks,
> Jose Miguel Abreu
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Clause 73 and USXGMII
  2019-08-08  8:26   ` Russell King - ARM Linux admin
@ 2019-08-08  9:02     ` Jose Abreu
  2019-08-08  9:23       ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 9+ messages in thread
From: Jose Abreu @ 2019-08-08  9:02 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

From: Russell King - ARM Linux admin <linux@armlinux.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

[ 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 ?

> On Thu, Aug 08, 2019 at 08:17:29AM +0000, Jose Abreu wrote:
> > ++ PHY Experts
> > 
> > From: Jose Abreu <joabreu@synopsys.com>
> > Date: Aug/07/2019, 16:46:23 (UTC+00:00)
> > 
> > > Hello,
> > > 
> > > I've some sample code for Clause 73 support using Synopsys based XPCS 
> > > but I would like to clarify some things that I noticed.
> > > 
> > > I'm using USXGMII as interface and a single SERDES that operates at 10G 
> > > rate but MAC side is working at 2.5G. Maximum available bandwidth is 
> > > therefore 2.5Gbps.
> > > 
> > > So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
> > > the autoneg abilities to 2.5G max then it never finishes:
> > > # ethtool enp4s0
> > > Settings for enp4s0:
> > > 	Supported ports: [ ]
> > > 	Supported link modes:   1000baseKX/Full 
> > > 	                        2500baseX/Full 
> > > 	Supported pause frame use: Symmetric Receive-only
> > > 	Supports auto-negotiation: Yes
> > > 	Supported FEC modes: Not reported
> > > 	Advertised link modes:  1000baseKX/Full 
> > > 	                        2500baseX/Full 
> > > 	Advertised pause frame use: Symmetric Receive-only
> > > 	Advertised auto-negotiation: Yes
> > > 	Advertised FEC modes: Not reported
> > > 	Speed: Unknown!
> > > 	Duplex: Unknown! (255)
> > > 	Port: MII
> > > 	PHYAD: 0
> > > 	Transceiver: internal
> > > 	Auto-negotiation: on
> > > 	Supports Wake-on: ug
> > > 	Wake-on: d
> > > 	Current message level: 0x0000003f (63)
> > > 			       drv probe link timer ifdown ifup
> > > 	Link detected: no
> > > 
> > > When I do not limit autoneg and I say that maximum limit is 10G then I 
> > > get Link Up and autoneg finishes with this outcome:
> > > # ethtool enp4s0
> > > Settings for enp4s0:
> > > 	Supported ports: [ ]
> > > 	Supported link modes:   1000baseKX/Full 
> > > 	                        2500baseX/Full 
> > > 	                        10000baseKX4/Full 
> > > 	                        10000baseKR/Full 
> > > 	Supported pause frame use: Symmetric Receive-only
> > > 	Supports auto-negotiation: Yes
> > > 	Supported FEC modes: Not reported
> > > 	Advertised link modes:  1000baseKX/Full 
> > > 	                        2500baseX/Full 
> > > 	                        10000baseKX4/Full 
> > > 	                        10000baseKR/Full 
> > > 	Advertised pause frame use: Symmetric Receive-only
> > > 	Advertised auto-negotiation: Yes
> > > 	Advertised FEC modes: Not reported
> > > 	Link partner advertised link modes:  1000baseKX/Full 
> > > 	                                     2500baseX/Full 
> > > 	                                     10000baseKX4/Full 
> > > 	                                     10000baseKR/Full 
> > > 	Link partner advertised pause frame use: Symmetric Receive-only
> > > 	Link partner advertised auto-negotiation: Yes
> > > 	Link partner advertised FEC modes: Not reported
> > > 	Speed: 2500Mb/s
> > > 	Duplex: Full
> > > 	Port: MII <- Never mind this, it's a SW issue
> > > 	PHYAD: 0
> > > 	Transceiver: internal
> > > 	Auto-negotiation: on
> > > 	Supports Wake-on: ug
> > > 	Wake-on: d
> > > 	Current message level: 0x0000003f (63)
> > > 			       drv probe link timer ifdown ifup
> > > 	Link detected: yes
> > > 
> > > I was expecting that, as MAC side is limited to 2.5G, I should set in 
> > > phylink the correct capabilities and then outcome of autoneg would only 
> > > have up to 2.5G modes. Am I wrong ?
> > > 
> > > ---
> > > Thanks,
> > > Jose Miguel Abreu
> > 
> > 
> > ---
> > Thanks,
> > Jose Miguel Abreu
> > 
> 
> -- 
> 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=1MdSlPrmzsMMCJbbLcDYTNuPq1njfusBRjcRz3UD4Dg&s=_30hwSYkGf9DfyCG48mnh7lXP8iiULXpfAP_6agUJno&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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Clause 73 and USXGMII
  2019-08-08  9:02     ` Jose Abreu
@ 2019-08-08  9:23       ` Russell King - ARM Linux admin
  2019-08-08 11:45         ` Jose Abreu
  0 siblings, 1 reply; 9+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-08  9:23 UTC (permalink / raw)
  To: Jose Abreu
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

On Thu, Aug 08, 2019 at 09:02:57AM +0000, Jose Abreu wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.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?

> [ 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...

> > On Thu, Aug 08, 2019 at 08:17:29AM +0000, Jose Abreu wrote:
> > > ++ PHY Experts
> > > 
> > > From: Jose Abreu <joabreu@synopsys.com>
> > > Date: Aug/07/2019, 16:46:23 (UTC+00:00)
> > > 
> > > > Hello,
> > > > 
> > > > I've some sample code for Clause 73 support using Synopsys based XPCS 
> > > > but I would like to clarify some things that I noticed.
> > > > 
> > > > I'm using USXGMII as interface and a single SERDES that operates at 10G 
> > > > rate but MAC side is working at 2.5G. Maximum available bandwidth is 
> > > > therefore 2.5Gbps.
> > > > 
> > > > So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
> > > > the autoneg abilities to 2.5G max then it never finishes:
> > > > # ethtool enp4s0
> > > > Settings for enp4s0:
> > > > 	Supported ports: [ ]
> > > > 	Supported link modes:   1000baseKX/Full 
> > > > 	                        2500baseX/Full 
> > > > 	Supported pause frame use: Symmetric Receive-only
> > > > 	Supports auto-negotiation: Yes
> > > > 	Supported FEC modes: Not reported
> > > > 	Advertised link modes:  1000baseKX/Full 
> > > > 	                        2500baseX/Full 
> > > > 	Advertised pause frame use: Symmetric Receive-only
> > > > 	Advertised auto-negotiation: Yes
> > > > 	Advertised FEC modes: Not reported
> > > > 	Speed: Unknown!
> > > > 	Duplex: Unknown! (255)
> > > > 	Port: MII
> > > > 	PHYAD: 0
> > > > 	Transceiver: internal
> > > > 	Auto-negotiation: on
> > > > 	Supports Wake-on: ug
> > > > 	Wake-on: d
> > > > 	Current message level: 0x0000003f (63)
> > > > 			       drv probe link timer ifdown ifup
> > > > 	Link detected: no
> > > > 
> > > > When I do not limit autoneg and I say that maximum limit is 10G then I 
> > > > get Link Up and autoneg finishes with this outcome:
> > > > # ethtool enp4s0
> > > > Settings for enp4s0:
> > > > 	Supported ports: [ ]
> > > > 	Supported link modes:   1000baseKX/Full 
> > > > 	                        2500baseX/Full 
> > > > 	                        10000baseKX4/Full 
> > > > 	                        10000baseKR/Full 
> > > > 	Supported pause frame use: Symmetric Receive-only
> > > > 	Supports auto-negotiation: Yes
> > > > 	Supported FEC modes: Not reported
> > > > 	Advertised link modes:  1000baseKX/Full 
> > > > 	                        2500baseX/Full 
> > > > 	                        10000baseKX4/Full 
> > > > 	                        10000baseKR/Full 
> > > > 	Advertised pause frame use: Symmetric Receive-only
> > > > 	Advertised auto-negotiation: Yes
> > > > 	Advertised FEC modes: Not reported
> > > > 	Link partner advertised link modes:  1000baseKX/Full 
> > > > 	                                     2500baseX/Full 
> > > > 	                                     10000baseKX4/Full 
> > > > 	                                     10000baseKR/Full 
> > > > 	Link partner advertised pause frame use: Symmetric Receive-only
> > > > 	Link partner advertised auto-negotiation: Yes
> > > > 	Link partner advertised FEC modes: Not reported
> > > > 	Speed: 2500Mb/s
> > > > 	Duplex: Full
> > > > 	Port: MII <- Never mind this, it's a SW issue
> > > > 	PHYAD: 0
> > > > 	Transceiver: internal
> > > > 	Auto-negotiation: on
> > > > 	Supports Wake-on: ug
> > > > 	Wake-on: d
> > > > 	Current message level: 0x0000003f (63)
> > > > 			       drv probe link timer ifdown ifup
> > > > 	Link detected: yes
> > > > 
> > > > I was expecting that, as MAC side is limited to 2.5G, I should set in 
> > > > phylink the correct capabilities and then outcome of autoneg would only 
> > > > have up to 2.5G modes. Am I wrong ?
> > > > 
> > > > ---
> > > > Thanks,
> > > > Jose Miguel Abreu
> > > 
> > > 
> > > ---
> > > Thanks,
> > > Jose Miguel Abreu
> > > 
> > 
> > -- 
> > 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=1MdSlPrmzsMMCJbbLcDYTNuPq1njfusBRjcRz3UD4Dg&s=_30hwSYkGf9DfyCG48mnh7lXP8iiULXpfAP_6agUJno&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
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Clause 73 and USXGMII
  2019-08-08  9:23       ` Russell King - ARM Linux admin
@ 2019-08-08 11:45         ` Jose Abreu
  2019-08-08 12:09           ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 9+ messages in thread
From: Jose Abreu @ 2019-08-08 11:45 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

From: Russell King - ARM Linux admin <linux@armlinux.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@armlinux.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.

> 
> > > On Thu, Aug 08, 2019 at 08:17:29AM +0000, Jose Abreu wrote:
> > > > ++ PHY Experts
> > > > 
> > > > From: Jose Abreu <joabreu@synopsys.com>
> > > > Date: Aug/07/2019, 16:46:23 (UTC+00:00)
> > > > 
> > > > > Hello,
> > > > > 
> > > > > I've some sample code for Clause 73 support using Synopsys based XPCS 
> > > > > but I would like to clarify some things that I noticed.
> > > > > 
> > > > > I'm using USXGMII as interface and a single SERDES that operates at 10G 
> > > > > rate but MAC side is working at 2.5G. Maximum available bandwidth is 
> > > > > therefore 2.5Gbps.
> > > > > 
> > > > > So, I configure USXGMII for 2.5G mode and it works but if I try to limit 
> > > > > the autoneg abilities to 2.5G max then it never finishes:
> > > > > # ethtool enp4s0
> > > > > Settings for enp4s0:
> > > > > 	Supported ports: [ ]
> > > > > 	Supported link modes:   1000baseKX/Full 
> > > > > 	                        2500baseX/Full 
> > > > > 	Supported pause frame use: Symmetric Receive-only
> > > > > 	Supports auto-negotiation: Yes
> > > > > 	Supported FEC modes: Not reported
> > > > > 	Advertised link modes:  1000baseKX/Full 
> > > > > 	                        2500baseX/Full 
> > > > > 	Advertised pause frame use: Symmetric Receive-only
> > > > > 	Advertised auto-negotiation: Yes
> > > > > 	Advertised FEC modes: Not reported
> > > > > 	Speed: Unknown!
> > > > > 	Duplex: Unknown! (255)
> > > > > 	Port: MII
> > > > > 	PHYAD: 0
> > > > > 	Transceiver: internal
> > > > > 	Auto-negotiation: on
> > > > > 	Supports Wake-on: ug
> > > > > 	Wake-on: d
> > > > > 	Current message level: 0x0000003f (63)
> > > > > 			       drv probe link timer ifdown ifup
> > > > > 	Link detected: no
> > > > > 
> > > > > When I do not limit autoneg and I say that maximum limit is 10G then I 
> > > > > get Link Up and autoneg finishes with this outcome:
> > > > > # ethtool enp4s0
> > > > > Settings for enp4s0:
> > > > > 	Supported ports: [ ]
> > > > > 	Supported link modes:   1000baseKX/Full 
> > > > > 	                        2500baseX/Full 
> > > > > 	                        10000baseKX4/Full 
> > > > > 	                        10000baseKR/Full 
> > > > > 	Supported pause frame use: Symmetric Receive-only
> > > > > 	Supports auto-negotiation: Yes
> > > > > 	Supported FEC modes: Not reported
> > > > > 	Advertised link modes:  1000baseKX/Full 
> > > > > 	                        2500baseX/Full 
> > > > > 	                        10000baseKX4/Full 
> > > > > 	                        10000baseKR/Full 
> > > > > 	Advertised pause frame use: Symmetric Receive-only
> > > > > 	Advertised auto-negotiation: Yes
> > > > > 	Advertised FEC modes: Not reported
> > > > > 	Link partner advertised link modes:  1000baseKX/Full 
> > > > > 	                                     2500baseX/Full 
> > > > > 	                                     10000baseKX4/Full 
> > > > > 	                                     10000baseKR/Full 
> > > > > 	Link partner advertised pause frame use: Symmetric Receive-only
> > > > > 	Link partner advertised auto-negotiation: Yes
> > > > > 	Link partner advertised FEC modes: Not reported
> > > > > 	Speed: 2500Mb/s
> > > > > 	Duplex: Full
> > > > > 	Port: MII <- Never mind this, it's a SW issue
> > > > > 	PHYAD: 0
> > > > > 	Transceiver: internal
> > > > > 	Auto-negotiation: on
> > > > > 	Supports Wake-on: ug
> > > > > 	Wake-on: d
> > > > > 	Current message level: 0x0000003f (63)
> > > > > 			       drv probe link timer ifdown ifup
> > > > > 	Link detected: yes
> > > > > 
> > > > > I was expecting that, as MAC side is limited to 2.5G, I should set in 
> > > > > phylink the correct capabilities and then outcome of autoneg would only 
> > > > > have up to 2.5G modes. Am I wrong ?
> > > > > 
> > > > > ---
> > > > > Thanks,
> > > > > Jose Miguel Abreu
> > > > 
> > > > 
> > > > ---
> > > > Thanks,
> > > > Jose Miguel Abreu
> > > > 
> > > 
> > > -- 
> > > 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=1MdSlPrmzsMMCJbbLcDYTNuPq1njfusBRjcRz3UD4Dg&s=_30hwSYkGf9DfyCG48mnh7lXP8iiULXpfAP_6agUJno&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
> > 
> 
> -- 
> 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=d_Og5QaTJOl1WoLi43ZAlCMajHnZp4mGg8Npwlaa2pk&s=bs6ws6HmZNKiutYWGFPy1ztnEQBuhtWyjiE0Hr1_URo&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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Clause 73 and USXGMII
  2019-08-08 11:45         ` Jose Abreu
@ 2019-08-08 12:09           ` Russell King - ARM Linux admin
  2019-08-09 18:42             ` Jose Abreu
  0 siblings, 1 reply; 9+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-08 12:09 UTC (permalink / raw)
  To: Jose Abreu
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

On Thu, Aug 08, 2019 at 11:45:29AM +0000, Jose Abreu wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.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@armlinux.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?

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://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Clause 73 and USXGMII
  2019-08-08 12:09           ` Russell King - ARM Linux admin
@ 2019-08-09 18:42             ` Jose Abreu
  2019-08-09 19:25               ` Russell King - ARM Linux admin
  0 siblings, 1 reply; 9+ messages in thread
From: Jose Abreu @ 2019-08-09 18:42 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Jose Abreu
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

From: Russell King - ARM Linux admin <linux@armlinux.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@armlinux.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@armlinux.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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Clause 73 and USXGMII
  2019-08-09 18:42             ` Jose Abreu
@ 2019-08-09 19:25               ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 9+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-09 19:25 UTC (permalink / raw)
  To: Jose Abreu
  Cc: netdev@vger.kernel.org, Andrew Lunn, Florian Fainelli,
	Heiner Kallweit

On Fri, Aug 09, 2019 at 06:42:39PM +0000, Jose Abreu wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.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@armlinux.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@armlinux.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 ...

And at the other end of the passive SFP cable?  I guess some kind of
standard networking device.

If the SFP is running at 10G, the protocol to the SFP is expected to be
10GBASE-R - which is fixed at 10G speed.  Unless the Xilinx serdes
(which you previously stated was a PHY) is capable of speed conversion
between 2.5G to the XPCS over USXGMII and 10G to the SFP, then I don't
see how you can expect this setup to work - at least not in a standard
environment.

In any case, I don't think it is phylink causing your problems. Without
knowing more about the "phy", what the Xilinx serdes is capable of, and
how that is being programmed, I don't see how I can provide further
help.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-08-09 19:25 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-07 15:46 Clause 73 and USXGMII Jose Abreu
2019-08-08  8:17 ` Jose Abreu
2019-08-08  8:26   ` Russell King - ARM Linux admin
2019-08-08  9:02     ` Jose Abreu
2019-08-08  9:23       ` Russell King - ARM Linux admin
2019-08-08 11:45         ` Jose Abreu
2019-08-08 12:09           ` Russell King - ARM Linux admin
2019-08-09 18:42             ` Jose Abreu
2019-08-09 19:25               ` Russell King - ARM Linux admin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).