lkml.org 
[lkml]   [2021]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up
Date

Hi Francesco,

> -----Original Message-----
> From: Francesco Dolcini <francesco.dolcini@toradex.com>
> Sent: 2021年12月15日 6:36
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: Philippe Schenker <philippe.schenker@toradex.com>;
> netdev@vger.kernel.org; Joakim Zhang <qiangqing.zhang@nxp.com>; David
> S . Miller <davem@davemloft.net>; Russell King <linux@armlinux.org.uk>;
> Heiner Kallweit <hkallweit1@gmail.com>; Francesco Dolcini
> <francesco.dolcini@toradex.com>; Jakub Kicinski <kuba@kernel.org>; Fabio
> Estevam <festevam@gmail.com>; Fugang Duan <fugang.duan@nxp.com>;
> linux-kernel@vger.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&amp;sdata=itV
> m0jroQ0MzDG5Ipqs3OY0F5SY%2FkbdFRWauNKq2XiQ%3D&amp;reserved=0
> [2] 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")

\
 
 \ /
  Last update: 2021-12-15 11:26    [W:0.086 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site