Tulip updates

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/media.c      |   31 +++++++++++++++++++++++++++----
 drivers/net/tulip/tulip_core.c |    4 ++--
 2 files changed, 29 insertions(+), 6 deletions(-)

drivers/net/tulip/tulip_core.c +2 -2

@@ -1701,8 +1701,8 @@ static int __devinit tulip_init_one (str
 			tp->nwayset = 0;
 			iowrite32(csr6_ttm | csr6_ca, ioaddr + CSR6);
 			iowrite32(0x30, ioaddr + CSR12);
-			iowrite32(0x0001F078, ioaddr + CSR6);
-			iowrite32(0x0201F078, ioaddr + CSR6); /* Turn on autonegotiation. */
+			iowrite32(0x0001F078, ioaddr + 0xB8);
+			iowrite32(0x0201F078, ioaddr + 0xB8); /* Turn on autonegotiation. */
 		}
 		break;
 	case MX98713:

drivers/net/tulip/media.c +27 -4

@@ -76,8 +76,20 @@ int tulip_mdio_read(struct net_device *d
 		ioread32(ioaddr + 0xA0);
 		while (--i > 0) {
 			barrier();
-			if ( ! ((retval = ioread32(ioaddr + 0xA0)) & 0x80000000))
-				break;
+			if ( ! ((retval = ioread32(ioaddr + 0xA0))
+                                & 0x80000000)) {
+				/*
+				 * Possible bug in 82c168 rev 17 -
+                                 * sometimes bit 31 is unstable and
+                                 * clears before actually finished.
+                                 * Delay and check if bit 31 is still
+                                 * cleared before believing it.
+				 */
+                                udelay(10);
+                                if ( ! ((retval = ioread32(ioaddr + 0xA0))
+                                        & 0x80000000))
+                                        break;
+                        }
 		}
 		spin_unlock_irqrestore(&tp->mii_lock, flags);
 		return retval & 0xffff;

@@ -136,8 +148,19 @@ void tulip_mdio_write(struct net_device 
 		iowrite32(cmd, ioaddr + 0xA0);
 		do {
 			barrier();
-			if ( ! (ioread32(ioaddr + 0xA0) & 0x80000000))
-				break;
+			if ( ! (ioread32(ioaddr + 0xA0) & 0x80000000)) {
+				/*
+				 * Possible bug in 82c168 rev 17 -
+                                 * sometimes bit 31 is unstable and
+                                 * clears before actually finished.
+                                 * Delay and check if bit 31 is still
+                                 * cleared before believing it.
+				 */
+                                udelay(10);
+                                if ( ! (ioread32(ioaddr + 0xA0)
+                                        & 0x80000000))
+                                        break;
+                        }
 		} while (--i > 0);
 		spin_unlock_irqrestore(&tp->mii_lock, flags);
 		return;

Mikael Pettersson

2007-03-15 13:00 UTC #2 lore raw

Re: [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC

Quoted 12 lines · Valerie Henson

From: Guido Classen <[email protected]>
This small patch fixes two issues with the Lite-On 82c168 PNIC adapters. I've tested it with two cards in different machines both chip rev 17
The first is the wrong register address CSR6 for writing the MII register which instead is 0xB8 (this may get a symbol too?) (see similar exisiting code at line 437) in tulip_core.c
[Double-checked by Val Henson; yes, 0xB8 is correct register for autonegotiate on this card.]

Quoted 7 lines

At least by my cards, the the bit 31 from the MII register seems to be somewhat unstable. This results in reading wrong values from the Phy-Registers und prevents the card from correct initialization. I've added a litte delay and an second test of the bit. If the bit is stil cleared the read/write process has definitely finished.
[Original patch slightly massaged by Val Henson]

Your patch doesn't test for rev 17, so it affects all 82c168 chips.

First, I've been using a rev 32 82c168 for years now in a News server that's up 24/7, without any issues.

Second, I'm now testing your patch on my rev 32 chip, and so far it seems to not have caused any regressions.

Just FYI.

/Mikael

Valerie Henson

author

2007-03-12 09:59 UTC #3 lore raw

PATCH 2/4 Quiet down tulip_stop_rxtx

Only print out debugging info for tulip_stop_rxtx if debug is on. Many cards (including at least two of my own) fail to stop properly during initialization according to this test with no apparent ill effects. Worse, it tends to spam logs when the driver doesn't work.

Signed-off-by Val Henson <[email protected]>

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/tulip.h |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

drivers/net/tulip/tulip.h +1 -1

@@ -481,7 +481,7 @@ static inline void tulip_stop_rxtx(struc
 		while (--i && (ioread32(ioaddr + CSR5) & (CSR5_TS|CSR5_RS)))
 			udelay(10);
 
-		if (!i)
+		if (!i && (tulip_debug > 1))
 			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
 					" (CSR5 0x%x CSR6 0x%x)\n",
 					pci_name(tp->pdev),

Valerie Henson

author

2007-03-12 09:59 UTC #4 lore raw

PATCH 3/4 Fix SytemError typo

Fix an annoying typo - SytemError -> SystemError

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/interrupt.c   |    4 ++--
 drivers/net/tulip/tulip.h       |    2 +-
 drivers/net/tulip/winbond-840.c |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

drivers/net/tulip/interrupt.c +2 -2

@@ -675,7 +675,7 @@ irqreturn_t tulip_interrupt(int irq, voi
 				if (tp->link_change)
 					(tp->link_change)(dev, csr5);
 			}
-			if (csr5 & SytemError) {
+			if (csr5 & SystemError) {
 				int error = (csr5 >> 23) & 7;
 				/* oops, we hit a PCI error.  The code produced corresponds
 				 * to the reason:

@@ -745,7 +745,7 @@ irqreturn_t tulip_interrupt(int irq, voi
 			  TxFIFOUnderflow |
 			  TxJabber |
 			  TPLnkFail |
-			  SytemError )) != 0);
+			  SystemError )) != 0);
 #else
 	} while ((csr5 & (NormalIntr|AbnormalIntr)) != 0);

drivers/net/tulip/tulip.h +1 -1

@@ -132,7 +132,7 @@ enum pci_cfg_driver_reg {
 /* The bits in the CSR5 status registers, mostly interrupt sources. */
 enum status_bits {
 	TimerInt = 0x800,
-	SytemError = 0x2000,
+	SystemError = 0x2000,
 	TPLnkFail = 0x1000,
 	TPLnkPass = 0x10,
 	NormalIntr = 0x10000,

drivers/net/tulip/winbond-840.c +1 -1

@@ -1148,7 +1148,7 @@ static irqreturn_t intr_handler(int irq,
 		}
 
 		/* Abnormal error summary/uncommon events handlers. */
-		if (intr_status & (AbnormalIntr | TxFIFOUnderflow | SytemError |
+		if (intr_status & (AbnormalIntr | TxFIFOUnderflow | SystemError |
 						   TimerInt | TxDied))
 			netdev_error(dev, intr_status);

Valerie Henson

author

2007-03-12 09:59 UTC #5 lore raw

PATCH 4/4 Rev tulip version

Rev tulip version... things have changed since 2002!

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/tulip_core.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/net/tulip/tulip_core.c +3 -3

@@ -17,11 +17,11 @@
 
 #define DRV_NAME	"tulip"
 #ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION    "1.1.14-NAPI" /* Keep at least for test */
+#define DRV_VERSION    "1.1.15-NAPI" /* Keep at least for test */
 #else
-#define DRV_VERSION	"1.1.14"
+#define DRV_VERSION	"1.1.15"
 #endif
-#define DRV_RELDATE	"May 11, 2002"
+#define DRV_RELDATE	"Feb 27, 2007"
 
 
 #include <linux/module.h>

Pekka Enberg

2007-03-12 10:44 UTC #6 lore raw

Re: [patch 4/4] [TULIP] Rev tulip version

Hi,

Quoted 4 lines · Valerie Henson

drivers/net/tulip/tulip_core.c +0 -0
@@ -17,11 +17,11 @@
 

drivers/net/tulip/tulip_core.c line 24

Quoted 10 lines

drivers/net/tulip/tulip_core.c +3 -3

 #define DRV_NAME       "tulip"
 #ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION    "1.1.14-NAPI" /* Keep at least for test */
+#define DRV_VERSION    "1.1.15-NAPI" /* Keep at least for test */
 #else
-#define DRV_VERSION    "1.1.14"
+#define DRV_VERSION    "1.1.15"
 #endif
-#define DRV_RELDATE    "May 11, 2002"
+#define DRV_RELDATE    "Feb 27, 2007"

Why not just drop this? What purpose does a per-module revision have for in-kernel drivers anyway?

Pekka

Jeff Garzik

2007-03-12 14:07 UTC #7 lore raw

Re: [patch 4/4] [TULIP] Rev tulip version

Quoted 7 lines · Pekka Enberg

Hi,
Quoted 4 lines · Valerie Henson
drivers/net/tulip/tulip_core.c +0 -0
@@ -17,11 +17,11 @@
 

Quoted 13 lines

drivers/net/tulip/tulip_core.c line 24

Quoted 10 lines

drivers/net/tulip/tulip_core.c +3 -3

 #define DRV_NAME       "tulip"
 #ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION    "1.1.14-NAPI" /* Keep at least for test */
+#define DRV_VERSION    "1.1.15-NAPI" /* Keep at least for test */
 #else
-#define DRV_VERSION    "1.1.14"
+#define DRV_VERSION    "1.1.15"
 #endif
-#define DRV_RELDATE    "May 11, 2002"
+#define DRV_RELDATE    "Feb 27, 2007"

Why not just drop this? What purpose does a per-module revision have for in-kernel drivers anyway?

It's the maintainer's call. Sometimes it eases parsing bug reports, and tracking changes as your drivers get backported to various enterprise operating systems(tm). Sometimes it just gets in the way.

Jeff

Andy Gospodarek

2007-03-13 17:07 UTC #8 lore raw

Re: [patch 4/4] [TULIP] Rev tulip version

Quoted 22 lines · Jeff Garzik

Quoted 7 lines · Pekka Enberg
Hi,
Quoted 4 lines · Valerie Henson
drivers/net/tulip/tulip_core.c +0 -0
@@ -17,11 +17,11 @@
 
Quoted 13 lines
drivers/net/tulip/tulip_core.c line 24
Quoted 10 lines
drivers/net/tulip/tulip_core.c +3 -3
 #define DRV_NAME       "tulip"
 #ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION    "1.1.14-NAPI" /* Keep at least for test */
+#define DRV_VERSION    "1.1.15-NAPI" /* Keep at least for test */
 #else
-#define DRV_VERSION    "1.1.14"
+#define DRV_VERSION    "1.1.15"
 #endif
-#define DRV_RELDATE    "May 11, 2002"
+#define DRV_RELDATE    "Feb 27, 2007"
Why not just drop this? What purpose does a per-module revision have for in-kernel drivers anyway?

Quoted 4 lines

It's the maintainer's call. Sometimes it eases parsing bug reports, and tracking changes as your drivers get backported to various enterprise operating systems(tm). Sometimes it just gets in the way.

It's good to keep this type of information in drivers. I've been thinking lately that it would be nice to even expand it a little bit (maybe include the commit sum) so its easier to help those who aren't running the latest upstream kernels on their boxes....

Valerie Henson

author

2007-03-12 18:42 UTC #9 lore raw

PATCH 1/6 From: Jim Gifford <[email protected]>, Grant Grundler <[email protected]>, Peter Horton <[email protected]>

With Grant's help I was able to get the tulip driver to work with 64 bit MIPS.

[VAL: I'm happy with the 1.5 ms max delay; it doesn't seem excessive.]

Signed-off-by Andrew Morton <[email protected]>

Cc Jeff Garzik <[email protected]>

---

 drivers/net/tulip/media.c |   22 ++++++++++++++++++++--
 drivers/net/tulip/tulip.h |    7 +++++--
 2 files changed, 25 insertions(+), 4 deletions(-)

drivers/net/tulip/media.c renamed from drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips +20 -2

diff -puN drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips drivers/net/tulip/media.c
@@ -44,8 +44,10 @@ static const unsigned char comet_miireg2
 
 /* MII transceiver control section.
    Read and write the MII registers using software-generated serial
-   MDIO protocol.  See the MII specifications or DP83840A data sheet
-   for details. */
+   MDIO protocol.
+   See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management functions")
+   or DP83840A data sheet for more details.
+   */
 
 int tulip_mdio_read(struct net_device *dev, int phy_id, int location)
 {

@@ -272,13 +274,29 @@ void tulip_select_media(struct net_devic
 				int reset_length = p[2 + init_length];
 				misc_info = (u16*)(reset_sequence + reset_length);
 				if (startup) {
+					int timeout = 10;	/* max 1 ms */
 					iowrite32(mtable->csr12dir | 0x100, ioaddr + CSR12);
 					for (i = 0; i < reset_length; i++)
 						iowrite32(reset_sequence[i], ioaddr + CSR12);
+
+					/* flush posted writes */
+					ioread32(ioaddr + CSR12);
+
+					/* Sect 3.10.3 in DP83840A.pdf (p39) */
+					udelay(500);
+
+					/* Section 4.2 in DP83840A.pdf (p43) */
+					/* and IEEE 802.3 "22.2.4.1.1 Reset" */
+					while (timeout-- &&
+						(tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+						udelay(100);
 				}
 				for (i = 0; i < init_length; i++)
 					iowrite32(init_sequence[i], ioaddr + CSR12);
+
+				ioread32(ioaddr + CSR12);	/* flush posted writes */
 			}
+
 			tmp_info = get_u16(&misc_info[1]);
 			if (tmp_info)
 				tp->advertising[phy_num] = tmp_info | 1;

drivers/net/tulip/tulip.h renamed from drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips +5 -2

diff -puN drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips drivers/net/tulip/tulip.h
@@ -482,8 +482,11 @@ static inline void tulip_stop_rxtx(struc
 			udelay(10);
 
 		if (!i)
-			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed\n",
-					pci_name(tp->pdev));
+			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
+					" (CSR5 0x%x CSR6 0x%x)\n",
+					pci_name(tp->pdev),
+					ioread32(ioaddr + CSR5),
+					ioread32(ioaddr + CSR6));
 	}
 }

Jeff Garzik

2007-03-15 15:20 UTC #10 lore raw

Re: [patch 1/6] [TULIP] From: Jim Gifford <[email protected]>, Grant Grundler <[email protected]>, Peter Horton <[email protected]>

Quoted 4 lines · Valerie Henson

With Grant's help I was able to get the tulip driver to work with 64 bit MIPS.
[VAL: I'm happy with the 1.5 ms max delay; it doesn't seem excessive.]

Quoted 8 lines

Signed-off-by Valerie Henson <[email protected]>
Signed-off-by Andrew Morton <[email protected]>
Cc Jeff Garzik <[email protected]>
---
 drivers/net/tulip/media.c |   22 ++++++++++++++++++++--
 drivers/net/tulip/tulip.h |    7 +++++--
 2 files changed, 25 insertions(+), 4 deletions(-)

applied 1-2, after fixing the subject line as discussed

Valerie Henson

author

2007-03-12 18:42 UTC #11 lore raw

PATCH 2/6 From: Thibaut VARENE <[email protected]>

Fix a problem with Tulip 21142 HP branded PCI cards (PN#: B5509-66001), which feature a NatSemi DP83840A PHY.

Without that patch, it is impossible to properly initialize the card's PHY, and it's thus impossible to monitor/configure it.

[VAL: I'm happy with the 1.5 ms max delay; it doesn't seem excessive.]

Signed-off-by Thibaut VARENE <[email protected]>

Cc Jeff Garzik <[email protected]>

Acked-by Grant Grundler <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

---

 drivers/net/tulip/media.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

drivers/net/tulip/media.c renamed from drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix +17 -1

diff -puN drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix drivers/net/tulip/media.c
@@ -263,11 +263,27 @@ void tulip_select_media(struct net_devic
 				u16 *reset_sequence = &((u16*)(p+3))[init_length];
 				int reset_length = p[2 + init_length*2];
 				misc_info = reset_sequence + reset_length;
-				if (startup)
+				if (startup) {
+					int timeout = 10;	/* max 1 ms */
 					for (i = 0; i < reset_length; i++)
 						iowrite32(get_u16(&reset_sequence[i]) << 16, ioaddr + CSR15);
+
+					/* flush posted writes */
+					ioread32(ioaddr + CSR15);
+
+					/* Sect 3.10.3 in DP83840A.pdf (p39) */
+					udelay(500);
+
+					/* Section 4.2 in DP83840A.pdf (p43) */
+					/* and IEEE 802.3 "22.2.4.1.1 Reset" */
+					while (timeout-- &&
+						(tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+						udelay(100);
+				}
 				for (i = 0; i < init_length; i++)
 					iowrite32(get_u16(&init_sequence[i]) << 16, ioaddr + CSR15);
+
+				ioread32(ioaddr + CSR15);	/* flush posted writes */
 			} else {
 				u8 *init_sequence = p + 2;
 				u8 *reset_sequence = p + 3 + init_length;

Valerie Henson

author

2007-03-12 18:42 UTC #12 lore raw

PATCH 3/6 fix for Lite-On 82c168 PNIC

From: Guido Classen <[email protected]>

This small patch fixes two issues with the Lite-On 82c168 PNIC adapters. I've tested it with two cards in different machines both chip rev 17

The first is the wrong register address CSR6 for writing the MII register which instead is 0xB8 (this may get a symbol too?) (see similar exisiting code at line 437) in tulip_core.c

[Double-checked by Val Henson; yes, 0xB8 is correct register for autonegotiate on this card.]

[Original patch slightly massaged by Val Henson]

Signed-off-by Val Henson <[email protected]>

Cc Guido Classen <[email protected]>

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/media.c      |   31 +++++++++++++++++++++++++++----
 drivers/net/tulip/tulip_core.c |    4 ++--
 2 files changed, 29 insertions(+), 6 deletions(-)

drivers/net/tulip/tulip_core.c +2 -2

@@ -1689,8 +1689,8 @@ static int __devinit tulip_init_one (str
 			tp->nwayset = 0;
 			iowrite32(csr6_ttm | csr6_ca, ioaddr + CSR6);
 			iowrite32(0x30, ioaddr + CSR12);
-			iowrite32(0x0001F078, ioaddr + CSR6);
-			iowrite32(0x0201F078, ioaddr + CSR6); /* Turn on autonegotiation. */
+			iowrite32(0x0001F078, ioaddr + 0xB8);
+			iowrite32(0x0201F078, ioaddr + 0xB8); /* Turn on autonegotiation. */
 		}
 		break;
 	case MX98713:

drivers/net/tulip/media.c +27 -4

@@ -76,8 +76,20 @@ int tulip_mdio_read(struct net_device *d
 		ioread32(ioaddr + 0xA0);
 		while (--i > 0) {
 			barrier();
-			if ( ! ((retval = ioread32(ioaddr + 0xA0)) & 0x80000000))
-				break;
+			if ( ! ((retval = ioread32(ioaddr + 0xA0))
+                                & 0x80000000)) {
+				/*
+				 * Possible bug in 82c168 rev 17 -
+                                 * sometimes bit 31 is unstable and
+                                 * clears before actually finished.
+                                 * Delay and check if bit 31 is still
+                                 * cleared before believing it.
+				 */
+                                udelay(10);
+                                if ( ! ((retval = ioread32(ioaddr + 0xA0))
+                                        & 0x80000000))
+                                        break;
+                        }
 		}
 		spin_unlock_irqrestore(&tp->mii_lock, flags);
 		return retval & 0xffff;

@@ -136,8 +148,19 @@ void tulip_mdio_write(struct net_device 
 		iowrite32(cmd, ioaddr + 0xA0);
 		do {
 			barrier();
-			if ( ! (ioread32(ioaddr + 0xA0) & 0x80000000))
-				break;
+			if ( ! (ioread32(ioaddr + 0xA0) & 0x80000000)) {
+				/*
+				 * Possible bug in 82c168 rev 17 -
+                                 * sometimes bit 31 is unstable and
+                                 * clears before actually finished.
+                                 * Delay and check if bit 31 is still
+                                 * cleared before believing it.
+				 */
+                                udelay(10);
+                                if ( ! (ioread32(ioaddr + 0xA0)
+                                        & 0x80000000))
+                                        break;
+                        }
 		} while (--i > 0);
 		spin_unlock_irqrestore(&tp->mii_lock, flags);
 		return;

Jeff Garzik

2007-03-15 15:21 UTC #13 lore raw

Re: [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC

Quoted 25 lines · Valerie Henson

From: Guido Classen <[email protected]>
This small patch fixes two issues with the Lite-On 82c168 PNIC adapters. I've tested it with two cards in different machines both chip rev 17
The first is the wrong register address CSR6 for writing the MII register which instead is 0xB8 (this may get a symbol too?) (see similar exisiting code at line 437) in tulip_core.c
[Double-checked by Val Henson; yes, 0xB8 is correct register for autonegotiate on this card.]
At least by my cards, the the bit 31 from the MII register seems to be somewhat unstable. This results in reading wrong values from the Phy-Registers und prevents the card from correct initialization. I've added a litte delay and an second test of the bit. If the bit is stil cleared the read/write process has definitely finished.
[Original patch slightly massaged by Val Henson]
Signed-off-by Val Henson <[email protected]>
Cc Guido Classen <[email protected]>
Signed-off-by Grant Grundler <[email protected]>
Cc Jeff Garzik <[email protected]>

Quoted 4 lines

---
 drivers/net/tulip/media.c      |   31 +++++++++++++++++++++++++++----
 drivers/net/tulip/tulip_core.c |    4 ++--
 2 files changed, 29 insertions(+), 6 deletions(-)

Seems sane, but now on HOLD while it's being discussed

Valerie Henson

author

2007-03-12 18:42 UTC #14 lore raw

PATCH 4/6 Quiet down tulip_stop_rxtx

Signed-off-by Val Henson <[email protected]>

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/tulip.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/tulip/tulip.h +1 -1

@@ -481,7 +481,7 @@ static inline void tulip_stop_rxtx(struc
 		while (--i && (ioread32(ioaddr + CSR5) & (CSR5_TS|CSR5_RS)))
 			udelay(10);
 
-		if (!i)
+		if (!i && (tulip_debug > 1))
 			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
 					" (CSR5 0x%x CSR6 0x%x)\n",
 					pci_name(tp->pdev),

Jeff Garzik

2007-03-15 15:25 UTC #15 lore raw

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

Quoted 16 lines · Valerie Henson

Only print out debugging info for tulip_stop_rxtx if debug is on. Many cards (including at least two of my own) fail to stop properly during initialization according to this test with no apparent ill effects. Worse, it tends to spam logs when the driver doesn't work.
Signed-off-by Val Henson <[email protected]>
Signed-off-by Grant Grundler <[email protected]>
Cc Jeff Garzik <[email protected]>
---
 drivers/net/tulip/tulip.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/tulip/tulip.h static inline void tulip_stop_rxtx(struc · line 487

Quoted 8 lines

drivers/net/tulip/tulip.h +1 -1

@@ -481,7 +481,7 @@ static inline void tulip_stop_rxtx(struc
 		while (--i && (ioread32(ioaddr + CSR5) & (CSR5_TS|CSR5_RS)))
 			udelay(10);
 
-		if (!i)
+		if (!i && (tulip_debug > 1))
 			printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
 					" (CSR5 0x%x CSR6 0x%x)\n",
 					pci_name(tp->pdev),

Here's the problem with this: this printk is signalling that the DMA engines have not yet stopped, which is an event of which we should be wary.

While it makes sense to do this patch, since the complaining cards appear to work anyway, we also need to take into account the times when this is not a spurious warning.

Thus, I would consider maybe adding a warning somewhere in the DMA-engine-start region of code, that complains if the DMA engines are already active, or somesuch.

Jeff

Valerie Henson

author

2007-03-16 00:10 UTC #16 lore raw

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

Quoted 11 lines · Jeff Garzik

Here's the problem with this: this printk is signalling that the DMA engines have not yet stopped, which is an event of which we should be wary.
While it makes sense to do this patch, since the complaining cards appear to work anyway, we also need to take into account the times when this is not a spurious warning.
Thus, I would consider maybe adding a warning somewhere in the DMA-engine-start region of code, that complains if the DMA engines are already active, or somesuch.

Yeah, I agree it's signifying a problem, and we should have a warning (only one) until we figure out what's going on. Put on my to-do list.

-VAL

Grant Grundler

2007-03-17 19:06 UTC #17 lore raw

Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx

In reply to Jeff Garzik

On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote:
...

Quoted 6 lines

Here's the problem with this: this printk is signalling that the DMA engines have not yet stopped, which is an event of which we should be wary.
While it makes sense to do this patch, since the complaining cards appear to work anyway, we also need to take into account the times when this is not a spurious warning.

It's certainly not spurious warning when in the "unload driver module" path. This is when the driver unmaps the control data and the particular packet it's doing DMA to.

Quoted 3 lines

Thus, I would consider maybe adding a warning somewhere in the DMA-engine-start region of code, that complains if the DMA engines are already active, or somesuch.

Sure. But also in the shutdown path where we unmap any DMA mappings.

thanks,
grant

Valerie Henson

author

2007-03-12 18:42 UTC #18 lore raw

PATCH 5/6 Fix SytemError typo

Fix an annoying typo - SytemError -> SystemError

Cc Jeff Garzik <[email protected]>

---
 drivers/net/tulip/interrupt.c   |    4 ++--
 drivers/net/tulip/tulip.h       |    2 +-
 drivers/net/tulip/winbond-840.c |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

drivers/net/tulip/interrupt.c +2 -2

@@ -675,7 +675,7 @@ irqreturn_t tulip_interrupt(int irq, voi
 				if (tp->link_change)
 					(tp->link_change)(dev, csr5);
 			}
-			if (csr5 & SytemError) {
+			if (csr5 & SystemError) {
 				int error = (csr5 >> 23) & 7;
 				/* oops, we hit a PCI error.  The code produced corresponds
 				 * to the reason:

@@ -745,7 +745,7 @@ irqreturn_t tulip_interrupt(int irq, voi
 			  TxFIFOUnderflow |
 			  TxJabber |
 			  TPLnkFail |
-			  SytemError )) != 0);
+			  SystemError )) != 0);
 #else
 	} while ((csr5 & (NormalIntr|AbnormalIntr)) != 0);

drivers/net/tulip/tulip.h +1 -1

@@ -132,7 +132,7 @@ enum pci_cfg_driver_reg {
 /* The bits in the CSR5 status registers, mostly interrupt sources. */
 enum status_bits {
 	TimerInt = 0x800,
-	SytemError = 0x2000,
+	SystemError = 0x2000,
 	TPLnkFail = 0x1000,
 	TPLnkPass = 0x10,
 	NormalIntr = 0x10000,

drivers/net/tulip/winbond-840.c +1 -1

@@ -1148,7 +1148,7 @@ static irqreturn_t intr_handler(int irq,
 		}
 
 		/* Abnormal error summary/uncommon events handlers. */
-		if (intr_status & (AbnormalIntr | TxFIFOUnderflow | SytemError |
+		if (intr_status & (AbnormalIntr | TxFIFOUnderflow | SystemError |
 						   TimerInt | TxDied))
 			netdev_error(dev, intr_status);

Jeff Garzik

2007-03-15 15:29 UTC #19 lore raw

Re: [patch 5/6] [TULIP] Fix SytemError typo

Quoted 10 lines · Valerie Henson

Fix an annoying typo - SytemError -> SystemError
Signed-off-by Valerie Henson <[email protected]>
Cc Jeff Garzik <[email protected]>
---
 drivers/net/tulip/interrupt.c   |    4 ++--
 drivers/net/tulip/tulip.h       |    2 +-
 drivers/net/tulip/winbond-840.c |    2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

applied 5-6, after fixing the subject lines.

Please note that anything in the subject line between '[' and ']', inclusive, is stripped before applying to the kernel. Thus, your '[TULIP]' identifier, which tells people which area of the kernel you are modifying, is stripped.

You want to use a subject line like

[patch 4/6] tulip: fix SytemError typo

For more info see http://linux.yyz.us/patch-format.html and Documentation/SubmittingPatches.

Jeff

Valerie Henson

author

2007-03-12 18:42 UTC #20 lore raw

PATCH 6/6 Rev tulip version

Rev tulip version... things have changed since 2002!