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 request

I 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.

On Fri, Apr 29, 2022 at 10:31:05AM -0300, Fabio Estevam wrote:

Hi Tom,

On Fri, Apr 29, 2022 at 9:44 AM Tom Rini trini@konsulko.com wrote:

...

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.

Great, care to send a patch to U-Boot that aligns this cubox dts with upstream?

I do have a preliminary patch that syncs all imx6dl/q dts with upstream.

I haven't submitted it yet, as it needs lots of careful manual inspection, especially with the alias nodes.

Still want to submit it, but it is not a trivial one due to the high chances of boot regressions.

I'd rather test your overall sync because I assume based on doing other resyncs before it'll end up pulling in a lot of other dts files.