patch-2.0.36 linux/drivers/net/eepro100.c

• Lines: 23
• Date: Sun Nov 15 10:33:02 1998
• Orig file: v2.0.35/linux/drivers/net/eepro100.c
• Orig date: Sun Nov 15 10:49:38 1998

diff -u --recursive --new-file v2.0.35/linux/drivers/net/eepro100.c linux/drivers/net/eepro100.c
@@ -41,7 +41,6 @@
 /* Maximum number of multicast addresses to filter (vs. rx-all-multicast) */
 static int multicast_filter_limit = 64;
 
-#include <linux/config.h>
 #ifdef MODULE
 #ifdef MODVERSIONS
 #include <linux/modversions.h>
@@ -182,10 +181,10 @@
 	doing the CU_RESUME
 		the chip processes the next-yet-valid post-final-command.
 So blindly sending a CU_RESUME is only safe if we do it immediately after
-after erasing the previous CmdSuspend, without the possibility of an
-intervening delay.  Thus the resume command is always within the
-interrupts-disabled region.  This is a timing dependence, but handling this
-condition in a timing-independent way would considerably complicate the code.
+erasing the previous CmdSuspend, without the possibility of an intervening
+delay.  Thus the resume command is always within the interrupts-disabled
+region.  This is a timing dependence, but handling this condition in a
+timing-independent way would considerably complicate the code.
 
 Note: In previous generation Intel chips, restarting the command unit was a
 notoriously slow process.  This is presumably no longer true.