[patch 0/4] [TULIP] Tulip updates

[patch 0/4] [TULIP] Tulip updates

[Valerie Henson]

This patch set includes a fix for Lite-on from Guido Classen, some
minor debugging/typo fixes, and a long-need rev to the version (the
last time this was done was 2002!).

-VAL

--

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

[Valerie Henson]

[-- Attachment #1: tulip-fix-for-lite-on --]
[-- Type: text/plain, Size: 3702 bytes --]

From: Guido Classen <classeng@clagi.de>

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 <val_henson@linux.intel.com>
Cc: Guido Classen <classeng@clagi.de>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Cc: Jeff Garzik <jeff@garzik.org>

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

--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -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:
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/media.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/media.c
@@ -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;

--

[patch 2/4] [TULIP] Quiet down tulip_stop_rxtx

[Valerie Henson]

[-- Attachment #1: tulip-quiet-stop-rxtx --]
[-- Type: text/plain, Size: 914 bytes --]

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 <val_henson@linux.intel.com>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Cc: Jeff Garzik <jeff@garzik.org>

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

--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip.h
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip.h
@@ -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),

--

[patch 3/4] [TULIP] Fix SytemError typo

[Valerie Henson]

[-- Attachment #1: tulip-system-error-typo --]
[-- Type: text/plain, Size: 1815 bytes --]

Fix an annoying typo - SytemError -> SystemError

Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Cc: Jeff Garzik <jeff@garzik.org>

---
 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(-)

--- tulip-2.6-mm-linux.orig/drivers/net/tulip/interrupt.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/interrupt.c
@@ -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);
 
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip.h
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip.h
@@ -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,
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/winbond-840.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/winbond-840.c
@@ -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);
 

--

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

[Valerie Henson]

[-- Attachment #1: tulip-rev-version --]
[-- Type: text/plain, Size: 751 bytes --]

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

Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Cc: Jeff Garzik <jeff@garzik.org>

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

--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -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>

--

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

[Pekka Enberg]

Hi,

On 3/12/07, Valerie Henson <val_henson@linux.intel.com> wrote:
> --- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
> +++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
> @@ -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"

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

                                      Pekka

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

[Jeff Garzik]

Pekka Enberg wrote:
> Hi,
> 
> On 3/12/07, Valerie Henson <val_henson@linux.intel.com> wrote:
>> --- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
>> +++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
>> @@ -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"
> 
> 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

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

[Andy Gospodarek]

On Mon, Mar 12, 2007 at 10:07:33AM -0400, Jeff Garzik wrote:
> Pekka Enberg wrote:
> >Hi,
> >
> >On 3/12/07, Valerie Henson <val_henson@linux.intel.com> wrote:
> >>--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
> >>+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
> >>@@ -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"
> >
> >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.
> 

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....

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

[Mikael Pettersson]

Valerie Henson writes:
 > From: Guido Classen <classeng@clagi.de>
 > 
 > 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]

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