archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <>
To: "Ismail, Mohammad Athari" <>,
	Andrew Lunn <>
Cc: Heiner Kallweit <>,
	"David S . Miller" <>,
	Russell King <>,
	Jakub Kicinski <>,
	"" <>,
	"" <>
Subject: Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option still enabled
Date: Thu, 8 Jul 2021 09:41:45 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 7/8/21 3:10 AM, Ismail, Mohammad Athari wrote:
>> -----Original Message-----
>> From: Florian Fainelli <>
>> Sent: Thursday, July 8, 2021 10:49 AM
>> To: Andrew Lunn <>; Ismail, Mohammad Athari
>> <>
>> Cc: Heiner Kallweit <>; David S . Miller
>> <>; Russell King <>; Jakub Kicinski
>> <>;;
>> Subject: Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL
>> option still enabled
>> On 7/7/2021 6:23 PM, Andrew Lunn wrote:
>>> On Thu, Jul 08, 2021 at 08:42:53AM +0800,
>> wrote:
>>>> From: Mohammad Athari Bin Ismail <>
>>>> When the PHY wakes up from suspend through WOL event, there is a need
>>>> to reconfigure the WOL if the WOL option still enabled. The main
>>>> operation is to clear the WOL event status. So that, subsequent WOL
>>>> event can be triggered properly.
>>>> This fix is needed especially for the PHY that operates in PHY_POLL
>>>> mode where there is no handler (such as interrupt handler) available
>>>> to clear the WOL event status.
>>> I still think this architecture is wrong.
>>> The interrupt pin is wired to the PMIC. Can the PMIC be modelled as an
>>> interrupt controller? That would allow the interrupt to be handled as
>>> normal, and would mean you don't need polling, and you don't need this
>>> hack.
>> I have to agree with Andrew here, and if the answer is that you cannot model
>> this PMIC as an interrupt controller, cannot the config_init() callback of the
>> driver acknowledge then disable the interrupts as it normally would if you were
>> cold booting the system? This would also allow you to properly account for the
>> PHY having woken-up the system.
> Hi Florian,
> Thank you for the suggestion. 
> If I understand correctly, you are suggesting to acknowledge and clear the WOL status in config_init() callback function. Am I correct?
> If yes, I did try to add a code to clear WOL status in marvell_config_init() function (we are using Marvell Alaska 88E1512). But, I found that, if the platform wake up from S3(mem) or S4(disk), the config_init() callback function is not called. As the result, WOL status not able to be cleared in config_init().
> Please advice if you any suggestion.

This is presumably that you are seeing with stmmac along with phylink?

During S3 resume you should be going back to the kernel provided
re-entry point and resume where we left (warm boot) so
mdio_bus_phy_resume() should call phy_init_hw() which calls
config_init(), have you traced if that is somehow not happening?

During S4 resume (disk), I suppose that you have to involve the boot
loader to restore the DRAM image from the storage disk, and so that does
effectively look like a quasi cold boot from the kernel? If so, that
should still lead to config_init() being called when the PHY is
attached, no?

  reply	other threads:[~2021-07-08 16:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08  0:42 mohammad.athari.ismail
2021-07-08  1:23 ` Andrew Lunn
2021-07-08  2:48   ` Florian Fainelli
2021-07-08 10:10     ` Ismail, Mohammad Athari
2021-07-08 16:41       ` Florian Fainelli [this message]
2021-07-08 23:20         ` Ismail, Mohammad Athari
2021-07-08 23:22           ` Florian Fainelli
2021-07-09  1:30             ` Andrew Lunn
2021-07-09  9:57         ` Russell King (Oracle)
2021-07-08 10:02   ` Ismail, Mohammad Athari
2021-07-08 13:11     ` Andrew Lunn
2021-07-08 23:11       ` Ismail, Mohammad Athari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option still enabled' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).