linux-kernel - RE: [PATCH net-next] net: phy: perform a PHY reset on resume

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: <DB8PR04MB6795CF540670BF328C637E2DE6749@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date:   Mon, 13 Dec 2021 04:40:00 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Francesco Dolcini <francesco.dolcini@...adex.com>,
        "philippe.schenker@...adex.com" <philippe.schenker@...adex.com>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "festevam@...il.com" <festevam@...il.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] net: phy: perform a PHY reset on resume


Hi Francesco,

> -----Original Message-----
> From: Francesco Dolcini <francesco.dolcini@...adex.com>
> Sent: 2021年12月11日 21:02
> To: philippe.schenker@...adex.com; andrew@...n.ch; Joakim Zhang
> <qiangqing.zhang@....com>
> Cc: davem@...emloft.net; festevam@...il.com; kuba@...nel.org;
> linux-kernel@...r.kernel.org; linux@...linux.org.uk;
> netdev@...r.kernel.org; Francesco Dolcini <francesco.dolcini@...adex.com>
> Subject: [PATCH net-next] net: phy: perform a PHY reset on resume
> 
> Perform a PHY reset in phy_init_hw() to ensure that the PHY is working after
> resume. This is required if the PHY was powered down in suspend like it is
> done by the freescale FEC driver in fec_suspend().
> 
> Link:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.k
> ernel.org%2Fnetdev%2F20211206101326.1022527-1-philippe.schenker%40tor
> adex.com%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C408
> 258b86fec4c39a1b708d9bca6755f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C637748245394278104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0&amp;sdata=m17Q5b3CZVI89xmplVVwVvCHEXZrMkY6dYIAmz2v3CE%3D&a
> mp;reserved=0
> Signed-off-by: Francesco Dolcini <francesco.dolcini@...adex.com>
> 
> ---
> 
> Philippe: what about something like that? Only compile tested, but I see no
> reason for this not solving the issue.
> 
> Any delay required on the reset can be specified using
> reset-assert-us/reset-deassert-us.

Looks fine for me. We can trigger a hardware reset first, then following a soft reset and phy
configurations, the logic seems reasonable.

Also need PHY maintainers give more comments.

Best Regards,
Joakim Zhang
> ---
>  drivers/net/phy/phy_device.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 74d8e1dc125f..7eab0c054adf 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1158,7 +1158,8 @@ int phy_init_hw(struct phy_device *phydev)  {
>  	int ret = 0;
> 
> -	/* Deassert the reset signal */
> +	/* phy reset required if the phy was powered down during suspend */
> +	phy_device_reset(phydev, 1);
>  	phy_device_reset(phydev, 0);
> 
>  	if (!phydev->drv)
> --
> 2.25.1