On 26/02/2025 11:37, Russell King (Oracle) wrote:
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.
I have tested these patches on Tegra186, Tegra194 and Tegra234 that they
are all working fine.
Thanks
Jon
--
nvpublic
