Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Jose Abreu <Jose.Abreu@synopsys.com>
To:     Russell King - ARM Linux admin <linux@armlinux.org.uk>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Joao Pinto <Joao.Pinto@synopsys.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next 1/4] net: phy: xpcs: Clear latched value of RX/TX
 fault
Thread-Topic: [PATCH net-next 1/4] net: phy: xpcs: Clear latched value of
 RX/TX fault
Thread-Index: AQHV+T0DV8FPfrDj6UiwCwoiz8iVCahGjUYAgAABUYA=
Date:   Fri, 13 Mar 2020 14:11:36 +0000
Message-ID: <BN8PR12MB3266F7ACE6A778CAA883F8F1D3FA0@BN8PR12MB3266.namprd12.prod.outlook.com>
References: <cover.1584106347.git.Jose.Abreu@synopsys.com>
 <50f3dd2ab58fecfea1156aaf8dbfa99d0c7b36be.1584106347.git.Jose.Abreu@synopsys.com>
 <20200313140122.GC25745@shell.armlinux.org.uk>
In-Reply-To: <20200313140122.GC25745@shell.armlinux.org.uk>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0218ae8b-a6fb-4996-2bf7-08d7c7587158
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 14:11:36.6928
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: f4nSbclHA1gax5BO0ay3MfiQ/LHjOx5R1QoNW+y7SJDwuNcTgPVPEouheGGiPsIXBveQ7D8WRhxgnCRdCO1xxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3539
X-OriginatorOrg: synopsys.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Mar/13/2020, 14:01:22 (UTC+00:00)

> On Fri, Mar 13, 2020 at 02:39:40PM +0100, Jose Abreu wrote:
> > When reading RX/TX fault register we may have latched values from Link
> > down. Clear the latched value first and then read it again to make sure
> > no old errors are flagged and that new errors are caught.
>=20
> The purpose of the latched link down is so that software can respond
> to a momentary loss of link with a possible change in the negotiation
> results.  That is why IEEE 802.3 wants a link loss to be a latched
> event.
>=20
> Double-reading the status register loses that information, and hides
> it from phylink.  A change in negotiation, which can occur very
> quickly on fiber links) can go unnoticed if the latching is not
> propagated up through phylink.
>=20
> If the negotiation parameters have changed, and pcs_get_state() does
> not report that the link has failed, then mac_link_up() will _not_ be
> called with the new link parameters, and the MAC will continue using
> the old ones.  Therefore, it is very important that any link-down
> event is reported to phylink.
>=20
> Phylink currently doesn't respond to a link-down event reported via
> PCS by re-checking after processing the link loss, but it could do,
> which would improve it's behaviour in that scenario.  I would prefer
> this resolution, rather than your proposed double-reading of the
> status register to "lose" the link-down event.
>=20
> I do have some patches that make that easier, but they're delayed
> behind the mass of patches that I still have outstanding - and trying
> to get progress on getting phylink patches merged has been glacial,
> and fraught with problems this time around.

This is not link status register. Its TX / RX fault and its latched high.=20
Link status is another register and we only read it once because of the=20
above reasons you mentioned.

When in 10GKR, this seems to always go up after link transition, hence we=20
added the double read.

I just read your reply to patch 2/4 of this series and it looks like the=20
two patches are correlated.

---
Thanks,
Jose Miguel Abreu