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/
