[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z779FzlWTwbbKW1s@shell.armlinux.org.uk>
Date: Wed, 26 Feb 2025 11:37:59 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
Bryan Whitehead <bryan.whitehead@...rochip.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
Marcin Wojtas <marcin.s.wojtas@...il.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org,
Paolo Abeni <pabeni@...hat.com>, UNGLinuxDriver@...rochip.com,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH net-next 9/9] net: stmmac: convert to phylink managed EEE
support
On Wed, Feb 26, 2025 at 10:11:58AM +0000, Jon Hunter wrote:
> On 26/02/2025 10:02, Russell King (Oracle) wrote:
> > The patch above was something of a hack, bypassing the layering, so I
> > would like to consider how this should be done properly.
> >
> > I'm still wondering whether the early call to phylink_resume() is
> > symptomatic of this same issue, or whether there is a PHY that needs
> > phy_start() to be called to output its clock even with link down that
> > we don't know about.
> >
> > The phylink_resume() call is relevant to this because I'd like to put:
> >
> > phy_eee_rx_clock_stop(priv->dev->phydev,
> > priv->phylink_config.eee_rx_clk_stop_enable);
> >
> > in there to ensure that the PHY is correctly configured for clock-stop,
> > but given stmmac's placement that wouldn't work.
> >
> > I'm then thinking of phylink_pre_resume() to disable the EEE clock-stop
> > at the PHY.
> >
> > I think the only thing we could do is try solving this problem as per
> > above and see what the fall-out from it is. I don't get the impression
> > that stmmac users are particularly active at testing patches though, so
> > it may take months to get breakage reports.
>
>
> We can ask Furong to test as he seems to active and making changes, but
> otherwise I am not sure how well it is being tested across various devices.
> On the other hand, it feels like there are still lingering issues like this
> with the driver and so I would hope this is moving in the right direction.
>
> Let me know if you have a patch you want me to test and I will run in on our
> Tegra186, Tegra194 and Tegra234 devices that all use this.
The attached patches shows what I'm thinking of - it's just been roughed
out, and only been build tested.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
View attachment "0001-net-phylink-add-config-of-PHY-receive-clock-stop-in-.patch" of type "text/x-diff" (1723 bytes)
View attachment "0002-net-phylink-add-phylink_prepare_resume.patch" of type "text/x-diff" (2365 bytes)
View attachment "0003-net-stmmac-move-phylink_resume-after-resume-setup-is.patch" of type "text/x-diff" (1800 bytes)
View attachment "0004-net-stmmac-simplify-calls-to-phylink_suspend-and-phy.patch" of type "text/x-diff" (2370 bytes)
View attachment "0005-net-stmmac-call-phylink_prepare_resume.patch" of type "text/x-diff" (1474 bytes)
Powered by blists - more mailing lists