* [PATCH] net: stmmac: linkup phy after enabled mac when system resume
@ 2022-10-19 12:36 ` Clark Wang
0 siblings, 0 replies; 4+ messages in thread
From: Clark Wang @ 2022-10-19 12:36 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem, edumazet, kuba,
pabeni, mcoquelin.stm32
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, linux-imx
Here is an issue: after enabled the WoL function, EQoS cannot send and
receive data after resumed because of the wrong setting of
MAC_CONFIGURATION register.
When enable the WoL function, stmmac_resume will call stmmac_hw_setup
and phylink_resume.
- When do stmmac_hw_setup, it will reset the stmmac, and re-config the
register GMAC_CONFIG with a fixed default value GMAC_CORE_INIT.
- When do phylink_resume in stmmac_resume, it will call stmmac_mac_link_up in
a workqueue. stmmac_mac_link_up will set the correct speed/duplex states
provided by phy to the CONFIG register.
So when resume the stmmac, the workqueue of phylink_resume must be run after
the stmmac_hw_setup to ensure that the configuration of the CONFIG register
is correct.
In order to ensure this, put the place of phylink_resume consistent with
stmmac_open.
Make sure that stmmac_mac_link_up is called after stmmac_hw_setup even the
workqueue of phylink_resume is run immediately.
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 65c96773c6d2..79c9ea451a81 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7515,16 +7515,6 @@ int stmmac_resume(struct device *dev)
return ret;
}
- rtnl_lock();
- if (device_may_wakeup(priv->device) && priv->plat->pmt) {
- phylink_resume(priv->phylink);
- } else {
- phylink_resume(priv->phylink);
- if (device_may_wakeup(priv->device))
- phylink_speed_up(priv->phylink);
- }
- rtnl_unlock();
-
rtnl_lock();
mutex_lock(&priv->lock);
@@ -7539,6 +7529,16 @@ int stmmac_resume(struct device *dev)
stmmac_restore_hw_vlan_rx_fltr(priv, ndev, priv->hw);
+ mutex_unlock(&priv->lock);
+ if (device_may_wakeup(priv->device) && priv->plat->pmt) {
+ phylink_resume(priv->phylink);
+ } else {
+ phylink_resume(priv->phylink);
+ if (device_may_wakeup(priv->device))
+ phylink_speed_up(priv->phylink);
+ }
+ mutex_lock(&priv->lock);
+
stmmac_enable_all_queues(priv);
stmmac_enable_all_dma_irq(priv);
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH] net: stmmac: linkup phy after enabled mac when system resume
@ 2022-10-19 12:36 ` Clark Wang
0 siblings, 0 replies; 4+ messages in thread
From: Clark Wang @ 2022-10-19 12:36 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem, edumazet, kuba,
pabeni, mcoquelin.stm32
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, linux-imx
Here is an issue: after enabled the WoL function, EQoS cannot send and
receive data after resumed because of the wrong setting of
MAC_CONFIGURATION register.
When enable the WoL function, stmmac_resume will call stmmac_hw_setup
and phylink_resume.
- When do stmmac_hw_setup, it will reset the stmmac, and re-config the
register GMAC_CONFIG with a fixed default value GMAC_CORE_INIT.
- When do phylink_resume in stmmac_resume, it will call stmmac_mac_link_up in
a workqueue. stmmac_mac_link_up will set the correct speed/duplex states
provided by phy to the CONFIG register.
So when resume the stmmac, the workqueue of phylink_resume must be run after
the stmmac_hw_setup to ensure that the configuration of the CONFIG register
is correct.
In order to ensure this, put the place of phylink_resume consistent with
stmmac_open.
Make sure that stmmac_mac_link_up is called after stmmac_hw_setup even the
workqueue of phylink_resume is run immediately.
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 65c96773c6d2..79c9ea451a81 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7515,16 +7515,6 @@ int stmmac_resume(struct device *dev)
return ret;
}
- rtnl_lock();
- if (device_may_wakeup(priv->device) && priv->plat->pmt) {
- phylink_resume(priv->phylink);
- } else {
- phylink_resume(priv->phylink);
- if (device_may_wakeup(priv->device))
- phylink_speed_up(priv->phylink);
- }
- rtnl_unlock();
-
rtnl_lock();
mutex_lock(&priv->lock);
@@ -7539,6 +7529,16 @@ int stmmac_resume(struct device *dev)
stmmac_restore_hw_vlan_rx_fltr(priv, ndev, priv->hw);
+ mutex_unlock(&priv->lock);
+ if (device_may_wakeup(priv->device) && priv->plat->pmt) {
+ phylink_resume(priv->phylink);
+ } else {
+ phylink_resume(priv->phylink);
+ if (device_may_wakeup(priv->device))
+ phylink_speed_up(priv->phylink);
+ }
+ mutex_lock(&priv->lock);
+
stmmac_enable_all_queues(priv);
stmmac_enable_all_dma_irq(priv);
--
2.34.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] net: stmmac: linkup phy after enabled mac when system resume
2022-10-19 12:36 ` Clark Wang
@ 2022-10-19 12:49 ` Russell King (Oracle)
-1 siblings, 0 replies; 4+ messages in thread
From: Russell King (Oracle) @ 2022-10-19 12:49 UTC (permalink / raw)
To: Clark Wang
Cc: peppe.cavallaro, alexandre.torgue, joabreu, davem, edumazet, kuba,
pabeni, mcoquelin.stm32, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, linux-imx
On Wed, Oct 19, 2022 at 08:36:43PM +0800, Clark Wang wrote:
> + mutex_unlock(&priv->lock);
> + if (device_may_wakeup(priv->device) && priv->plat->pmt) {
> + phylink_resume(priv->phylink);
> + } else {
> + phylink_resume(priv->phylink);
> + if (device_may_wakeup(priv->device))
> + phylink_speed_up(priv->phylink);
> + }
> + mutex_lock(&priv->lock);
First, is there a reason this isn't coded as:
mutex_unlock(&priv->lock);
phylink_resume(priv->phylink);
if (!priv->plat->pmt && device_may_wakeup(priv->device))
phylink_speed_up(priv->phylink);
mutex_lock(&priv->lock);
And secondly, is it really safe to drop this lock? What specifically
is the lock protecting? I see this isn't documented in the driver...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] net: stmmac: linkup phy after enabled mac when system resume
@ 2022-10-19 12:49 ` Russell King (Oracle)
0 siblings, 0 replies; 4+ messages in thread
From: Russell King (Oracle) @ 2022-10-19 12:49 UTC (permalink / raw)
To: Clark Wang
Cc: peppe.cavallaro, alexandre.torgue, joabreu, davem, edumazet, kuba,
pabeni, mcoquelin.stm32, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, linux-imx
On Wed, Oct 19, 2022 at 08:36:43PM +0800, Clark Wang wrote:
> + mutex_unlock(&priv->lock);
> + if (device_may_wakeup(priv->device) && priv->plat->pmt) {
> + phylink_resume(priv->phylink);
> + } else {
> + phylink_resume(priv->phylink);
> + if (device_may_wakeup(priv->device))
> + phylink_speed_up(priv->phylink);
> + }
> + mutex_lock(&priv->lock);
First, is there a reason this isn't coded as:
mutex_unlock(&priv->lock);
phylink_resume(priv->phylink);
if (!priv->plat->pmt && device_may_wakeup(priv->device))
phylink_speed_up(priv->phylink);
mutex_lock(&priv->lock);
And secondly, is it really safe to drop this lock? What specifically
is the lock protecting? I see this isn't documented in the driver...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-10-19 13:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-19 12:36 [PATCH] net: stmmac: linkup phy after enabled mac when system resume Clark Wang
2022-10-19 12:36 ` Clark Wang
2022-10-19 12:49 ` Russell King (Oracle)
2022-10-19 12:49 ` Russell King (Oracle)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.