Tulip updates
Subsystems (2)
cover Tulip updates
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 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.]
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]
--- 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 *dioread32 (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_deviceiowrite32 (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 Quiet down tulip_stop_rxtx
In reply to Valerie HensonOnly 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.
--- 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(strucwhile (--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 Fix SytemError typo
In reply to Valerie HensonFix an annoying typo - SytemError -> SystemError
--- 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, voiif (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);
--
PATCH 4/4 Rev tulip version
In reply to Valerie HensonRev tulip version... things have changed since 2002!
--- 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>
--
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
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
PATCH 1/6 From: Jim Gifford <[email protected]>, Grant Grundler <[email protected]>, Peter Horton <[email protected]>
In reply to Valerie HensonWith 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.]
---
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
@@ -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_devicint 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
@@ -482,8 +482,11 @@ static inline void tulip_stop_rxtx(strucudelay (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 )); } }
_
--
PATCH 2/6 From: Thibaut VARENE <[email protected]>
In reply to Valerie HensonFix 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.]
---
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
@@ -263,11 +263,27 @@ void tulip_select_media(struct net_devicu16 *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;
_
--
PATCH 3/6 fix for Lite-On 82c168 PNIC
In reply to Valerie HensonFrom: 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]
--- 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 *dioread32 (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_deviceiowrite32 (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 4/6 Quiet down tulip_stop_rxtx
In reply to Valerie HensonOnly 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.
--- 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(strucwhile (--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 5/6 Fix SytemError typo
In reply to Valerie HensonFix an annoying typo - SytemError -> SystemError
--- 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, voiif (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);
--
PATCH 6/6 Rev tulip version
In reply to Valerie HensonRev tulip version... things have changed since 2002!
--- 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>
--
Re: [patch 4/4] [TULIP] Rev tulip version
In reply to Jeff GarzikQuoted 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....
Re: [patch 1/4] [TULIP] fix for Lite-On 82c168 PNIC
In reply to Valerie HensonQuoted 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) intulip_core.c[Double-checked by Val Henson; yes,
0xB8is 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
Re: [patch 1/6] [TULIP] From: Jim Gifford <[email protected]>, Grant Grundler <[email protected]>, Peter Horton <[email protected]>
In reply to Valerie HensonQuoted 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
Re: [patch 3/6] [TULIP] fix for Lite-On 82c168 PNIC
In reply to Valerie HensonQuoted 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) intulip_core.c[Double-checked by Val Henson; yes,
0xB8is 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
Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
In reply to Valerie HensonQuoted 16 lines · Valerie Henson
Only print out debugging info for
tulip_stop_rxtxif 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(strucwhile (--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
Re: [patch 5/6] [TULIP] Fix SytemError typo
In reply to Valerie HensonQuoted 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
Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
In reply to Jeff GarzikQuoted 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
Re: [patch 4/6] [TULIP] Quiet down tulip_stop_rxtx
In reply to Jeff GarzikOn 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