[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZL5nQxCyj8x+5lWk@shell.armlinux.org.uk>
Date: Mon, 24 Jul 2023 12:57:55 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Revanth Kumar Uppala <ruppala@...dia.com>
Cc: "andrew@...n.ch" <andrew@...n.ch>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH 3/4] net: phy: aquantia: Poll for TX ready at PHY system
side
On Mon, Jul 24, 2023 at 11:29:33AM +0000, Revanth Kumar Uppala wrote:
> > -----Original Message-----
> > From: Russell King <linux@...linux.org.uk>
> > Sent: Wednesday, June 28, 2023 7:04 PM
> > To: Revanth Kumar Uppala <ruppala@...dia.com>
> > Cc: andrew@...n.ch; hkallweit1@...il.com; netdev@...r.kernel.org; linux-
> > tegra@...r.kernel.org
> > Subject: Re: [PATCH 3/4] net: phy: aquantia: Poll for TX ready at PHY system side
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Jun 28, 2023 at 06:13:25PM +0530, Revanth Kumar Uppala wrote:
> > > + /* Lane bring-up failures are seen during interface up, as interface
> > > + * speed settings are configured while the PHY is still initializing.
> > > + * To resolve this, poll until PHY system side interface gets ready
> > > + * and the interface speed settings are configured.
> > > + */
> > > + ret = phy_read_mmd_poll_timeout(phydev, MDIO_MMD_PHYXS,
> > MDIO_PHYXS_VEND_IF_STATUS,
> > > + val, (val & MDIO_PHYXS_VEND_IF_STATUS_TX_READY),
> > > + 20000, 2000000, false);
> >
> > What does this actually mean when the condition succeeds? Does it mean that
> > the system interface is now fully configured (but may or may not have link)?
> Yes, your understanding is correct.
> It means that the system interface is now fully configured and has the link.
As you indicate that it also indicates that the system interface has
link, then you leave me no option but to NAK this patch, sorry. The
reason is:
> > ... If it doesn't succeed because the system
> > interface doesn't have link, then that would be very bad, because _this_ function
> > needs to return so the MAC side can then be configured to gain link with the PHY
> > with the appropriate link parameters.
Essentially, if the PHY changes its host interface because the media
side has changed, we *need* the read_status() function to succeed, tell
us that the link is up, and what the parameters are for the media side
link _and_ the host side interface.
At this point, if the PHY has changed its host-side interface, then the
link with the host MAC will be _down_ because the MAC driver is not yet
aware of the new parameters for the link. read_status() has to succeed
and report the new parameters to the MAC so that the MAC (or phylink)
can reconfigure the MAC and PCS for the PHY's new operating mode.
Sorry, but NAK.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists