linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Francesco Dolcini <francesco.dolcini@toradex.com>
Cc: philippe.schenker@toradex.com, andrew@lunn.ch,
	qiangqing.zhang@nxp.com, davem@davemloft.net, festevam@gmail.com,
	kuba@kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: phy: perform a PHY reset on resume
Date: Sat, 11 Dec 2021 14:15:54 +0000	[thread overview]
Message-ID: <YbSymkxlslW2DqLW@shell.armlinux.org.uk> (raw)
In-Reply-To: <20211211130146.357794-1-francesco.dolcini@toradex.com>

On Sat, Dec 11, 2021 at 02:01:46PM +0100, Francesco Dolcini wrote:
> 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://lore.kernel.org/netdev/20211206101326.1022527-1-philippe.schenker@toradex.com/
> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.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.
> 
> ---
>  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)

I don't particularly like this - this impacts everyone who is using
phylib at this point, whereas no reset was happening if the reset was
already deasserted here.

In the opening remarks to this series, it is stated:

  If a hardware-design is able to control power to the Ethernet PHY and
  relying on software to do a reset, the PHY does no longer work after
  resuming from suspend, given the PHY does need a hardware-reset.

This requirement is conditional on the hardware design, it isn't a
universal requirement and won't apply everywhere. I think it needs to
be described in firmware that this action is required. That said...

Please check the datasheet on the PHY regarding application of power and
reset. You may find that the PHY datasheet requires the reset to be held
active from power up until the clock input is stable - this could mean
you need some other arrangement to assert the PHY reset signal after
re-applying power sooner than would happen by the proposed point in the
kernel.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2021-12-11 14:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 10:13 [RFC PATCH 0/2] Reset PHY in fec_resume if it got powered down Philippe Schenker
2021-12-06 10:13 ` [RFC PATCH 1/2] net: fec: make fec_reset_phy not only usable once Philippe Schenker
2021-12-06 13:13   ` Andrew Lunn
2021-12-06 10:13 ` [RFC PATCH 2/2] net: fec: reset phy in resume if it was powered down Philippe Schenker
2021-12-07  1:58 ` [RFC PATCH 0/2] Reset PHY in fec_resume if it got " Joakim Zhang
2021-12-10 13:51   ` Philippe Schenker
2021-12-11 13:01     ` [PATCH net-next] net: phy: perform a PHY reset on resume Francesco Dolcini
2021-12-11 14:15       ` Russell King (Oracle) [this message]
2021-12-11 14:57         ` Francesco Dolcini
2021-12-14 11:58         ` Francesco Dolcini
2021-12-13  4:40       ` Joakim Zhang
2021-12-13 10:57       ` Philippe Schenker
2021-12-13  4:39     ` [RFC PATCH 0/2] Reset PHY in fec_resume if it got powered down Joakim Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbSymkxlslW2DqLW@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=festevam@gmail.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=philippe.schenker@toradex.com \
    --cc=qiangqing.zhang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).