On Mon, May 02, 2022 at 08:24:53PM +0200, Andrew Lunn wrote:

quoted

writing to this register could trigger a FEC_ENET_MII interrupt actually
creating a race condition with fec_enet_mdio_read() that is called on
link change also.

Another point to consider:

static int fec_enet_mdio_wait(struct fec_enet_private *fep)
{
        uint ievent;
        int ret;

        ret = readl_poll_timeout_atomic(fep->hwp + FEC_IEVENT, ievent,
                                        ievent & FEC_ENET_MII, 2, 30000);

        if (!ret)
                writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);

        return ret;
}

An unexpected interrupt will make this exit too early, and the read
will get invalid data. An unexpected interrupt would not cause a
timeout here, which is what you are reporting.

yes, I had the exact same thought. Could it be that this creates some
kind of misalignments between the MDIO data and the related FEC
interrupt with the first early exist not triggering any error and the
second one triggering an infinite wait?

I guess I need to sleep on this, in the meantime I have a test running
with the change I described running since a couple of hours.

Francesco