Re: [PATCH stable-4.19.y] net: phy: reschedule state machine if AN has not completed in PHY_AN state

From: Vladimir Oltean <olteanv@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: stable@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	netdev <netdev@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	zefir.kurtisi@neratec.com
Subject: Re: [PATCH stable-4.19.y] net: phy: reschedule state machine if AN has not completed in PHY_AN state
Date: Tue, 2 Jun 2020 00:38:13 +0300	[thread overview]
Message-ID: <CA+h21hpXM41CJGw5BnuqBYHgdEYXXsPNVBCnt6Ng=1dCRQs-AQ@mail.gmail.com> (raw)
In-Reply-To: <20200601212114.GT1551@shell.armlinux.org.uk>

On Tue, 2 Jun 2020 at 00:21, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, Jun 01, 2020 at 11:57:30PM +0300, Vladimir Oltean wrote:
> > On Mon, 1 Jun 2020 at 03:28, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > And yes, I do have some copper SFP modules that have an (inaccessible)
> > > AR803x PHY on them - Microtik S-RJ01 to be exact.  I forget exactly
> > > which variant it is, and no, I haven't seen any of this "SGMII fails
> > > to come up" - in fact, the in-band SGMII status is the only way to
> > > know what the PHY negotiated with its link partner... and this SFP
> > > module works with phylink with no issues.
> >
> > See, you should also specify what kernel you're testing on. Since
> > Heiner did the PHY_AN cleanup, phy_aneg_done is basically dead code
> > from the state machine's perspective, only a few random drivers call
> > it:
> > https://elixir.bootlin.com/linux/latest/A/ident/phy_aneg_done
> > So I would not be at all surprised that you're not hitting it simply
> > because at803x_aneg_done is never in your call path.
>
> Please re-read the paragraph of my reply that is quoted above, and
> consider your response to it in light of the word *inaccessible* in
> my paragraph above.
>
> Specifically, ask yourself the question: "if the PHY is inaccessible,
> does it matter what kernel version is being tested?  Does it matter
> what the at803x code is doing?"
>
> The point that I was trying to get across, but you seem to have missed,
> is that this SFP module uses an AR803x PHY that is inaccessible and I
> have never seen a problem with the SGMII side coming up - and if the
> SGMII side does not come up, we have no way to know what the copper
> side is doing.  With this module, we are totally reliant on the SGMII
> side working correctly to work out what the copper side status is.
>
> *Frustrated*.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

So I ignored the "inaccessible" part because I failed to understand
the relevance of your reply given the issue at hand. I wasn't trying
to suggest that the AT803x SGMII AN logic is broken.