netdev - Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option still enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9871a015-bcfb-0bdb-c481-5e8f2356e5ba@gmail.com>
Date:   Thu, 8 Jul 2021 09:41:45 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Ismail, Mohammad Athari" <mohammad.athari.ismail@...el.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>,
        Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option
 still enabled

On 7/8/21 3:10 AM, Ismail, Mohammad Athari wrote:
> 
> 
>> -----Original Message-----
>> From: Florian Fainelli <f.fainelli@...il.com>
>> Sent: Thursday, July 8, 2021 10:49 AM
>> To: Andrew Lunn <andrew@...n.ch>; Ismail, Mohammad Athari
>> <mohammad.athari.ismail@...el.com>
>> Cc: Heiner Kallweit <hkallweit1@...il.com>; David S . Miller
>> <davem@...emloft.net>; Russell King <linux@...linux.org.uk>; Jakub Kicinski
>> <kuba@...nel.org>; netdev@...r.kernel.org; linux-kernel@...r.kernel.org
>> 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,
>> mohammad.athari.ismail@...el.com wrote:
>>>> From: Mohammad Athari Bin Ismail <mohammad.athari.ismail@...el.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.
> 
> 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?
-- 
Florian