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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200601212114.GT1551@shell.armlinux.org.uk>
Date:   Mon, 1 Jun 2020 22:21:14 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>, zefir.kurtisi@...atec.com
Subject: 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
> <linux@...linux.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