[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZafXQS1_4fHpEzL0@ninjato>
Date: Wed, 17 Jan 2024 14:33:53 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Francesco Dolcini <francesco@...cini.it>
Cc: linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org,
Francesco Dolcini <francesco.dolcini@...adex.com>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] net: phy: micrel: reset KSZ9x31 when resuming
Hi Francesco,
> - Philippe, email address is no longer valid.
OK, thanks for the heads up.
> Therefore is not straightforward to provide valuable feedback to you
> now.
Thanks for answering anyhow.
> > +static int ksz9x31_resume(struct phy_device *phydev)
> > +{
> > + phy_device_reset(phydev, 1);
> > + phy_device_reset(phydev, 0);
>
> Is something like that fine?
> Don't we need to reconfigure the ethernet phy completely on resume
> if we do reset it? kszphy_config_reset() is taking care of something,
> but I think that the phy being reset on resume is not handled
> correctly.
If the interface is up before suspending, then suspend will assert the
reset-line. If the interface is disabled before suspending, then close
will assert the reset line. Deassertion will happen on resume/open.
So, unless I am overlooking something, my code does not really add
something new. It only makes sure that the reset line always gets
asserted before deasserting. Because in the case that the interface has
never been up before, there is no instance which could assert reset. Or,
at least, I could not find one.
Makes sense? Tests work fine here, at least.
All the best,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists