[patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod

[patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod

[John W. Linville]

Some (earlier?) versions of the 3c905(B) card get confused and refuse to
work again after the 3c59x module is removed (even after reloading the
module).  Changing vortex_remove_one() to allow the auto-initialize
state machine logic to be reset when the module is removed alleviates
this problem.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
--- 
See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133388 for more
details.

If anyone can suggest a better way to fix this problem, please do so.
I'll be happy to pursue it.

 drivers/net/3c59x.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

This patch should apply (with a little fuzz) to 2.4 as well...

--- linux-2.6/drivers/net/3c59x.c.orig
+++ linux-2.6/drivers/net/3c59x.c
@@ -3162,7 +3162,7 @@ static void __devexit vortex_remove_one 
 			pci_restore_state(VORTEX_PCI(vp), vp->power_state);
 	}
 	/* Should really use issue_and_wait() here */
-	outw(TotalReset|0x14, dev->base_addr + EL3_CMD);
+	outw(TotalReset|0x04, dev->base_addr + EL3_CMD);
 
 	pci_free_consistent(pdev,
 						sizeof(struct boom_rx_desc) * RX_RING_SIZE

Re: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod

[Donald Becker]

On Tue, 28 Sep 2004, John W. Linville wrote:

> Date: Tue, 28 Sep 2004 14:54:55 -0400
> From: John W. Linville <linville@tuxdriver.com>
> To: akpm@osdl.org
> Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org
> Subject: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod
> 
> Some (earlier?) versions of the 3c905(B) card get confused and refuse to
> work again after the 3c59x module is removed (even after reloading the
> module).  Changing vortex_remove_one() to allow the auto-initialize
> state machine logic to be reset when the module is removed alleviates
> this problem.

...and creates a new problem: resetting the link causes operational
problems on many networks.  The most obvious example is spanning tree
detection delays on switches, where the switch does not pass traffic.

This 3c59x.c code was changed in 2001 to mask the transceiver reset and
shut the chip down cleanly.  This occurred in two steps, with a
discussion on the vortex mailing list for each.
3c59x.c:v0.99Uc 12/5/2001
3c59x.c:v0.99T 7/16/2001
The December change was noted as specifically for the 3c905B.

The correct solution is to reset the transceiver (and thus cause
re-autonegotiation) only if a problem is detected, not an unconditional
or proactive reset.

> --- linux-2.6/drivers/net/3c59x.c.orig
> +++ linux-2.6/drivers/net/3c59x.c
> @@ -3162,7 +3162,7 @@ static void __devexit vortex_remove_one 
>  			pci_restore_state(VORTEX_PCI(vp), vp->power_state);
>  	}
>  	/* Should really use issue_and_wait() here */
> -	outw(TotalReset|0x14, dev->base_addr + EL3_CMD);
> +	outw(TotalReset|0x04, dev->base_addr + EL3_CMD);
>  



-- 
Donald Becker				becker@scyld.com
Scyld Software	 			Scyld Beowulf cluster systems
914 Bay Ridge Road, Suite 220		www.scyld.com
Annapolis MD 21403			410-990-9993

Re: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod

[John W. Linville]

On Wed, Sep 29, 2004 at 01:16:01PM -0400, Donald Becker wrote:

> This 3c59x.c code was changed in 2001 to mask the transceiver reset and
> shut the chip down cleanly.  This occurred in two steps, with a
> discussion on the vortex mailing list for each.
> 3c59x.c:v0.99Uc 12/5/2001
> 3c59x.c:v0.99T 7/16/2001
> The December change was noted as specifically for the 3c905B.

Don,

I'm having trouble finding the discussions you referenced.  I think I
found the discussion related to the v0.99T change in the vortex-bug
archives, but I never did find the discussion for the v0.99Uc in either
the vortex or vortex-bug archives (or any of the other lists that looked
to possibly be related).  Since you seem to have already found them,
would you mind sending me a more precise link?  Thanks!

Also, how can I look at the version history for the 3c59x.c that you
maintain?  Is it in CVS (or BK or something similar) where I may access
it?

> > module).  Changing vortex_remove_one() to allow the auto-initialize
> > state machine logic to be reset when the module is removed alleviates
> > this problem.
> 
> ...and creates a new problem: resetting the link causes operational
> problems on many networks.  The most obvious example is spanning tree
> detection delays on switches, where the switch does not pass traffic.

To be clear, were you looking at the version of the patch I posted on
the netdev list?  Or the version in Red Hat's Bugzilla?  In the bugzilla
patch, I had none of the bits masked, while in the netdev patch I left
the networkReset bit masked.

Does allowing the aismReset to occur cause the link to go down?  I guess
I presumed that was what the networkReset bit was there to prevent.

Even if the link does go down, is that really such a bit deal on an
rmmod?  I can see wanting to avoid it on a normal close, but an rmmod
would seem like a more rare event.

> The correct solution is to reset the transceiver (and thus cause
> re-autonegotiation) only if a problem is detected, not an unconditional
> or proactive reset.

The reset is already there, I was just letting it do more.  The cards
that have this problem just don't come back w/o this reset.

There is a TxReset that occurs on the transmit underrun condition.  Are
you suggesting that a TotalReset should occur instead?

John

P.S.  The current state of the reset at rmmod seems to have come in the
2.4.9 timeframe.  Prior to that, FWIW all but one card left the aismReset
bit unmasked just as in my patch.
-- 
John W. Linville
linville@tuxdriver.com

Re: [patch 2.6.9-rc2] 3c59x: do not mask reset of aism logic at rmmod

[John W. Linville]

Bad form to reply to oneself, but someone needs to... :-)

Jeff/Andrew/Don,

Long message follows -- basically, I'm 100% convinced that at least
certain cards covered by the 3c59x driver need to have the aismReset
bit unmasked in the TotalReset command.

I'm looking for some advice as to how to rework my patch in order for it
to be accepted.  I enumerate a few possible variations.

For details, see below...

On Thu, Sep 30, 2004 at 09:14:07AM -0400, John W. Linville wrote:
> On Wed, Sep 29, 2004 at 01:16:01PM -0400, Donald Becker wrote:
> 
> > > module).  Changing vortex_remove_one() to allow the auto-initialize
> > > state machine logic to be reset when the module is removed alleviates
> > > this problem.
> > 
> > ...and creates a new problem: resetting the link causes operational
> > problems on many networks.  The most obvious example is spanning tree
> > detection delays on switches, where the switch does not pass traffic.

> Does allowing the aismReset to occur cause the link to go down?  I guess
> I presumed that was what the networkReset bit was there to prevent.

It appears that aismReset does not cause the link to go down.

Here is the setup I used to test this:

	 "domestic"                "partner"
	+---------+               +---------+
	|         |eth2       eth1|         |
	|  3c905  |<------------->| ns83820 |
	|         |               |         |
	+---------+               +---------+

The ns83820 driver gets an interrupt on link state changes.  For the
test, the ns83820 driver was modified to log those interrupts to the
system console.  To verify that was working, the link was reset w/ this
command on "domestic":

	mii-tool -r eth2

As expected, this resulted in entries in /var/log/messages on "partner"
immediately after every time the command was issued.

Next, I applied my patch to un-mask the aismReset bit in the TotalReset
command during rmmod of the 3c59x driver (handling the 3c905).  To test
this, I executed the following series of comands on "domestic":

	ifconfig eth2 0.0.0.0 down
	modprobe -r 3c59x
	ifup 3c59x

I repeated the sequence many times, and /var/log/messages on "partner"
showed none of the link status interrupts.  This indicates that
unmasking aismReset does NOT result in resetting the link.

> Even if the link does go down, is that really such a bit deal on an
> rmmod?  I can see wanting to avoid it on a normal close, but an rmmod
> would seem like a more rare event.

BTW, I still think the above is a good point...

> P.S.  The current state of the reset at rmmod seems to have come in the
> 2.4.9 timeframe.  Prior to that, FWIW all but one card left the aismReset
> bit unmasked just as in my patch.

Which brings me to "how do we want to fix this?"  I think there are (at
least) three options:

	-- apply (some version) of the patch I submitted a few days ago;
	-- add a flag to the drv_flags field to indicate which cards need
	   the aismReset bit to be unmasked; or,
	-- key the reset off the IS_BOOMERANG filed of the drv_flags field.

The first option is the cleanest, althought I think it would be most
prudent to reimplent the patch to reinstate the EEPROM_NORESET flag that
was eliminited in version LK1.1.16 of the driver.  The testing I
described above would suggest that the aismReset bit is not related to
the "reset the interface logic on open/close/rmmod" changes that were
also added in that revision.

The second version would be a lot like the old EEPROM_NORESET field in
reverse -- only cards w/ the flag would get the aismReset flag unmasked.
This is the most flexible in case it turns-out that multiple card
variations have this problem.

The third version is what my gut tells me we need, but I don't have
enough card variations to be sure that all/only Boomerang cards are
prone to this problem.  It would be less flexible than the second
version if it turned-out the some Boomerang cards don't have the problem
or if some Cyclone cards do, etc.

I've done a lot of searching for references to this problem, and none of
them go back further than 2.4.9, which is when the aismReset bit first
started getting masked at rmmod (for all cards but one).  I'm sure that
at least certain cards (e.g. the 3c905) NEED this fix, and it seems to be
safe to make it.  I'm looking for some guidance on how to fix this problem
in a way that makes people comfortable.

I appreciate your attention and response!

John
-- 
John W. Linville
linville@tuxdriver.com

[patch 2.6.9-rc3] 3c59x: reload EEPROM values at rmmod for needy cards

[John W. Linville]

Enable reload of EEPROM values in reset at rmmod for cards that need
it, similar to old EEPROM_NORESET flag but in reverse.

Signed-of-by: John W. Linville <linville@tuxdriver.com>
---
(Most?) 3c905 and (some?) 3c905B cards need an additional bit unmasked
in the reset at rmmod or else they don't get reinitialized properly when
the driver is reloaded.

 drivers/net/3c59x.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

I didn't get any guidance on which way to go, so I decided to try the
version which I thought would be least offensive and see if it gets
shot-down... :-)

--- linux-2.6/drivers/net/3c59x.c.orig
+++ linux-2.6/drivers/net/3c59x.c
@@ -416,7 +416,7 @@ enum {	IS_VORTEX=1, IS_BOOMERANG=2, IS_C
 	HAS_PWR_CTRL=0x20, HAS_MII=0x40, HAS_NWAY=0x80, HAS_CB_FNS=0x100,
 	INVERT_MII_PWR=0x200, INVERT_LED_PWR=0x400, MAX_COLLISION_RESET=0x800,
 	EEPROM_OFFSET=0x1000, HAS_HWCKSM=0x2000, WNO_XCVR_PWR=0x4000,
-	EXTRA_PREAMBLE=0x8000, };
+	EXTRA_PREAMBLE=0x8000, EEPROM_RESET=0x10000, };
 
 enum vortex_chips {
 	CH_3C590 = 0,
@@ -504,16 +504,16 @@ static struct vortex_chip_info {
 	{"3c900B-FL Cyclone 10base-FL",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
 	{"3c905 Boomerang 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII, 64, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905 Boomerang 100baseT4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII, 64, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905B Cyclone 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
 
 	{"3c905B Cyclone 10/100/BNC",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EEPROM_RESET, 128, },
 	{"3c905B-FX Cyclone 100baseFx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM|EEPROM_RESET, 128, },
 	{"3c905C Tornado",
 	PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM (ATI Radeon 9100 IGP)",
@@ -564,7 +564,7 @@ static struct vortex_chip_info {
 	{"3c982 Hydra Dual Port B",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_HWCKSM|HAS_NWAY, 128, },
 	{"3c905B-T4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
 	{"3c920B-EMB-WNM Tornado",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM, 128, },
 
@@ -3169,7 +3169,8 @@ static void __devexit vortex_remove_one 
 			pci_restore_state(VORTEX_PCI(vp), vp->power_state);
 	}
 	/* Should really use issue_and_wait() here */
-	outw(TotalReset|0x14, dev->base_addr + EL3_CMD);
+	outw(TotalReset | ((vp->drv_flags & EEPROM_RESET) ? 0x04 : 0x14),
+	     dev->base_addr + EL3_CMD);
 
 	pci_free_consistent(pdev,
 						sizeof(struct boom_rx_desc) * RX_RING_SIZE

[patch 2.4.28-pre3] 3c59x: reload EEPROM values at rmmod for needy cards

[John W. Linville]

Enable reload of EEPROM values in reset at rmmod for cards that need
it, similar to old EEPROM_NORESET flag but in reverse.

Signed-of-by: John W. Linville <linville@tuxdriver.com>
---
(Most?) 3c905 and (some?) 3c905B cards need an additional bit unmasked
in the reset at rmmod or else they don't get reinitialized properly when
the driver is reloaded.

 drivers/net/3c59x.c |   17 +++++++++--------
 1 files changed, 9 insertions(+), 8 deletions(-)

Please note that this depends on the "3c59x: resync with 2.6" patch
which I posted earlier today.

--- linux-2.4/drivers/net/3c59x.c.orig
+++ linux-2.4/drivers/net/3c59x.c
@@ -413,7 +413,7 @@ enum {	IS_VORTEX=1, IS_BOOMERANG=2, IS_C
 	HAS_PWR_CTRL=0x20, HAS_MII=0x40, HAS_NWAY=0x80, HAS_CB_FNS=0x100,
 	INVERT_MII_PWR=0x200, INVERT_LED_PWR=0x400, MAX_COLLISION_RESET=0x800,
 	EEPROM_OFFSET=0x1000, HAS_HWCKSM=0x2000, WNO_XCVR_PWR=0x4000,
-	EXTRA_PREAMBLE=0x8000, };
+	EXTRA_PREAMBLE=0x8000, EEPROM_RESET=0x10000, };
 
 enum vortex_chips {
 	CH_3C590 = 0,
@@ -502,16 +502,16 @@ static struct vortex_chip_info {
 	{"3c900B-FL Cyclone 10base-FL",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
 	{"3c905 Boomerang 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII, 64, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905 Boomerang 100baseT4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII, 64, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905B Cyclone 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
 
 	{"3c905B Cyclone 10/100/BNC",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EEPROM_RESET, 128, },
 	{"3c905B-FX Cyclone 100baseFx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM|EEPROM_RESET, 128, },
 	{"3c905C Tornado",
 	PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM (ATI Radeon 9100 IGP)",
@@ -562,7 +562,7 @@ static struct vortex_chip_info {
 	{"3c982 Hydra Dual Port B",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_HWCKSM|HAS_NWAY, 128, },
 	{"3c905B-T4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
 	{"3c920B-EMB-WNM Tornado",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM, 128, },
 
@@ -3091,7 +3091,8 @@ static void __devexit vortex_remove_one 
 			pci_restore_state(VORTEX_PCI(vp), vp->power_state);
 	}
 	/* Should really use issue_and_wait() here */
-	outw(TotalReset|0x14, dev->base_addr + EL3_CMD);
+	outw(TotalReset | ((vp->drv_flags & EEPROM_RESET) ? 0x04 : 0x14),
+	     dev->base_addr + EL3_CMD);
 
 	pci_free_consistent(pdev,
 						sizeof(struct boom_rx_desc) * RX_RING_SIZE

Re: [patch 2.6.9-rc3] 3c59x: reload EEPROM values at rmmod for needy cards

[Jeff Garzik]

John W. Linville wrote:
> Enable reload of EEPROM values in reset at rmmod for cards that need
> it, similar to old EEPROM_NORESET flag but in reverse.
> 
> Signed-of-by: John W. Linville <linville@tuxdriver.com>

Andrew... ack/nak?

Seems OK to me, provided that it chills out in -mm for a while for 
people to test.

	Jeff

Re: [patch 2.6.9-rc3] 3c59x: reload EEPROM values at rmmod for needy cards

[Andrew Morton]

Jeff Garzik <jgarzik@pobox.com> wrote:
>
> John W. Linville wrote:
>  > Enable reload of EEPROM values in reset at rmmod for cards that need
>  > it, similar to old EEPROM_NORESET flag but in reverse.
>  > 
>  > Signed-of-by: John W. Linville <linville@tuxdriver.com>
> 
>  Andrew... ack/nak?

I queued it up.

>  Seems OK to me, provided that it chills out in -mm for a while for 
>  people to test.

Yes, it takes some time for problems in this area to be shaken out.

[patch 2.6.9-rc2] 3c59x: remove EEPROM_RESET for 3c905B

[John W. Linville]

Remove the EEPROM_RESET flag for the 3c905B cards.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Looks like I over-reached.  Apparently only the 3c905 cards actually
need the EEPROM reset, and the 3c905B cards don't like it...

 drivers/net/3c59x.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6/drivers/net/3c59x.c.orig	2004-10-17 10:53:38.142281232 -0400
+++ linux-2.6/drivers/net/3c59x.c	2004-10-17 10:54:25.975009552 -0400
@@ -508,12 +508,12 @@ static struct vortex_chip_info {
 	{"3c905 Boomerang 100baseT4",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905B Cyclone 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 
 	{"3c905B Cyclone 10/100/BNC",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM, 128, },
 	{"3c905B-FX Cyclone 100baseFx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
 	{"3c905C Tornado",
 	PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM (ATI Radeon 9100 IGP)",
@@ -564,7 +564,7 @@ static struct vortex_chip_info {
 	{"3c982 Hydra Dual Port B",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_HWCKSM|HAS_NWAY, 128, },
 	{"3c905B-T4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM Tornado",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM, 128, },
 
-- 
John W. Linville
linville@tuxdriver.com

[patch 2.4.28-pre3] 3c59x: remove EEPROM_RESET for 3c905B

[John W. Linville]

Remove the EEPROM_RESET flag for the 3c905B cards.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Looks like I over-reached.  Apparently only the 3c905 cards actually
need the EEPROM reset, and the 3c905B cards don't like it...

(Virtually identical to the 2.6 patch posted previously...)

 drivers/net/3c59x.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.4/drivers/net/3c59x.c.orig	2004-10-17 11:11:01.023739152 -0400
+++ linux-2.4/drivers/net/3c59x.c	2004-10-17 11:11:24.834119424 -0400
@@ -506,12 +506,12 @@ static struct vortex_chip_info {
 	{"3c905 Boomerang 100baseT4",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_BOOMERANG|HAS_MII|EEPROM_RESET, 64, },
 	{"3c905B Cyclone 100baseTx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 
 	{"3c905B Cyclone 10/100/BNC",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM, 128, },
 	{"3c905B-FX Cyclone 100baseFx",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_HWCKSM, 128, },
 	{"3c905C Tornado",
 	PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM (ATI Radeon 9100 IGP)",
@@ -562,7 +562,7 @@ static struct vortex_chip_info {
 	{"3c982 Hydra Dual Port B",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_HWCKSM|HAS_NWAY, 128, },
 	{"3c905B-T4",
-	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE|EEPROM_RESET, 128, },
+	 PCI_USES_IO|PCI_USES_MASTER, IS_CYCLONE|HAS_NWAY|HAS_HWCKSM|EXTRA_PREAMBLE, 128, },
 	{"3c920B-EMB-WNM Tornado",
 	 PCI_USES_IO|PCI_USES_MASTER, IS_TORNADO|HAS_NWAY|HAS_HWCKSM, 128, },
 
-- 
John W. Linville
linville@tuxdriver.com