90702dcd19c ("net: stmmac: fix MAC not working when system resume back
with WoL active") introduced a section of code in stmmac_resume that
is protected with rtnl_lock/rtnl_unlock. However, the call to
rtnl_unlock() is followed by an already existing call to rtnl_lock().
Instead of unlock/lock, allow the prexisting lock to continue.
Signed-off-by: Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index eb3b7bf771d7..5e69380027af 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7263,9 +7263,7 @@ int stmmac_resume(struct device *dev)
if (device_may_wakeup(priv->device))
phylink_speed_up(priv->phylink);
}
- rtnl_unlock();
- rtnl_lock();
mutex_lock(&priv->lock);
stmmac_reset_queues_param(priv);
--
2.33.0
Is this a valid patch? Perhaps the lock is released in the middle
on purpose but I would assume it was just an little oversight.
