From: Florian Fainelli <email@example.com> To: Andrew Lunn <firstname.lastname@example.org>, email@example.com Cc: Heiner Kallweit <firstname.lastname@example.org>, "David S . Miller" <email@example.com>, Russell King <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option still enabled Date: Wed, 7 Jul 2021 19:48:39 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YOZTmfvVTj9eoemail@example.com> On 7/7/2021 6:23 PM, Andrew Lunn wrote: > On Thu, Jul 08, 2021 at 08:42:53AM +0800, firstname.lastname@example.org wrote: >> From: Mohammad Athari Bin Ismail <email@example.com> >> >> 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. -- Florian
next prev parent reply other threads:[~2021-07-08 2:48 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 [this message] 2021-07-08 10:10 ` Ismail, Mohammad Athari 2021-07-08 16:41 ` Florian Fainelli 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option still enabled' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).