| Message ID | 20210621094536.387442-4-pei.lee.ling@intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add option to enable PHY WOL with PMT enabled | expand |
> > From: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> > > > > After PHY received a magic packet, the PHY WOL event will be triggered > > then PHY WOL event interrupt will be disarmed. > > Ethtool settings will remain with WOL enabled after a S3/S4 suspend > > resume cycle as expected. Hence,the driver should reconfigure the PHY > > settings to reenable/disable WOL depending on the ethtool WOL settings > > in the resume flow. > > Please could you explain this a bit more? I'm wondering if you have a > PHY driver bug. PHY WOL should remain enabled until it is explicitly > disabled. > > Andrew Let's take Marvell 1510 as example. As explained in driver/net/phy/marvell.c 1773 >------->-------/* If WOL event happened once, the LED[2] interrupt pin 1774 >------->------- * will not be cleared unless we reading the interrupt status 1775 >------->------- * register. The WOL event will not able trigger again if the driver does not clear the interrupt status. Are we expecting PHY driver will automatically clears the interrupt status rather than trigger from the MAC driver? After scanning through all the PHY drivers, the drivers only touches the WOL settings in the get|set_wol() callbacks. Hence, I think that currently there are no PHY drivers that clear the WOL status. Unless the PHY able to self-clear the WOL event status, the PHY WOL would not able to remain enabled after resume from S3/S4. Therefore, we implemented it in the MAC driver to reconfigure the PHY WOL during the MAC resume() flow. Weifeng
On Wed, Jun 23, 2021 at 10:06:44AM +0000, Voon, Weifeng wrote: > > > From: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> > > > > > > After PHY received a magic packet, the PHY WOL event will be triggered > > > then PHY WOL event interrupt will be disarmed. > > > Ethtool settings will remain with WOL enabled after a S3/S4 suspend > > > resume cycle as expected. Hence,the driver should reconfigure the PHY > > > settings to reenable/disable WOL depending on the ethtool WOL settings > > > in the resume flow. > > > > Please could you explain this a bit more? I'm wondering if you have a > > PHY driver bug. PHY WOL should remain enabled until it is explicitly > > disabled. > > > > Andrew > > Let's take Marvell 1510 as example. > > As explained in driver/net/phy/marvell.c > 1773 >------->-------/* If WOL event happened once, the LED[2] interrupt pin > 1774 >------->------- * will not be cleared unless we reading the interrupt status > 1775 >------->------- * register. > > The WOL event will not able trigger again if the driver does not clear > the interrupt status. > Are we expecting PHY driver will automatically clears the interrupt > status rather than trigger from the MAC driver? So you are saying the interrupt it getting discarded? I would of though it is this interrupt which brings to system out of suspend, and it should trigger the usual action, i.e. call the interrupt handler. That should then clear the interrupt. Andrew
> > > > After PHY received a magic packet, the PHY WOL event will be > > > > triggered then PHY WOL event interrupt will be disarmed. > > > > Ethtool settings will remain with WOL enabled after a S3/S4 > > > > suspend resume cycle as expected. Hence,the driver should > > > > reconfigure the PHY settings to reenable/disable WOL depending on > > > > the ethtool WOL settings in the resume flow. > > > > > > Please could you explain this a bit more? I'm wondering if you have > > > a PHY driver bug. PHY WOL should remain enabled until it is > > > explicitly disabled. > > > > > > Andrew > > > > Let's take Marvell 1510 as example. > > > > As explained in driver/net/phy/marvell.c > > 1773 >------->-------/* If WOL event happened once, the LED[2] > > interrupt pin > > 1774 >------->------- * will not be cleared unless we reading the > > interrupt status > > 1775 >------->------- * register. > > > > The WOL event will not able trigger again if the driver does not clear > > the interrupt status. > > Are we expecting PHY driver will automatically clears the interrupt > > status rather than trigger from the MAC driver? > > So you are saying the interrupt it getting discarded? I would of though it > is this interrupt which brings to system out of suspend, and it should > trigger the usual action, i.e. call the interrupt handler. That should then > clear the interrupt. > > Andrew No, the interrupt will not be discarded. If the PHY is in interrupt mode, the interrupt handler will triggers and ISR will clear the WOL status bit. The condition here is when the PHY is in polling mode, the PHY driver does not have any other mechanism to clear the WOL interrupt status bit. Hence, we need to go through the PHY set_wol() again. Weifeng
> No, the interrupt will not be discarded. If the PHY is in interrupt mode, the > interrupt handler will triggers and ISR will clear the WOL status bit. > The condition here is when the PHY is in polling mode, the PHY driver does not > have any other mechanism to clear the WOL interrupt status bit. > Hence, we need to go through the PHY set_wol() again. I would say you have a broken setup. If you are explicitly using the interrupt as a wakeup source, you need to be servicing the interrupt. You cannot use polled mode. Andrew
> > No, the interrupt will not be discarded. If the PHY is in interrupt > > mode, the interrupt handler will triggers and ISR will clear the WOL > status bit. > > The condition here is when the PHY is in polling mode, the PHY driver > > does not have any other mechanism to clear the WOL interrupt status bit. > > Hence, we need to go through the PHY set_wol() again. > > I would say you have a broken setup. If you are explicitly using the > interrupt as a wakeup source, you need to be servicing the interrupt. You > cannot use polled mode. Sorry for the confusion. But I would like to clarify the I should use the term of "WOL event status" rather than "WOL interrupt status". For interrupt mode, clearing the "WOL interrupt status" register will auto clear the "WOL event status". For polling mode, the phy driver can manually clear the "WOL event status" by setting 1 to "Clear WOL Status" bit. I would like to rephase the commit message to make things clear: After PHY received a magic packet, the PHY WOL event will be triggered. At the same time, the "Magic Packet Match Detected" bit is set. In order for the PHY WOL event to be triggered again, the WOL event status of "Magic Packet Match Detected" bit needs to be cleared. When the PHY is in polling mode, the WOL event status needs to be manually cleared. Ethtool settings will remain with WOL enabled after a S3/S4 suspend resume cycle as expected. Hence, the driver should reconfigure the PHY settings to reenable/disable WOL depending on the ethtool WOL settings in the MAC resume flow. The PHY set_wol flow would clear the WOL event status. Weifeng
> I would like to rephase the commit message to make things clear: > > After PHY received a magic packet, the PHY WOL event will be > triggered. At the same time, the "Magic Packet Match Detected" bit > is set. In order for the PHY WOL event to be triggered again, the > WOL event status of "Magic Packet Match Detected" bit needs to be > cleared. When the PHY is in polling mode, the WOL event status needs > to be manually cleared. > > Ethtool settings will remain with WOL enabled after a S3/S4 > suspend resume cycle as expected. Hence, the driver should > reconfigure the PHY settings to reenable/disable WOL > depending on the ethtool WOL settings in the MAC resume flow. > The PHY set_wol flow would clear the WOL event status. I would still argue that making use of a WoL interrupts and PHY polling is just wrong. But i assume you cannot fix this? You have a hardware design error? The problem with this solution is you need to modify every MAC driver using the Marvell PHY. It does not scale. Please try to find a solution within phylib or the marvell driver. Something which will work for any broken setup which is using WoL interrupts combined with polling. Andrew
On Fri, Jun 25, 2021 at 03:58:17PM +0000, Voon, Weifeng wrote: > > > No, the interrupt will not be discarded. If the PHY is in interrupt > > > mode, the interrupt handler will triggers and ISR will clear the WOL > > status bit. > > > The condition here is when the PHY is in polling mode, the PHY driver > > > does not have any other mechanism to clear the WOL interrupt status bit. > > > Hence, we need to go through the PHY set_wol() again. > > > > I would say you have a broken setup. If you are explicitly using the > > interrupt as a wakeup source, you need to be servicing the interrupt. You > > cannot use polled mode. > > Sorry for the confusion. But I would like to clarify the I should use the > term of "WOL event status" rather than "WOL interrupt status". > For interrupt mode, clearing the "WOL interrupt status" register will auto > clear the "WOL event status". > For polling mode, the phy driver can manually clear the "WOL event status" by > setting 1 to "Clear WOL Status" bit. If WOL raises an interrupt signal from the PHY, but the PHY interrupt signal is not wired, how does the wakeup happen? What is the PHY interrupt wired to? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> > I would like to rephase the commit message to make things clear: > > > > After PHY received a magic packet, the PHY WOL event will be > > triggered. At the same time, the "Magic Packet Match Detected" bit is > > set. In order for the PHY WOL event to be triggered again, the WOL > > event status of "Magic Packet Match Detected" bit needs to be cleared. > > When the PHY is in polling mode, the WOL event status needs to be > > manually cleared. > > > > Ethtool settings will remain with WOL enabled after a S3/S4 suspend > > resume cycle as expected. Hence, the driver should reconfigure the PHY > > settings to reenable/disable WOL depending on the ethtool WOL settings > > in the MAC resume flow. > > The PHY set_wol flow would clear the WOL event status. > > I would still argue that making use of a WoL interrupts and PHY polling is > just wrong. But i assume you cannot fix this? You have a hardware design > error? > > The problem with this solution is you need to modify every MAC driver using > the Marvell PHY. It does not scale. > > Please try to find a solution within phylib or the marvell driver. > Something which will work for any broken setup which is using WoL > interrupts combined with polling. Yes, I would not able to fix this as the PHY WOL event signal pin is connected directly to the PMC. And, I do not have the info why the HW is designed in this way. But, I totally agreed that this solution is not scalable. We will drop this patch from this patchset for v2. We will find another solution and most probably in phylib as this behavior most likely will be similar across all other PHYs. Weifeng
> > > > No, the interrupt will not be discarded. If the PHY is in > > > > interrupt mode, the interrupt handler will triggers and ISR will > > > > clear the WOL > > > status bit. > > > > The condition here is when the PHY is in polling mode, the PHY > > > > driver does not have any other mechanism to clear the WOL interrupt > status bit. > > > > Hence, we need to go through the PHY set_wol() again. > > > > > > I would say you have a broken setup. If you are explicitly using the > > > interrupt as a wakeup source, you need to be servicing the > > > interrupt. You cannot use polled mode. > > > > Sorry for the confusion. But I would like to clarify the I should use > > the term of "WOL event status" rather than "WOL interrupt status". > > For interrupt mode, clearing the "WOL interrupt status" register will > > auto clear the "WOL event status". > > For polling mode, the phy driver can manually clear the "WOL event > > status" by setting 1 to "Clear WOL Status" bit. > > If WOL raises an interrupt signal from the PHY, but the PHY interrupt > signal is not wired, how does the wakeup happen? What is the PHY interrupt > wired to? The PHY WOL event signal is wired directly to the PMC. The PMC will detect the triggered WOL event signal and wakeup the system. Weifeng
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index a3b79ddcf08e..cd96e4d7a22e 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -7246,6 +7246,16 @@ int stmmac_resume(struct device *dev) phylink_start(priv->phylink); /* We may have called phylink_speed_down before */ phylink_speed_up(priv->phylink); + /* Reconfigure PHY WOL if the WOL is enabled in ethtool, + * so that subsequent WOL still can be triggered. + */ + if (!priv->plat->pmt) { + struct ethtool_wolinfo phy_wol = { .cmd = ETHTOOL_GWOL }; + + phylink_ethtool_get_wol(priv->phylink, &phy_wol); + if (phy_wol.wolopts) + phylink_ethtool_set_wol(priv->phylink, &phy_wol); + } rtnl_unlock(); }