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-next>] [day] [month] [year] [list]
Date:   Fri, 22 Jan 2021 16:13:46 +0100
From:   Laurent Badel <laurentbadel@...on.com>
To:     Fugang Duan <fugang.duan@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
CC:     Laurent Badel <laurentbadel@...on.com>
Subject: [PATCH net 0/1] net: fec: Fix RMII clock glitch in FEC

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):
  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 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ