On Mon, Jun 21, 2021 at 05:45:35PM +0800, Ling Pei Lee wrote:
> From: Muhammad Husaini Zulkifli <[email protected]>
>
> 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
> > From: Muhammad Husaini Zulkifli <[email protected]>
> >
> > 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 <[email protected]>
> > >
> > > 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