Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH net] net: phy: reconfigure PHY WOL in resume if WOL option
 still enabled
To:     Andrew Lunn <andrew@lunn.ch>, mohammad.athari.ismail@intel.com
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Russell King <linux@armlinux.org.uk>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20210708004253.6863-1-mohammad.athari.ismail@intel.com>
 <YOZTmfvVTj9eo+to@lunn.ch>
From:   Florian Fainelli <f.fainelli@gmail.com>
Message-ID: <4e159b98-ec02-33b7-862a-0e35832c3a5f@gmail.com>
Date:   Wed, 7 Jul 2021 19:48:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <YOZTmfvVTj9eo+to@lunn.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 7/7/2021 6:23 PM, Andrew Lunn wrote:
> On Thu, Jul 08, 2021 at 08:42:53AM +0800, mohammad.athari.ismail@intel.com wrote:
>> From: Mohammad Athari Bin Ismail <mohammad.athari.ismail@intel.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