linux-kernel - Re: [PATCH net-next v1 1/1] net: usb: asix: ax88772: suspend PHY on driver probe

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 for Android: free password hash cracker in your pocket

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

Message-ID: <53535272-c28f-092a-f068-87253da4013c@gmail.com>
Date:   Sat, 3 Jul 2021 14:34:21 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Russell King <linux@...linux.org.uk>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        kernel@...gutronix.de, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 1/1] net: usb: asix: ax88772: suspend PHY on
 driver probe

On 02.07.2021 05:53, Oleksij Rempel wrote:
> On Thu, Jul 01, 2021 at 12:01:04PM -0700, Florian Fainelli wrote:
>> On 6/28/21 9:43 PM, Oleksij Rempel wrote:
>>> After probe/bind sequence is the PHY in active state, even if interface
>>> is stopped. As result, on some systems like Samsung Exynos5250 SoC based Arndale
>>> board, the ASIX PHY will be able to negotiate the link but fail to
>>> transmit the data.
>>>
>>> To handle it, suspend the PHY on probe.
>>
>> Very unusual, could not the PHY be attached/connected to a ndo_open()
>> time like what most drivers do?
> 
> May be this can be done to.
> But, should not the PHY be in the same state after phy_connect() and after
> phy_stop()?
> 
> Currently, phy_connect() and phy_start() resume the PHY. The phy_stop()
> is suspending it. Since the driver calls phy_connect(), phy_start() and
> phy_stop(), the resume/suspend state is out of balance.

At least currently there is no requirement that phy_resume()/phy_suspend()
calls have to be balanced. Drivers must be able to deal with this.
However phy_suspend() checks the state of phydev->suspended and skips the
suspend callback if set.

> In case some one will add for example something like regulator_enable/disable
> callbacks in to phydev->syspend/resume callbacks, this would never work.
> 
> So, the question is, should phy_connect() put the PHY back in to suspend
> mode? Or should the MAC driver take care of this?
> 
>>>
>>> Fixes: e532a096be0e ("net: usb: asix: ax88772: add phylib support")
>>> Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
>>> Reported-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>> Tested-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>> ---
>>>  drivers/net/usb/asix_devices.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
>>> index aec97b021a73..2c115216420a 100644
>>> --- a/drivers/net/usb/asix_devices.c
>>> +++ b/drivers/net/usb/asix_devices.c
>>> @@ -701,6 +701,7 @@ static int ax88772_init_phy(struct usbnet *dev)
>>>  		return ret;
>>>  	}
>>>  
>>> +	phy_suspend(priv->phydev);
>>>  	priv->phydev->mac_managed_pm = 1;
>>>  
>>>  	phy_attached_info(priv->phydev);
>>>
>>
>>
>> -- 
>> Florian
>>
> 
> Regards,
> Oleksij
>