[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB8PR04MB679570A356B655A5D6BFE818E6769@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date: Wed, 15 Dec 2021 10:25:14 +0000
From: Joakim Zhang <qiangqing.zhang@....com>
To: Francesco Dolcini <francesco.dolcini@...adex.com>,
Andrew Lunn <andrew@...n.ch>
CC: Philippe Schenker <philippe.schenker@...adex.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Russell King <linux@...linux.org.uk>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Fabio Estevam <festevam@...il.com>,
Fugang Duan <fugang.duan@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up
Hi Francesco,
> -----Original Message-----
> From: Francesco Dolcini <francesco.dolcini@...adex.com>
> Sent: 2021年12月15日 6:36
> To: Andrew Lunn <andrew@...n.ch>
> Cc: Philippe Schenker <philippe.schenker@...adex.com>;
> netdev@...r.kernel.org; Joakim Zhang <qiangqing.zhang@....com>; David
> S . Miller <davem@...emloft.net>; Russell King <linux@...linux.org.uk>;
> Heiner Kallweit <hkallweit1@...il.com>; Francesco Dolcini
> <francesco.dolcini@...adex.com>; Jakub Kicinski <kuba@...nel.org>; Fabio
> Estevam <festevam@...il.com>; Fugang Duan <fugang.duan@....com>;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH net-next 3/3] net: fec: reset phy on resume after
> power-up
>
> Hello Andrew,
>
> On Tue, Dec 14, 2021 at 07:54:54PM +0100, Andrew Lunn wrote:
> > What i don't particularly like about this is that the MAC driver is
> > doing it. Meaning if this PHY is used with any other MAC, the same
> > code needs adding there.
> This is exactly the same case as phy_reset_after_clk_enable() [1][2], to me it
> does not look that bad.
>
> > So maybe in the phy driver, add a suspend handler, which asserts the
> > reset. This call here will take it out of reset, so applying the reset
> > you need?
> Asserting the reset in the phylib in suspend path is a bad idea, in the general
> case in which the PHY is powered in suspend the power-consumption is likely
> to be higher if the device is in reset compared to software power-down using
> the BMCR register (at least for the PHY datasheet I checked).
>
> What we could do is to call phy_device_reset in the fec driver suspend path
> when we know we are going to disable the regulator, I do not like it, but it
> would solve the issue.
>
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -4064,7 +4064,11 @@ static int __maybe_unused fec_suspend(struct
> device *dev)
> rtnl_unlock();
>
> if (fep->reg_phy && !(fep->wol_flag & FEC_WOL_FLAG_ENABLE))
> + {
> regulator_disable(fep->reg_phy);
> + phy_device_reset(ndev->phydev, 1);
> + }
> +
>
> /* SOC supply clock to phy, when clock is disabled, phy link down
> * SOC control phy regulator, when regulator is disabled, phy link
> down
As I mentioned before, both mac and phylib have not taken PHY reset into consideration during
system suspend/resume scenario. As Andrew suggested, you could move this into phy driver suspend
function, this is a corner case. One point I don't understand, why do you reject to assert reset signal during
system suspended?
Best Regards,
Joakim Zhang
> Francesco
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Fnetdev%2F20171211121700.10200-1-dev%40g0hl1n.net%2F&a
> mp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cf7140fe971544fe8d2
> 2608d9bf521517%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6377
> 51181527979233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=itV
> m0jroQ0MzDG5Ipqs3OY0F5SY%2FkbdFRWauNKq2XiQ%3D&reserved=0
> [2] 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")
Powered by blists - more mailing lists