Hi Andy,

On 22/10/20 7:04 pm, Andy Duan wrote:
From: Greg Ungerer <g...@linux-m68k.org> Sent: Thursday, October 22, 2020 9:14 
AM
Hi Andrew,

On 21/10/20 11:37 pm, Andrew Lunn wrote:
+    if (fep->quirks & FEC_QUIRK_CLEAR_SETUP_MII) {
+            /* Clear MMFR to avoid to generate MII event by writing
MSCR.
+             * MII event generation condition:
+             * - writing MSCR:
+             *      - mmfr[31:0]_not_zero & mscr[7:0]_is_zero &
+             *        mscr_reg_data_in[7:0] != 0
+             * - writing MMFR:
+             *      - mscr[7:0]_not_zero
+             */
+            writel(0, fep->hwp + FEC_MII_DATA);
+    }

Hi Greg

The last time we discussed this, we decided that if you cannot do the
quirk, you need to wait around for an MDIO interrupt, e.g. call
fec_enet_mdio_wait() after setting FEC_MII_SPEED register.


      writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);

The code following this is:

          writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);

          /* Clear any pending transaction complete indication */
          writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);


So this is forcing a clear of the event here. Is that not good enough?

For me on my ColdFire test target I always get a timeout if I wait for a
FEC_IEVENT after the FEC_MII_SPEED write.

Regards
Greg

Dave Karr's last patch can fix the issue, but it may introduce 30ms delay 
during boot.
Greg's patch is to add quirk flag to distinguish platform before clearing mmfr 
operation,
which also can fix the issue.

Do you mean that we can use either fix - and that is ok for all hardware types?

Regards
Greg

Reply via email to