Messages in this thread | | | From | Joakim Zhang <> | Subject | RE: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up | Date | Wed, 15 Dec 2021 10:25:14 +0000 |
| |
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&sdata=itV > m0jroQ0MzDG5Ipqs3OY0F5SY%2FkbdFRWauNKq2XiQ%3D&reserved=0 > [2] 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")
| |