From: Steven Scholz <steven.scholz@imc-berlin.de>
To: Tom Rini <trini@kernel.crashing.org>,
Linuxppc-Embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: was: FEC on MPC860T & race condition
Date: Tue, 04 Feb 2003 17:14:08 +0100 [thread overview]
Message-ID: <3E3FE6D0.1010600@imc-berlin.de> (raw)
In-Reply-To: 20030204160401.GA30936@ip68-0-152-218.tc.ph.cox.net
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
I wrote:
>>I just hab a look at arch/ppc/8xx_io/fec.c in the recent linuxppc_2_4 and
>>could find this problem fixed! The MII irq is still requested very early
>>without waiting for the PHY to discovered!
Damn it!!! Stupid fingers.
I meant to write "could NOT find this problem fixed" !
> So linuxppc_2_4 has a partial fix then is what you're saying? Around
> what lines? I'm interested to see why _devel doesn't have this.
So IHMO there is neither in recent linuxppc_2_4_devel nor in linuxppc_2_4 a fix
for the mentioned problem.
I'll attach my patch. It is not configurable since I think it won't break anything.
If you need or wish something like CONFIG_FEC_FIX_RACE or
CONFIG_FEC_LATE_ENABLE_PHY I could do that!
Regards,
Steven
[-- Attachment #2: fec8xx_fix_race.patch --]
[-- Type: text/plain, Size: 2447 bytes --]
Index: arch/ppc/8xx_io/fec.c
===================================================================
RCS file: /home/cvsroot/linuxppc_2_4_denx/arch/ppc/8xx_io/fec.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fec.c
--- arch/ppc/8xx_io/fec.c 15 Dec 2002 05:06:41 -0000 1.1.1.1
+++ arch/ppc/8xx_io/fec.c 31 Jan 2003 14:55:18 -0000
@@ -33,6 +33,10 @@
*
* Added code for Multicast support, Frederic Goddeeris, Paul Geerinckx
* Copyright (c) 2002 Siemens Atea
+ *
+ * Fix compiler warning: changed type of mem_addr
+ * Fix to avoid race condition: wait until PHY is discovered
+ * before requesting the MII irq
*/
#include <linux/config.h>
@@ -2032,7 +2036,7 @@
struct fec_enet_private *fep;
int i, j, k;
unsigned char *eap, *iap, *ba;
- unsigned long mem_addr;
+ dma_addr_t mem_addr;
volatile cbd_t *bdp;
cbd_t *cbd_base;
volatile immap_t *immap;
@@ -2172,17 +2176,6 @@
*((uint *) RPX_CSR_ADDR) &= ~BCSR2_FETHLEDMODE;
#endif /* CONFIG_RPXCLASSIC */
-#ifdef CONFIG_USE_MDIO
-# ifndef PHY_INTERRUPT
-# error Want to use MII, but PHY_INTERRUPT not defined!
-# endif
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel |=
- (0x80000000 >> PHY_INTERRUPT);
-
- if (request_8xxirq(PHY_INTERRUPT, mii_link_interrupt, 0, "mii", dev) != 0)
- panic("Could not allocate MII IRQ!");
-#endif /* CONFIG_USE_MDIO */
-
dev->base_addr = (unsigned long)fecp;
dev->priv = fep;
@@ -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 found the following lines in a post from yhkim@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
+ if (request_8xxirq(PHY_INTERRUPT, mii_link_interrupt, 0, "mii", dev) != 0)
+ panic("Could not allocate MII IRQ!");
+
+ ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel |=
+ (0x80000000 >> PHY_INTERRUPT);
+#endif /* CONFIG_USE_MDIO */
return 0;
}
next prev parent reply other threads:[~2003-02-04 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-30 17:05 was: FEC on MPC860T & race condition Steven Scholz
2003-01-30 20:22 ` Dan Malek
2003-01-31 9:16 ` Steven Scholz
2003-02-03 21:09 ` Tom Rini
2003-02-04 8:39 ` Steven Scholz
2003-02-04 16:04 ` Tom Rini
2003-02-04 16:14 ` Steven Scholz [this message]
2003-02-04 19:32 ` Tom Rini
2003-02-04 19:55 ` Dan Malek
2003-02-07 7:35 ` Steven Scholz
2003-02-07 7:37 ` Steven Scholz
2003-02-07 17:12 ` Tom Rini
2003-02-07 17:15 ` Steven Scholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E3FE6D0.1010600@imc-berlin.de \
--to=steven.scholz@imc-berlin.de \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=trini@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.