[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM5PR04MB313943C24A61C48D761B452688BC9@AM5PR04MB3139.eurprd04.prod.outlook.com>
Date: Thu, 16 Mar 2023 09:10:23 +0000
From: Wei Fang <wei.fang@....com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
Shenwei Wang <shenwei.wang@....com>,
Clark Wang <xiaoning.wang@....com>,
dl-linux-imx <linux-imx@....com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 3/4] fec: add FIXME to move 'mac_managed_pm' to
probe
> -----Original Message-----
> From: Wolfram Sang <wsa+renesas@...g-engineering.com>
> Sent: 2023年3月16日 16:02
> To: Wei Fang <wei.fang@....com>; linux-renesas-soc@...r.kernel.org;
> kernel@...gutronix.de; Shenwei Wang <shenwei.wang@....com>; Clark
> Wang <xiaoning.wang@....com>; dl-linux-imx <linux-imx@....com>; David S.
> Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>;
> Jakub Kicinski <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>;
> linux-kernel@...r.kernel.org; netdev@...r.kernel.org
> Subject: Re: [PATCH net-next 3/4] fec: add FIXME to move 'mac_managed_pm'
> to probe
>
>
> > Yes, I will resend the series as RFC with more explanations.
>
> Because I was able to fix SMSC myself, I'll just describe the procedure
> here:
>
> 1) apply this debug patch:
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index
> 1b2e253fce75..7b79c5979486 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -310,6 +310,8 @@ static __maybe_unused int
> mdio_bus_phy_suspend(struct device *dev)
> if (phydev->mac_managed_pm)
> return 0;
>
> +printk(KERN_INFO "****** MDIO suspend\n");
> +
> /* Wakeup interrupts may occur during the system sleep transition when
> * the PHY is inaccessible. Set flag to postpone handling until the PHY
> * has resumed. Wait for concurrent interrupt handler to complete.
>
> 2) boot the device without bringing the interface (and thus the PHY) up.
> Bringing it down after it was up is not the same! It is important
> that it was never up before.
>
> 3) do a suspend-to-ram/resume cycle
>
> 4) your log should show the above debug message. If not, I was wrong
>
> 5) If yes, apply a similar fix to the one I did for the Renesas drivers
> in this series
>
> 6) suspend/resume should not show the debug message anymore
>
> 7) test for regressions and send out :)
>
> I hope this was understandable. If not, feel free to ask.
>
> Happy hacking,
>
Thank you Wolfram. But I'm not sure whether it's really an issue. The flag
" mac_managed_pm" indicates that the MAC driver will take care of
suspending/resuming the PHY, that is to say the MAC driver calls
phy_stop()/phy_start() in its PM callbacks. If a ethernet interface never
brings up, the MAC PM callbacks do nothing and just return 0 directly. So I
think it's fine for the MDIO PM to do suspend/resume the PHY unless the MDIO
bus can't be accessed.
Powered by blists - more mailing lists