[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8143134-1df9-d3bc-8ce7-79cb71148d49@linux-m68k.org>
Date: Tue, 20 Oct 2020 12:14:04 +1000
From: Greg Ungerer <gerg@...ux-m68k.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Chris Heally <cphealy@...il.com>, netdev@...r.kernel.org,
Fugang Duan <fugang.duan@....com>
Subject: Re: [PATCH] net: ethernet: fec: Replace interrupt driven MDIO with
polled IO
Hi Andrew,
Commit f166f890c8f0 ("[PATCH] net: ethernet: fec: Replace interrupt
driven MDIO with polled IO") breaks the FEC driver on at least one of
the ColdFire platforms (the 5208). Maybe others, that is all I have
tested on so far.
Specifically the driver no longer finds any PHY devices when it probes
the MDIO bus at kernel start time.
I have pinned the problem down to this one specific change in this commit:
> @@ -2143,8 +2142,21 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> if (suppress_preamble)
> fep->phy_speed |= BIT(7);
>
> + /* 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);
At least by removing this I get the old behavior back and everything
works as it did before.
With that write of the FEC_MII_DATA register in place it seems that
subsequent MDIO operations return immediately (that is FEC_IEVENT is
set) - even though it is obvious the MDIO transaction has not completed yet.
Any ideas?
Regards
Greg
Powered by blists - more mailing lists