From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Wei Fang <wei.fang@nxp.com>, Marek Vasut <marex@denx.de>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, Eric Dumazet <edumazet@google.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
kernel@pengutronix.de, linux-clk@vger.kernel.org,
Stephen Boyd <sboyd@kernel.org>,
Michael Turquette <mturquette@baylibre.com>
Subject: Re: [PATCH] net: phy: at803x: Improve hibernation support on start up
Date: Wed, 9 Aug 2023 09:43:49 +0100 [thread overview]
Message-ID: <ZNNRxY4z7HroDurv@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230809060836.GA13300@pengutronix.de>
On Wed, Aug 09, 2023 at 08:08:36AM +0200, Oleksij Rempel wrote:
> If fully functional external clock provider is need to initialize the
> MAC, just disabling this clock on already initialized HW without doing
> proper re-initialization sequence is usually bad idea. HW may get some
> glitch which will make troubleshooting a pain.
There are cases where the PHY sits on a MDIO bus that is created
by the ethernet MAC driver, which means the PHY only exists during
the ethernet MAC driver probe.
I think that provided the clock is only obtained after we know the
PHY is present, that would probably be fine - but doing it before
the MDIO bus has been created will of course cause problems.
We've had these issues before with stmmac, so this "stmmac needs the
PHY receive clock" is nothing new - it's had problems with system
suspend/resume in the past, and I've made suggestions... and when
there's been two people trying to work on it, I've attempted to get
them to talk to each other which resulted in nothing further
happening.
Another solution could possibly be that we reserve bit 30 on the
PHY dev_flags to indicate that the receive clock must always be
provided. I suspect that would have an advantage in another
situation - for EEE, there's a control bit which allows the
receive clock to be stopped while the link is in low-power state.
If the MAC always needs the receive clock, then obviously that
should be blocked.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-08-09 8:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 17:58 [PATCH] net: phy: at803x: Improve hibernation support on start up Marek Vasut
2023-08-08 8:44 ` Wei Fang
2023-08-08 18:37 ` Marek Vasut
2023-08-09 2:27 ` Wei Fang
2023-08-09 4:36 ` Oleksij Rempel
2023-08-09 5:37 ` Wei Fang
2023-08-09 6:08 ` Oleksij Rempel
2023-08-09 8:43 ` Russell King (Oracle) [this message]
2023-08-10 10:30 ` Russell King (Oracle)
2023-12-14 8:13 ` Romain Gantois
2023-12-14 10:46 ` Marek Vasut
2023-12-14 16:49 ` Russell King (Oracle)
2023-12-15 8:22 ` Romain Gantois
2023-08-10 3:28 ` Wei Fang
2023-08-10 9:08 ` Russell King (Oracle)
2023-08-09 13:40 ` Andrew Lunn
2023-08-09 21:34 ` Marek Vasut
2023-08-09 22:06 ` Andrew Lunn
2023-08-10 0:49 ` Marek Vasut
2023-08-10 4:32 ` Oleksij Rempel
2023-08-10 10:10 ` Russell King (Oracle)
2023-08-10 10:01 ` Russell King (Oracle)
2023-08-10 10:34 ` Russell King (Oracle)
2023-08-10 12:51 ` Oleksij Rempel
2023-08-10 13:16 ` Russell King (Oracle)
2023-08-10 13:49 ` Andrew Lunn
2023-08-10 13:54 ` Russell King (Oracle)
2023-08-10 14:23 ` Andrew Lunn
2023-08-10 14:36 ` Russell King (Oracle)
2023-08-09 23:15 ` Russell King (Oracle)
2023-08-10 10:34 ` Russell King (Oracle)
2023-08-10 3:38 ` Wei Fang
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=ZNNRxY4z7HroDurv@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=marex@denx.de \
--cc=mturquette@baylibre.com \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=sboyd@kernel.org \
--cc=wei.fang@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).