Message-ID: <ZqdzOxYJiRyft1Nh@shell.armlinux.org.uk>
Date: Mon, 29 Jul 2024 11:47:23 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Revanth Kumar Uppala <ruppala@...dia.com>,
	"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 Fri, Jul 19, 2024 at 02:27:24PM +0100, Jon Hunter wrote:
> Hi Russell,
> 
> On 24/07/2023 12:57, Russell King (Oracle) wrote:
> > 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.
> 
> 
> Apologies for not following up before on this and now that is has been a
> year I am not sure if it is even appropriate to dig this up as opposed to
> starting a new thread completely.
> 
> However, I want to resume this conversation because we have found that this
> change does resolve a long-standing issue where we occasionally see our
> ethernet controller fail to get an IP address.
> 
> I understand that your objection to the above change is that (per Revanth's
> feedback) this change assumes interface has the link. However, looking at
> the aqr107_read_status() function where this change is made the function has
> the following ...
> 
> static int aqr107_read_status(struct phy_device *phydev)
> {
>         int val, ret;
> 
>         ret = aqr_read_status(phydev);
>         if (ret)
>                 return ret;
> 
>         if (!phydev->link || phydev->autoneg == AUTONEG_DISABLE)
>                 return 0;
> 
> 
> So my understanding is that if we don't have the link, then the above test
> will return before we attempt to poll the TX ready status. If that is the
> case, then would the change being proposed be OK?

Here, phydev->link will be the _media_ side link. This is fine - if the
media link is down, there's no point doing anything further. However,
if the link is up, then we need the PHY to update phydev->interface
_and_ report that the link was up (phydev->link is true).

When that happens, the layers above (e.g. phylib, phylink, MAC driver)
then know that the _media_ side interface has come up, and they also
know the parameters that were negotiated. They also know what interface
mode the PHY is wanting to use.

At that point, the MAC driver can then reconfigure its PHY facing
interface according to what the PHY is using. Until that point, there
is a very real chance that the PHY <--> MAC connection will remain
_down_.

The patch adds up to a _two_ _second_ wait for the PHY <--> MAC
connection to come up before aqr107_read_status() will return. This
is total nonsense - because waiting here means that the MAC won't
get the notification of which interface mode the PHY is expecting
to use, therefore the MAC won't configure its PHY facing hardware
for that interface mode, and therefore the PHY <--> MAC connection
will _not_ _come_ _up_.

You can not wait for the PHY <--> MAC connection to come up in the
phylib read_status method. Ever.

This is non-negotiable because it is just totally wrong to do this
and leads to pointless two second delays.

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