linux-kernel - 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]

Date:   Wed, 7 Jul 2021 19:48:39 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, 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.
-- 
Florian