netdev - Broken networking on iMX8QXP after suspend after upgrading from 5.10 to 6.1

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]

Message-ID: <1f45bdbe-eab1-4e59-8f24-add177590d27@actia.se>
Date: Thu, 8 Feb 2024 13:16:43 +0000
From: John Ernberg <john.ernberg@...ia.se>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: Jonas Blixt <jonas.blixt@...ia.se>, Wei Fang <wei.fang@....com>, "Shenwei
 Wang" <shenwei.wang@....com>, Clark Wang <xiaoning.wang@....com>, Andrew Lunn
	<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King
	<linux@...linux.org.uk>
Subject: Broken networking on iMX8QXP after suspend after upgrading from 5.10
 to 6.1

Hi,

We just upgraded vendor kernel from 5.10 to 6.1 and ended up with broken
networking on our board  unless we bring the PHY up before the first
suspend of the system.

The link is brought up via external signal, so it is not guaranteed to
have been UP before the first system suspend.

We'd like to run the mainline kernel but we're not in a position to do so
yet. But we hope we can get some advice on this problem anyway.

We have a permanently powered Microchip LAN8700R (microchip_t1.c) connected
to an iMX8QXP (fec), to be able to wake the system via network if the link
is up.

This setup was working fine in 5.10.

The offending commit as far as we could bisect it is:
557d5dc83f68 ("net: fec: use mac-managed PHY PM")
And somewhat:
fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages 
PHY PM")

If the interface has not been brought UP before the system suspends we can
see this in dmesg:

     fec 5b040000.ethernet eth0: MDIO read timeout
     Microchip LAN87xx T1 5b040000.ethernet-1:04: PM: 
dpm_run_callback(): mdio_bus_phy_resume+0x0/0xc8 returns -110
     Microchip LAN87xx T1 5b040000.ethernet-1:04: PM: failed to resume: 
error -110

In this state it is impossible to bring the link up before removing all
power from the board and then plugging it in again, since the PHY is
permanently powered.

My understanding here is that since the link has never been UP,
fec_enet_open() has never executed, therefor mac_managed_pm is not true.
This in turn makes us take the normal PM flow.
Likewise in fec_resume() if the interface is not running, the MAC isn't
enabled because on the iMX8QXP the FEC is powered down in the suspend path
but never re-initialized and enabled in the resume path, so the MAC is
powered back up, but still disabled.

Adding the following seems to fix the issue, but I personally don't like
this, because we just allow the non-mac_managed_pm flow to run longer by
enabling the MAC again rather than letting the MAC do the PM as configured
in fec_enet_open().
What would be the correct thing to do here?

--------- >8 ------
  drivers/net/ethernet/freescale/fec_main.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index a9b61fcf9b5c..6be5f3883582 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -4690,6 +4690,8 @@ static int __maybe_unused fec_resume(struct device 
*dev)
                 ret = fec_restore_mii_bus(ndev);
                 if (ret < 0)
                         return ret;
+       } else {
+               fec_restart(ndev);
         }
         rtnl_unlock();

--

Thanks! // John Ernberg