From: Russell King - ARM Linux admin <linux@armlinux•org.uk>
To: Jose Abreu <Jose.Abreu@synopsys•com>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
Andrew Lunn <andrew@lunn•ch>,
Florian Fainelli <f.fainelli@gmail•com>,
Heiner Kallweit <hkallweit1@gmail•com>
Subject: Re: Clause 73 and USXGMII
Date: Fri, 9 Aug 2019 20:25:16 +0100 [thread overview]
Message-ID: <20190809192515.GB13294@shell.armlinux.org.uk> (raw)
In-Reply-To: <BN8PR12MB32664B2DE18A30311A19E5B8D3D60@BN8PR12MB3266.namprd12.prod.outlook.com>
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
prev parent reply other threads:[~2019-08-09 19:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190809192515.GB13294@shell.armlinux.org.uk \
--to=linux@armlinux$(echo .)org.uk \
--cc=Jose.Abreu@synopsys$(echo .)com \
--cc=andrew@lunn$(echo .)ch \
--cc=f.fainelli@gmail$(echo .)com \
--cc=hkallweit1@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox