3c59x: do not mask reset of aism logic at rmmod

PATCH In review John W. Linville 4 participants 10 messages Sep 28, 2004 – Oct 17, 2004

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

John W. Linville

author

2004-09-28 18:54 UTC #0 lore raw

PATCH 1/1 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.

Signed-off-by John W. Linville <[email protected]>

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

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +1 -1

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

Donald Becker

2004-09-29 17:16 UTC #1 lore raw

Quoted 11 lines · John W. Linville

Date: Tue, 28 Sep 2004 14:54:55 -0400
From: John W. Linville <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
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.

Quoted 9 lines

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +1 -1

@@ -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);

Signature · 4 lines

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

John W. Linville

author

2004-09-30 13:14 UTC #2 lore raw

Quoted 6 lines · Donald Becker

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?

Quoted 7 lines

Quoted 3 lines
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.

Quoted 3 lines

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.

Signature · 2 lines

John W. Linville
[email protected]

John W. Linville

author

2004-10-07 17:46 UTC #3 lore raw

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

Quoted 6 lines · John W. Linville

Quoted 4 lines · Donald Becker
Quoted 3 lines
module). Changing vortex_remove_one() to allow the auto-initialize state machine logic to be reset when the module is removed alleviates this problem.

Quoted 6 lines

Quoted 3 lines
...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.

Quoted 3 lines

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

Quoted 3 lines

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

Signature · 2 lines

John W. Linville
[email protected]

John W. Linville

author

2004-10-08 16:39 UTC #4 lore raw

PATCH 1/1 3c59x: reload EEPROM values at rmmod for needy cards

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 <[email protected]>

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

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +9 -8

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

Jeff Garzik

2004-10-15 19:33 UTC #5 lore raw

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

Quoted 4 lines · 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 <[email protected]>

Andrew... ack/nak?

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

Jeff

Andrew Morton

2004-10-15 21:12 UTC #6 lore raw

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

Quoted 8 lines · Jeff Garzik

Quoted 4 lines · 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 <[email protected]>
Andrew... ack/nak?

I queued it up.

Quoted 2 lines

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.

John W. Linville

author

2004-10-08 16:44 UTC #7 lore raw

PATCH 1/1 3c59x: reload EEPROM values at rmmod for needy cards

In reply to 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 <[email protected]>

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

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +9 -8

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

John W. Linville

author

2004-10-17 15:04 UTC #8 lore raw

PATCH 1/1 3c59x: remove EEPROM_RESET for 3c905B

In reply to John W. Linville

Remove the EEPROM_RESET flag for the 3c905B cards.

Signed-off-by John W. Linville <[email protected]>

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

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +4 -4

@@ -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, },

Signature · 2 lines

John W. Linville
[email protected]

John W. Linville

author

2004-10-17 15:19 UTC #9 lore raw

PATCH 1/1 3c59x: remove EEPROM_RESET for 3c905B

In reply to John W. Linville

Remove the EEPROM_RESET flag for the 3c905B cards.

Signed-off-by John W. Linville <[email protected]>

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

drivers/net/3c59x.c renamed from drivers/net/3c59x.c.orig +4 -4

@@ -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, },

Signature · 2 lines

John W. Linville
[email protected]