On Thu, Apr 28, 2022 at 02:25:03PM -0700, Tim Harvey wrote:
On Thu, Apr 28, 2022 at 1:41 PM Tom Rini trini@konsulko.com wrote:
Hey,
So my mx6cuboxi was out of my lab for a bit, and that's how this regression got in mainline. With: 4223fb0ee18d11462c55ac94198fdc2055f2c27c is the first bad commit commit 4223fb0ee18d11462c55ac94198fdc2055f2c27c Author: Tim Harvey tharvey@gateworks.com Date: Tue Mar 1 12:15:01 2022 -0800
net: fec: prevent undesired de-assertion of phy-reset on requestI now see: => dhcp ethernet@2188000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@2188000 BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16
Any ideas? Thanks!
Tom,
What PHY is used on that board and can you verify the PHY reset is properly defined in the dt polarity and all?
What I found is that before commit 4223fb0ee18d11 ("net: fec: prevent undesired de-assertion of phy-reset on request") my board's (imx8mm-venice-gw73xx) PHY_RST would driver high during the gpio-request before it was driven low then high again. The PHY used on my board (at least new revisions) is the MaxLinear GPY111 and we it was extremely sensitive to multiple reset events and this behavior would make it unreliable.
Thanks for the hint, Tim! Fabio, the dts needs to be re-synced with Linux as upstream it says: /* * The PHY seems to require a long-enough reset duration to avoid * some rare issues where the PHY gets stuck in an inconsistent and * non-functional state at boot-up. 10ms proved to be fine . */ phy-reset-duration = <10>;
But we have this set to 2, and indeed bumping it up to 10 to match fixes the network tests for me.