Thread (11 messages) 11 messages, 5 authors, 2021-12-15

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

flat view

From: Joakim Zhang <hidden>
Date: 2021-12-15 10:25:19
Also in: lkml

Hi Francesco,
quoted hunk ↗ jump to hunk
-----Original Message-----
From: Francesco Dolcini <redacted>
Sent: 2021年12月15日 6:36
To: Andrew Lunn <andrew@lunn.ch>
Cc: Philippe Schenker <redacted>;
netdev@vger.kernel.org; Joakim Zhang [off-list ref]; David
S . Miller [off-list ref]; Russell King [off-list ref];
Heiner Kallweit [off-list ref]; Francesco Dolcini
[off-list ref]; Jakub Kicinski [off-list ref]; Fabio
Estevam [off-list ref]; Fugang Duan [off-list ref];
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:
quoted
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.
quoted
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")
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help