From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: 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
Date: Wed, 17 Jan 2024 14:33:53 +0100 [thread overview]
Message-ID: <ZafXQS1_4fHpEzL0@ninjato> (raw)
In-Reply-To: <20240109232838.GA3626@francesco-nb>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-17 13:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 20:52 [RFC PATCH] net: phy: micrel: reset KSZ9x31 when resuming Wolfram Sang
2024-01-09 21:04 ` Andrew Lunn
2024-01-17 13:59 ` Wolfram Sang
2024-01-09 23:28 ` Francesco Dolcini
2024-01-17 13:33 ` Wolfram Sang [this message]
2024-02-06 17:26 ` Francesco Dolcini
2024-02-06 17:57 ` Andrew Lunn
2024-02-06 19:09 ` Francesco Dolcini
2024-02-06 19:19 ` Andrew Lunn
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=ZafXQS1_4fHpEzL0@ninjato \
--to=wsa+renesas@sang-engineering.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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