netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Ernberg <john.ernberg@actia.se>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Jonas Blixt <jonas.blixt@actia.se>, Wei Fang <wei.fang@nxp.com>,
	"Shenwei Wang" <shenwei.wang@nxp.com>,
	Clark Wang <xiaoning.wang@nxp.com>, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>
Subject: Broken networking on iMX8QXP after suspend after upgrading from 5.10 to 6.1
Date: Thu, 8 Feb 2024 13:16:43 +0000	[thread overview]
Message-ID: <1f45bdbe-eab1-4e59-8f24-add177590d27@actia.se> (raw)

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

             reply	other threads:[~2024-02-08 13:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 13:16 John Ernberg [this message]
2024-02-19  2:25 ` Broken networking on iMX8QXP after suspend after upgrading from 5.10 to 6.1 Wei Fang
2024-02-28  7:59   ` John Ernberg
2024-02-28  8:34     ` Wei Fang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f45bdbe-eab1-4e59-8f24-add177590d27@actia.se \
    --to=john.ernberg@actia.se \
    --cc=andrew@lunn.ch \
    --cc=hkallweit1@gmail.com \
    --cc=jonas.blixt@actia.se \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=shenwei.wang@nxp.com \
    --cc=wei.fang@nxp.com \
    --cc=xiaoning.wang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).