* [patch 1/6] [TULIP] From: Jim Gifford <maillist@jg555.com>, Grant Grundler <grundler@parisc-linux.org>, Peter Horton <pdh@colonel-panic.org>
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-15 15:20 ` Jeff Garzik
2007-03-12 9:31 ` [patch 2/6] [TULIP] From: Thibaut VARENE <T-Bone@parisc-linux.org> Valerie Henson
` (8 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm; +Cc: netdev, Valerie Henson, Jeff Garzik
[-- Attachment #1: tulip-fix-for-64-bit-mips.patch --]
[-- Type: text/plain, Size: 2633 bytes --]
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: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
---
drivers/net/tulip/media.c | 22 ++++++++++++++++++++--
drivers/net/tulip/tulip.h | 7 +++++--
2 files changed, 25 insertions(+), 4 deletions(-)
diff -puN drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips drivers/net/tulip/media.c
--- a/drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips
+++ a/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;
diff -puN drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips drivers/net/tulip/tulip.h
--- a/drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips
+++ a/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));
}
}
_
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 1/6] [TULIP] From: Jim Gifford <maillist@jg555.com>, Grant Grundler <grundler@parisc-linux.org>, Peter Horton <pdh@colonel-panic.org>
2007-03-12 9:31 ` [patch 1/6] [TULIP] From: Jim Gifford <maillist@jg555.com>, Grant Grundler <grundler@parisc-linux.org>, Peter Horton <pdh@colonel-panic.org> Valerie Henson
@ 2007-03-15 15:20 ` Jeff Garzik
0 siblings, 0 replies; 21+ messages in thread
From: Jeff Garzik @ 2007-03-15 15:20 UTC (permalink / raw)
To: Valerie Henson; +Cc: akpm, netdev, Jeff Garzik
Valerie Henson wrote:
> 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: Valerie Henson <val_henson@linux.intel.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Cc: Jeff Garzik <jgarzik@pobox.com>
> ---
>
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [patch 2/6] [TULIP] From: Thibaut VARENE <T-Bone@parisc-linux.org>
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
2007-03-12 9:31 ` [patch 1/6] [TULIP] From: Jim Gifford <maillist@jg555.com>, Grant Grundler <grundler@parisc-linux.org>, Peter Horton <pdh@colonel-panic.org> Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-12 9:31 ` [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
` (7 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm
Cc: netdev, Thibaut VARENE, Jeff Garzik, Grant Grundler,
Valerie Henson
[-- Attachment #1: tulip-natsemi-dp83840a-phy-fix.patch --]
[-- Type: text/plain, Size: 1863 bytes --]
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 <varenet@parisc-linux.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/tulip/media.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff -puN drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix drivers/net/tulip/media.c
--- a/drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix
+++ a/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;
_
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
2007-03-12 9:31 ` [patch 1/6] [TULIP] From: Jim Gifford <maillist@jg555.com>, Grant Grundler <grundler@parisc-linux.org>, Peter Horton <pdh@colonel-panic.org> Valerie Henson
2007-03-12 9:31 ` [patch 2/6] [TULIP] From: Thibaut VARENE <T-Bone@parisc-linux.org> Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-15 15:21 ` Jeff Garzik
2007-03-12 9:31 ` [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx Valerie Henson
` (6 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm; +Cc: netdev, Val Henson, Guido Classen, Grant Grundler
[-- Attachment #1: tulip-fix-for-lite-on --]
[-- Type: text/plain, Size: 3686 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(-)
--- pristine-linux.orig/drivers/net/tulip/tulip_core.c
+++ pristine-linux/drivers/net/tulip/tulip_core.c
@@ -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:
--- pristine-linux.orig/drivers/net/tulip/media.c
+++ pristine-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;
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC
2007-03-12 9:31 ` [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
@ 2007-03-15 15:21 ` Jeff Garzik
0 siblings, 0 replies; 21+ messages in thread
From: Jeff Garzik @ 2007-03-15 15:21 UTC (permalink / raw)
To: Valerie Henson; +Cc: akpm, netdev, Guido Classen, Grant Grundler
Valerie Henson wrote:
> 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(-)
Seems sane, but now on HOLD while it's being discussed
^ permalink raw reply [flat|nested] 21+ messages in thread
* [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (2 preceding siblings ...)
2007-03-12 9:31 ` [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-15 15:25 ` Jeff Garzik
2007-03-12 9:31 ` [patch 5/6] [TULIP] Fix SytemError typo Valerie Henson
` (5 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm; +Cc: netdev, Val Henson, Grant Grundler
[-- Attachment #1: tulip-quiet-stop-rxtx --]
[-- Type: text/plain, Size: 905 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 file changed, 1 insertion(+), 1 deletion(-)
--- pristine-linux.orig/drivers/net/tulip/tulip.h
+++ pristine-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),
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
2007-03-12 9:31 ` [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx Valerie Henson
@ 2007-03-15 15:25 ` Jeff Garzik
2007-03-16 0:10 ` Valerie Henson
2007-03-17 19:05 ` Grant Grundler
0 siblings, 2 replies; 21+ messages in thread
From: Jeff Garzik @ 2007-03-15 15:25 UTC (permalink / raw)
To: Valerie Henson; +Cc: akpm, netdev, Grant Grundler
Valerie Henson wrote:
> 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 file changed, 1 insertion(+), 1 deletion(-)
>
> --- pristine-linux.orig/drivers/net/tulip/tulip.h
> +++ pristine-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),
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
2007-03-15 15:25 ` Jeff Garzik
@ 2007-03-16 0:10 ` Valerie Henson
2007-03-17 19:05 ` Grant Grundler
1 sibling, 0 replies; 21+ messages in thread
From: Valerie Henson @ 2007-03-16 0:10 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, netdev, Grant Grundler
On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote:
>
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
2007-03-15 15:25 ` Jeff Garzik
2007-03-16 0:10 ` Valerie Henson
@ 2007-03-17 19:05 ` Grant Grundler
1 sibling, 0 replies; 21+ messages in thread
From: Grant Grundler @ 2007-03-17 19:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Valerie Henson, akpm, netdev, Grant Grundler
On Thu, Mar 15, 2007 at 11:25:10AM -0400, Jeff Garzik wrote:
...
> 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.
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [patch 5/6] [TULIP] Fix SytemError typo
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (3 preceding siblings ...)
2007-03-12 9:31 ` [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-15 15:29 ` Jeff Garzik
2007-03-12 9:31 ` [patch 6/6] [TULIP] Rev tulip version Valerie Henson
` (4 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm; +Cc: netdev, Valerie Henson
[-- Attachment #1: tulip-system-error-typo --]
[-- Type: text/plain, Size: 1791 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(-)
--- pristine-linux.orig/drivers/net/tulip/interrupt.c
+++ pristine-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);
--- pristine-linux.orig/drivers/net/tulip/tulip.h
+++ pristine-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,
--- pristine-linux.orig/drivers/net/tulip/winbond-840.c
+++ pristine-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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 5/6] [TULIP] Fix SytemError typo
2007-03-12 9:31 ` [patch 5/6] [TULIP] Fix SytemError typo Valerie Henson
@ 2007-03-15 15:29 ` Jeff Garzik
0 siblings, 0 replies; 21+ messages in thread
From: Jeff Garzik @ 2007-03-15 15:29 UTC (permalink / raw)
To: Valerie Henson; +Cc: akpm, netdev
Valerie Henson wrote:
> 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(-)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [patch 6/6] [TULIP] Rev tulip version
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (4 preceding siblings ...)
2007-03-12 9:31 ` [patch 5/6] [TULIP] Fix SytemError typo Valerie Henson
@ 2007-03-12 9:31 ` Valerie Henson
2007-03-12 9:59 ` [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
` (3 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:31 UTC (permalink / raw)
To: Jeff Garzik, akpm; +Cc: netdev, Valerie Henson
[-- Attachment #1: tulip-rev-version --]
[-- Type: text/plain, Size: 743 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(-)
--- pristine-linux.orig/drivers/net/tulip/tulip_core.c
+++ pristine-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>
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (5 preceding siblings ...)
2007-03-12 9:31 ` [patch 6/6] [TULIP] Rev tulip version Valerie Henson
@ 2007-03-12 9:59 ` Valerie Henson
2007-03-15 12:40 ` Mikael Pettersson
2007-03-12 9:59 ` [patch 2/4] [TULIP] Quiet down tulip_stop_rxtx Valerie Henson
` (2 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:59 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Val Henson, Guido Classen, Grant Grundler, Jeff Garzik
[-- 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;
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC
2007-03-12 9:59 ` [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
@ 2007-03-15 12:40 ` Mikael Pettersson
0 siblings, 0 replies; 21+ messages in thread
From: Mikael Pettersson @ 2007-03-15 12:40 UTC (permalink / raw)
To: Valerie Henson
Cc: linux-kernel, netdev, Guido Classen, Grant Grundler, Jeff Garzik
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [patch 2/4] [TULIP] Quiet down tulip_stop_rxtx
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (6 preceding siblings ...)
2007-03-12 9:59 ` [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC Valerie Henson
@ 2007-03-12 9:59 ` Valerie Henson
2007-03-12 9:59 ` [patch 3/4] [TULIP] Fix SytemError typo Valerie Henson
2007-03-12 9:59 ` [patch 4/4] [TULIP] Rev tulip version Valerie Henson
9 siblings, 0 replies; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:59 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: Val Henson, Grant Grundler, Jeff Garzik
[-- 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),
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [patch 3/4] [TULIP] Fix SytemError typo
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (7 preceding siblings ...)
2007-03-12 9:59 ` [patch 2/4] [TULIP] Quiet down tulip_stop_rxtx Valerie Henson
@ 2007-03-12 9:59 ` Valerie Henson
2007-03-12 9:59 ` [patch 4/4] [TULIP] Rev tulip version Valerie Henson
9 siblings, 0 replies; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:59 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: Valerie Henson, Jeff Garzik
[-- 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);
--
^ permalink raw reply [flat|nested] 21+ messages in thread* [patch 4/4] [TULIP] Rev tulip version
2007-03-12 9:59 [patch 0/4] [TULIP] Tulip updates Valerie Henson
` (8 preceding siblings ...)
2007-03-12 9:59 ` [patch 3/4] [TULIP] Fix SytemError typo Valerie Henson
@ 2007-03-12 9:59 ` Valerie Henson
2007-03-12 10:44 ` Pekka Enberg
9 siblings, 1 reply; 21+ messages in thread
From: Valerie Henson @ 2007-03-12 9:59 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: Valerie Henson, Jeff Garzik
[-- 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>
--
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 4/4] [TULIP] Rev tulip version
2007-03-12 9:59 ` [patch 4/4] [TULIP] Rev tulip version Valerie Henson
@ 2007-03-12 10:44 ` Pekka Enberg
2007-03-12 14:07 ` Jeff Garzik
0 siblings, 1 reply; 21+ messages in thread
From: Pekka Enberg @ 2007-03-12 10:44 UTC (permalink / raw)
To: Valerie Henson; +Cc: linux-kernel, netdev, Jeff Garzik
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [patch 4/4] [TULIP] Rev tulip version
2007-03-12 10:44 ` Pekka Enberg
@ 2007-03-12 14:07 ` Jeff Garzik
2007-03-13 17:07 ` Andy Gospodarek
0 siblings, 1 reply; 21+ messages in thread
From: Jeff Garzik @ 2007-03-12 14:07 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Valerie Henson, linux-kernel, netdev
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch 4/4] [TULIP] Rev tulip version
2007-03-12 14:07 ` Jeff Garzik
@ 2007-03-13 17:07 ` Andy Gospodarek
0 siblings, 0 replies; 21+ messages in thread
From: Andy Gospodarek @ 2007-03-13 17:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Pekka Enberg, Valerie Henson, linux-kernel, netdev
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....
^ permalink raw reply [flat|nested] 21+ messages in thread