RE: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up

[Joakim Zhang]

Hi Francesco,

> -----Original Message-----
> From: Francesco Dolcini <francesco.dolcini@xxxxxxxxxxx>
> Sent: 2021年12月15日 6:36
> To: Andrew Lunn <andrew@xxxxxxx>
> Cc: Philippe Schenker <philippe.schenker@xxxxxxxxxxx>;
> netdev@xxxxxxxxxxxxxxx; Joakim Zhang <qiangqing.zhang@xxxxxxx>; David
> S . Miller <davem@xxxxxxxxxxxxx>; Russell King <linux@xxxxxxxxxxxxxxx>;
> Heiner Kallweit <hkallweit1@xxxxxxxxx>; Francesco Dolcini
> <francesco.dolcini@xxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Fabio
> Estevam <festevam@xxxxxxxxx>; Fugang Duan <fugang.duan@xxxxxxx>;
> linux-kernel@xxxxxxxxxxxxxxx
> 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")