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

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
[off-list ref] wrote:

quoted

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