Re: [PATCH RFCv2 3/6] net: phy: provide phy_resume/phy_suspend helpers
2013/12/4 Sebastian Hesselbarth : > This adds helper functions to resume and suspend a given phy_device > by calling the corresponding driver callbacks if available. > > Signed-off-by: Sebastian Hesselbarth > --- > Changelog: > RFCv1->RFCv2: > - only suspend if WOL is not enabled > - remove EXPORT_SYMBOL for phy_suspend/resume > > Cc: David Miller > Cc: Florian Fainelli > Cc: Mugunthan V N > Cc: net...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/net/phy/phy_device.c | 24 > include/linux/phy.h |2 ++ > 2 files changed, 26 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c > index d6447b3..6f0e9e4 100644 > --- a/drivers/net/phy/phy_device.c > +++ b/drivers/net/phy/phy_device.c > @@ -625,6 +625,30 @@ void phy_detach(struct phy_device *phydev) > } > EXPORT_SYMBOL(phy_detach); > > +int phy_suspend(struct phy_device *phydev) > +{ > + struct phy_driver *phydrv = to_phy_driver(phydev->dev.driver); > + struct ethtool_wolinfo wol; > + > + /* If the device has WOL enabled, we cannot suspend the PHY */ > + wol.cmd = ETHTOOL_GWOL; > + phy_ethtool_get_wol(phydev, ); > + if (wol.wolopts) > + return -EBUSY; I wonder if we should not set a flag in the phy device structure which says "someone called my phydrv->set_wol() callback, this succeeded and WoL is now enabled for me", rather than using this potentially racy call? This would have to be modified in phy_ethtool_set_wol() for instance? This is kind of theoretical though as I can't picture a case where this sequence of events would happen in real-life. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFCv2 3/6] net: phy: provide phy_resume/phy_suspend helpers
2013/12/4 Sebastian Hesselbarth sebastian.hesselba...@gmail.com: This adds helper functions to resume and suspend a given phy_device by calling the corresponding driver callbacks if available. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: RFCv1-RFCv2: - only suspend if WOL is not enabled - remove EXPORT_SYMBOL for phy_suspend/resume Cc: David Miller da...@davemloft.net Cc: Florian Fainelli f.faine...@gmail.com Cc: Mugunthan V N mugunthan...@ti.com Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/phy/phy_device.c | 24 include/linux/phy.h |2 ++ 2 files changed, 26 insertions(+), 0 deletions(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index d6447b3..6f0e9e4 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -625,6 +625,30 @@ void phy_detach(struct phy_device *phydev) } EXPORT_SYMBOL(phy_detach); +int phy_suspend(struct phy_device *phydev) +{ + struct phy_driver *phydrv = to_phy_driver(phydev-dev.driver); + struct ethtool_wolinfo wol; + + /* If the device has WOL enabled, we cannot suspend the PHY */ + wol.cmd = ETHTOOL_GWOL; + phy_ethtool_get_wol(phydev, wol); + if (wol.wolopts) + return -EBUSY; I wonder if we should not set a flag in the phy device structure which says someone called my phydrv-set_wol() callback, this succeeded and WoL is now enabled for me, rather than using this potentially racy call? This would have to be modified in phy_ethtool_set_wol() for instance? This is kind of theoretical though as I can't picture a case where this sequence of events would happen in real-life. -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/