Received-SPF: pass (google.com: domain of linux-kernel+bounces-55369-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 6 Feb 2024 18:26:45 +0100
From: Francesco Dolcini <francesco@dolcini.it>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Francesco Dolcini <francesco@dolcini.it>,
	linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org,
	Francesco Dolcini <francesco.dolcini@toradex.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] net: phy: micrel: reset KSZ9x31 when resuming
Message-ID: <20240206172645.GA24848@francesco-nb>
References: <20240109205223.40219-1-wsa+renesas@sang-engineering.com>
 <20240109232838.GA3626@francesco-nb>
 <ZafXQS1_4fHpEzL0@ninjato>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZafXQS1_4fHpEzL0@ninjato>

On Wed, Jan 17, 2024 at 02:33:53PM +0100, Wolfram Sang wrote:
> > > +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.

What I do not know, is what happen to any configuration that was done to
the phy before.

What if you have disabled gigabit ethernet from auto negotiation before
suspend, it will be enabled again after the phy get out of reset.

Is the ethernet phy subsystem taking care of this? Ensuring that this
configuration is restored into the phy?

I was starting to debug something around this a few days ago, with the
difference that in that case the reset was asserted/de-asserted by the
hardware and the end results was not really the expected one ...

Francesco