Message-ID: <YgI7qcO1qjicYqUm@shell.armlinux.org.uk>
Date:   Tue, 8 Feb 2022 09:45:13 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Raag Jadav <raagjadav@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Steen Hegelund <steen.hegelund@...rochip.com>,
        Bjarni Jonasson <bjarni.jonasson@...rochip.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: mscc: enable MAC SerDes autonegotiation

On Mon, Feb 07, 2022 at 11:19:48PM +0530, Raag Jadav wrote:
> On Sun, Feb 06, 2022 at 07:01:41PM +0100, Andrew Lunn wrote:
> > On Sun, Feb 06, 2022 at 10:42:34PM +0530, Raag Jadav wrote:
> > > On Sat, Feb 05, 2022 at 03:57:49PM +0100, Andrew Lunn wrote:
> > > > On Sat, Feb 05, 2022 at 12:14:52PM +0530, Raag Jadav wrote:
> > > > > Enable MAC SerDes autonegotiation to distinguish between
> > > > > 1000BASE-X, SGMII and QSGMII MAC.
> > > > 
> > > > How does autoneg help you here? It just tells you about duplex, pause
> > > > etc. It does not indicate 1000BaseX, SGMII etc. The PHY should be
> > > > using whatever mode it was passed in phydev->interface, which the MAC
> > > > sets when it calls the connection function. If the PHY dynamically
> > > > changes its host side mode as a result of what that line side is
> > > > doing, it should also change phydev->interface. However, as far as i
> > > > can see, the mscc does not do this.
> > > >
> > > 
> > > Once the PHY auto-negotiates parameters such as speed and duplex mode
> > > with its link partner over the copper link as per IEEE 802.3 Clause 27,
> > > the link partner’s capabilities are then transferred by PHY to MAC
> > > over 1000BASE-X or SGMII link using the auto-negotiation functionality
> > > defined in IEEE 802.3z Clause 37.
> > 
> > None of this allows you to distinguish between 1000BASE-X, SGMII and
> > QSGMII, which is what the commit message says.
> > 
> 
> I agree, the current commit message is misleading.
> 
> > It does allow you to get duplex, pause, and maybe speed via in band
> > signalling. But you should also be getting the same information out of
> > band, via the phylib callback.
> > 
> > There are some MACs which don't seem to work correctly without the in
> > band signalling, so maybe that is your problem? Please could you give
> > more background about your problem, what MAC and PHY combination are
> > you using, what problem you are seeing, etc.
> > 
> 
> MAC implementation[1] in a lot of NXP SoCs comes with in-band aneg enabled
> by default, and it does expect Clause 37 auto-negotiation to complete
> between MAC and PHY before the actual data transfer happens.
> 
> [1] https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/t-series/3241/1/AN3869(1).pdf
> 
> I faced such issue while integrating VSC85xx PHY
> with one of the recent NXP SoC having similar MAC implementation.
> Not sure if this is a problem on MAC side or PHY side,
> But having Clause 37 support should help in most cases I believe.

Clause 37 is 1000BASE-X negotiation, which is different from SGMII - a
point which is even made in your PDF above in section 1.1.

You will need both ends to be operating in SGMII mode for 10M and 100M
to work. If one end is in 1000BASE-X mdoe and the other is in SGMII,
it can appear to work, but it won't be working correctly.

Please get the terminology correct here when talking about SGMII or
1000BASE-X.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists