was: FEC on MPC860T & race condition

Tom Rini trini at kernel.crashing.org
Wed Feb 5 06:32:24 EST 2003


On Tue, Feb 04, 2003 at 05:14:08PM +0100, Steven Scholz wrote:

> I'll attach my patch. It is not configurable since I think it won't break
> anything.

Okay.  Moving along the process, I have a comment:

> @@ -2285,6 +2278,39 @@
>  	fep->old_status = 0;
>  #endif	/* CONFIG_USE_MDIO */
>
> +#ifdef CONFIG_USE_MDIO
> +# ifndef PHY_INTERRUPT
> +#  error Want to use MII, but PHY_INTERRUPT not defined!
> +# endif
> +	/* before requesting the irq, we should wait until PHY is discovered
> +	 * to avoid race conditions
> +	 */
> +	while (!fep->phy_id_done) {
> +		udelay(5);
> +	}

I believe this is wrong, in that trying to udelay() here is a bad idea.
I don't have the time right now, but I suspect google, or #kernelnewbies
might be able to suggest a more appropriate way of waiting here.

Or perhaps classes have fried my mind, and this is correct.

> +	/* I found the following lines in a post from yhkim at da-san.com>
> +	 * (http://lists.linuxppc.org/linuxppc-embedded/200110/msg00206.html)
> +	 * But I am not sure if and why this is necessary.
> +	 * Enable it just to be sure, be sure ... ?
> +	 * It works for me without it.
> +	 */
> +#if 0
> +	mii_do_cmd(dev, fep->phy->ack_int);
> +	mii_do_cmd(dev, fep->phy->startup);
> +
> +	{
> +		int tmp;
> +		for (tmp = 0; tmp < 50; tmp++)
> +			udelay(5);
> +	}
> +#endif

I believe this is an attempt at waiting as well.  Kick the PHY and do
nothing until it's hopefully discovered.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





More information about the Linuxppc-embedded mailing list