[PATCH net-next] net: phy: don't touch suspended flag if there's no suspend/resume callback

[PATCH net-next] net: phy: don't touch suspended flag if there's no suspend/resume callback

[Heiner Kallweit]

So far we set phydev->suspended to true in phy_suspend() even if the
PHY driver doesn't implement the suspend callback. This applies
accordingly for the resume path. The current behavior doesn't cause
any issue I'd be aware of, but it's not logical and misleading,
especially considering the description of the flag:
"suspended: Set to true if this phy has been suspended successfully"

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/net/phy/phy_device.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 3b8f6b0b4..d6024b678 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1519,23 +1519,22 @@ EXPORT_SYMBOL(phy_detach);
 
 int phy_suspend(struct phy_device *phydev)
 {
-	struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
-	struct net_device *netdev = phydev->attached_dev;
 	struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
-	int ret = 0;
+	struct net_device *netdev = phydev->attached_dev;
+	struct phy_driver *phydrv = phydev->drv;
+	int ret;
 
 	/* If the device has WOL enabled, we cannot suspend the PHY */
 	phy_ethtool_get_wol(phydev, &wol);
 	if (wol.wolopts || (netdev && netdev->wol_enabled))
 		return -EBUSY;
 
-	if (phydev->drv && phydrv->suspend)
-		ret = phydrv->suspend(phydev);
-
-	if (ret)
-		return ret;
+	if (!phydrv || !phydrv->suspend)
+		return 0;
 
-	phydev->suspended = true;
+	ret = phydrv->suspend(phydev);
+	if (!ret)
+		phydev->suspended = true;
 
 	return ret;
 }
@@ -1543,18 +1542,17 @@ EXPORT_SYMBOL(phy_suspend);
 
 int __phy_resume(struct phy_device *phydev)
 {
-	struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
-	int ret = 0;
+	struct phy_driver *phydrv = phydev->drv;
+	int ret;
 
 	WARN_ON(!mutex_is_locked(&phydev->lock));
 
-	if (phydev->drv && phydrv->resume)
-		ret = phydrv->resume(phydev);
-
-	if (ret)
-		return ret;
+	if (!phydrv || !phydrv->resume)
+		return 0;
 
-	phydev->suspended = false;
+	ret = phydrv->resume(phydev);
+	if (!ret)
+		phydev->suspended = false;
 
 	return ret;
 }
-- 
2.26.0

Re: [PATCH net-next] net: phy: don't touch suspended flag if there's no suspend/resume callback

[Andrew Lunn]

On Thu, Mar 26, 2020 at 06:58:24PM +0100, Heiner Kallweit wrote:
> So far we set phydev->suspended to true in phy_suspend() even if the
> PHY driver doesn't implement the suspend callback. This applies
> accordingly for the resume path. The current behavior doesn't cause
> any issue I'd be aware of, but it's not logical and misleading,
> especially considering the description of the flag:
> "suspended: Set to true if this phy has been suspended successfully"
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net-next] net: phy: don't touch suspended flag if there's no suspend/resume callback

[Florian Fainelli]

On 3/26/2020 10:58 AM, Heiner Kallweit wrote:
> So far we set phydev->suspended to true in phy_suspend() even if the
> PHY driver doesn't implement the suspend callback. This applies
> accordingly for the resume path. The current behavior doesn't cause
> any issue I'd be aware of, but it's not logical and misleading,
> especially considering the description of the flag:
> "suspended: Set to true if this phy has been suspended successfully"
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

Re: [PATCH net-next] net: phy: don't touch suspended flag if there's no suspend/resume callback

[David Miller]

From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 26 Mar 2020 18:58:24 +0100

> So far we set phydev->suspended to true in phy_suspend() even if the
> PHY driver doesn't implement the suspend callback. This applies
> accordingly for the resume path. The current behavior doesn't cause
> any issue I'd be aware of, but it's not logical and misleading,
> especially considering the description of the flag:
> "suspended: Set to true if this phy has been suspended successfully"
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Applied, thanks.