[PATCH v2 net 0/1] net: fec: Fix temporary RMII clock reset on link up

[PATCH v2 net 0/1] net: fec: Fix temporary RMII clock reset on link up

[Laurent Badel]

v2: fixed a compilation warning 

The FEC drivers performs a "hardware reset" of the MAC module when the
link is reported to be up. This causes a short glitch in the RMII clock 
due to the hardware reset clearing the receive control register which 
controls the MII mode. It seems that some link partners do not tolerate 
this glitch, and invalidate the link, which leads to a never-ending loop
of negotiation-link up-link down events. 

This was observed with the iMX28 Soc and LAN8720/LAN8742 PHYs, with two 
Intel adapters I218-LM and X722-DA2 as link partners, though a number of
other link partners do not seem to mind the clock glitch. Changing the 
hardware reset to a software reset (clearing bit 1 of the ECR register) 
cured the issue.

Attempts to optimize fec_restart() in order to minimize the duration of 
the glitch were unsuccessful. Furthermore manually producing the glitch by
setting MII mode and then back to RMII in two consecutive instructions, 
resulting in a clock glitch <10us in duration, was enough to cause the 
partner to invalidate the link. This strongly suggests that the root cause
of the link being dropped is indeed the change in clock frequency.

In an effort to minimize changes to driver, the patch proposes to use 
soft reset only for tested SoCs (iMX28) and only if the link is up. This 
preserves hardware reset in other situations, which might be required for
proper setup of the MAC.


Laurent Badel (1):
  net: fec: Fix temporary RMII clock reset on link up

 drivers/net/ethernet/freescale/fec.h      | 5 +++++
 drivers/net/ethernet/freescale/fec_main.c | 6 ++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

-- 
2.17.1



-----------------------------
Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la Longeraie 7, 1110, Morges, Switzerland 

-----------------------------

[PATCH v2 net 1/1] net: fec: Fix temporary RMII clock reset on link up

[Laurent Badel]

fec_restart() does a hard reset of the MAC module when the link status
changes to up. This temporarily resets the R_CNTRL register which controls
the MII mode of the ENET_OUT clock. In the case of RMII, the clock
frequency momentarily drops from 50MHz to 25MHz until the register is
reconfigured. Some link partners do not tolerate this glitch and
invalidate the link causing failure to establish a stable link when using
PHY polling mode. Since as per IEEE802.11 the criteria for link validity
are PHY-specific, what the partner should tolerate cannot be assumed, so
avoid resetting the MII clock by using software reset instead of hardware
reset when the link is up. This is generally relevant only if the SoC
provides the clock to an external PHY and the PHY is configured for RMII.

Signed-off-by: Laurent Badel <laurentbadel@eaton.com>
---
 drivers/net/ethernet/freescale/fec.h      | 5 +++++
 drivers/net/ethernet/freescale/fec_main.c | 6 ++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index c527f4ee1d3a..0602d5d5d2ee 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -462,6 +462,11 @@ struct bufdesc_ex {
  */
 #define FEC_QUIRK_CLEAR_SETUP_MII	(1 << 17)
 
+/* Some link partners do not tolerate the momentary reset of the REF_CLK
+ * frequency when the RNCTL register is cleared by hardware reset.
+ */
+#define FEC_QUIRK_NO_HARD_RESET		(1 << 18)
+
 struct bufdesc_prop {
 	int qid;
 	/* Address of Rx and Tx buffers */
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 04f24c66cf36..0720f36ae384 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -100,7 +100,8 @@ static const struct fec_devinfo fec_imx27_info = {
 static const struct fec_devinfo fec_imx28_info = {
 	.quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME |
 		  FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC |
-		  FEC_QUIRK_HAS_FRREG | FEC_QUIRK_CLEAR_SETUP_MII,
+		  FEC_QUIRK_HAS_FRREG | FEC_QUIRK_CLEAR_SETUP_MII |
+		  FEC_QUIRK_NO_HARD_RESET,
 };
 
 static const struct fec_devinfo fec_imx6q_info = {
@@ -953,7 +954,8 @@ fec_restart(struct net_device *ndev)
 	 * For i.MX6SX SOC, enet use AXI bus, we use disable MAC
 	 * instead of reset MAC itself.
 	 */
-	if (fep->quirks & FEC_QUIRK_HAS_AVB) {
+	if (fep->quirks & FEC_QUIRK_HAS_AVB ||
+	    ((fep->quirks & FEC_QUIRK_NO_HARD_RESET) && fep->link)) {
 		writel(0, fep->hwp + FEC_ECNTRL);
 	} else {
 		writel(1, fep->hwp + FEC_ECNTRL);
-- 
2.17.1



-----------------------------
Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la Longeraie 7, 1110, Morges, Switzerland 

-----------------------------

Re: [PATCH v2 net 1/1] net: fec: Fix temporary RMII clock reset on link up

[Jakub Kicinski]

On Mon, 25 Jan 2021 11:07:45 +0100 Laurent Badel wrote:
> fec_restart() does a hard reset of the MAC module when the link status
> changes to up. This temporarily resets the R_CNTRL register which controls
> the MII mode of the ENET_OUT clock. In the case of RMII, the clock
> frequency momentarily drops from 50MHz to 25MHz until the register is
> reconfigured. Some link partners do not tolerate this glitch and
> invalidate the link causing failure to establish a stable link when using
> PHY polling mode. Since as per IEEE802.11 the criteria for link validity

I think you meant 802.3, fixed that up and applied, thanks!

> are PHY-specific, what the partner should tolerate cannot be assumed, so
> avoid resetting the MII clock by using software reset instead of hardware
> reset when the link is up. This is generally relevant only if the SoC
> provides the clock to an external PHY and the PHY is configured for RMII.

RE: [EXTERNAL] Re: [PATCH v2 net 1/1] net: fec: Fix temporary RMII clock reset on link up

[Badel, Laurent]

> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Wednesday, January 27, 2021 3:26 AM
> > PHY polling mode. Since as per IEEE802.11 the criteria for link
> validity
> 
> I think you meant 802.3, fixed that up and applied, thanks!
> 

You are right, I got confused. 
Thank you for your patience, I am only beginning to understand how things should be, and should not be, done, but hopefully I'll get there someday. 
Best regards,
Laurent


-----------------------------
Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la Longeraie 7, 1110, Morges, Switzerland 

-----------------------------