remove drivers/net/eepro100.c
Subsystems (2)
RFC PATCH 1/1 remove drivers/net/eepro100.c
This patch removes the obsolete drivers/net/eepro100.c driver.
Is there any reason why it should be kept?
---
MAINTAINERS | 5 drivers/net/Kconfig | 14 drivers/net/Makefile | 1 drivers/net/eepro100.c | 2412 ----------------------------------------- 4 files changed, 2432 deletions(-)
MAINTAINERS renamed from MAINTAINERS.old +0 -5
@@ -868,11 +868,6 @@ W: http://ebtables.sourceforge.net/ S: Maintained -EEPRO100 NETWORK DRIVER -P: Andrey V. Savochkin -M: [email protected] -S: Maintained - EMU10K1 SOUND DRIVER P: James Courtier-Dutton M: [email protected]
drivers/net/Kconfig renamed from drivers/net/Kconfig.old +0 -14
@@ -1405,20 +1405,6 @@ <file:Documentation/networking/net-modules.txt>. The module will be called dgrs. -config EEPRO100 - tristate "EtherExpressPro/100 support (eepro100, original Becker driver)" - depends on NET_PCI && PCI - select MII - help - If you have an Intel EtherExpress PRO/100 PCI network (Ethernet) - card, say Y and read the Ethernet-HOWTO, available from - <http://www.tldp.org/docs.html#howto>. - - To compile this driver as a module, choose M here and read - <file:Documentation/networking/net-modules.txt>. The module - will be called eepro100. - - config E100 tristate "Intel(R) PRO/100+ support" depends on NET_PCI && PCI
drivers/net/Makefile renamed from drivers/net/Makefile.old +0 -1
@@ -40,7 +40,6 @@ obj-$(CONFIG_TYPHOON) += typhoon.o obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o obj-$(CONFIG_PCNET32) += pcnet32.o -obj-$(CONFIG_EEPRO100) += eepro100.o obj-$(CONFIG_E100) += e100.o obj-$(CONFIG_TLAN) += tlan.o obj-$(CONFIG_EPIC100) += epic100.o
drivers/net/eepro100.c deleted +0 -2412
2,412 lines not on this page · raw message
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
David S. Miller
maintainerFrom: Russell King <[email protected]>
Date: Fri, 18 Nov 2005 09:01:59 +0000
Quoted 9 lines · Adrian Bunk
Quoted 3 lines
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
Yes, sadly this is still true and therefore the eepro100 driver needs to stick around.
Quoted 11 lines · Russell King
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
After reading the archives, one discovers the current status is:
waiting on ARM folks to test e100
Latest reference is public message-id <[email protected]>, which was CC'd to you.
There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback...
Jeff
Quoted 15 lines · Jeff Garzik
Quoted 11 lines · Russell King
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
After reading the archives, one discovers the current status is:
Quoted 8 lines
waiting on ARM folks to test e100
Latest reference is public message-id <[email protected]>, which was CC'd to you.
There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback...
So what you're saying is that it's down to me to test the thing.
Ok.
I've been extremely patient waiting for e100 to get fixed (it's been literally _years_), and I think it isn't surprising that the hardware it was noticed on has been packed away.
Now I ask the same of others for when I'm (a) well enough to enter the cold environment in which this machine is currently stored and
(b) can find the time to resurect the machine.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 6 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Signed-off-by Adrian Bunk <[email protected]>
Can you state a reason why it is obsolete and should be removed? IMHO this would provide a much better commit message.
Tim
Quoted 15 lines · Jeff Garzik
Quoted 11 lines · Russell King
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
After reading the archives, one discovers the current status is:
Quoted 8 lines
waiting on ARM folks to test e100
Latest reference is public message-id <[email protected]>, which was CC'd to you.
There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback...
I'mn not subscribed to netdev, and [email protected] was not Cc'ed to me, but I do now understand the status of e100/eepro100.
After all my email was just an RFC.
Quoted 1 line
Jeff
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 15 lines · Jeff Garzik
Quoted 11 lines · Russell King
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
After reading the archives, one discovers the current status is:
Quoted 8 lines
waiting on ARM folks to test e100
Latest reference is public message-id <[email protected]>, which was CC'd to you.
There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback...
Well, I've run 2.6.15-rc2 on what I think was the ARM platform which exhibited the problem, but it doesn't show up. However, that's meaningless as it has been literally _years_ (4 or more) since the problem was reported. It's rather unsurprising that I can't reproduce it - I don't even know if I'm using the right processor module!
It's far too late to try swapping modules and rebuilding everything (if I can find the code for the boot loader still.) Also since this platform is being returned to whence it came tomorrow, I lose the ability to test this.
I've been struggling all day trying to get the kernel back up and running on this hardware due to various issues with sizes of kernels and mtd/jffs2 incompatibilities with the jffs2 filesystem in flash.
So, all in all, resolving this issue has taken far too long and it is now far too late to do any kind of positive testing.
I leave it up to you how to proceed. Effectively I'm now completely out of the loop on this with no hardware to worry about. Sorry.
Finally, please don't assign any blame for this in my direction; I reported it and I kept bugging people about it, and in spite of my best efforts there was very little which was forthcoming. Obviously that wasn't enough.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
Quoted 25 lines · Russell King
Quoted 15 lines · Jeff Garzik
Quoted 11 lines · Russell King
Quoted 3 lines · Adrian Bunk
This patch removes the obsolete
drivers/net/eepro100.cdriver.Is there any reason why it should be kept?
Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists.
After reading the archives, one discovers the current status is:
Quoted 8 lines
waiting on ARM folks to test e100
Latest reference is public message-id <[email protected]>, which was CC'd to you.
There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback...
Quoted 5 lines
Well, I've run 2.6.15-rc2 on what I think was the ARM platform which exhibited the problem, but it doesn't show up. However, that's meaningless as it has been literally _years_ (4 or more) since the problem was reported. It's rather unsurprising that I can't reproduce it - I don't even know if I'm using the right processor module!
Additionally, looking back at my 30th June 2004 message, I don't think I've even managed sufficient testing to make any claim of working-ness or non-working-ness against either driver.
The test was merely a "did it successfully BOOTP" because I can't get it to mount and run /sbin/init from the jffs2 rootfs which 2.5.70 was perfectly happy to earlier today. However, the failure point seemed to be when NFS tried to use the card.
Whether that means I was or was not using BOOTP back in 2004... your guess is as good as mine.
Anyway, that's the end of the issue as far as I'm concerned.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
David S. Miller
maintainerFrom: Russell King <[email protected]>
Date: Wed, 23 Nov 2005 22:15:48 +0000
Quoted 7 lines
I leave it up to you how to proceed. Effectively I'm now completely out of the loop on this with no hardware to worry about. Sorry.
Finally, please don't assign any blame for this in my direction; I reported it and I kept bugging people about it, and in spite of my best efforts there was very little which was forthcoming. Obviously that wasn't enough.
I think you're being unreasonable.
They've worked on a fix for the problem, and now you're unable to test the fix, and you're angry at them because they took so long to code up the fix.
If you're overextended and have too much work to do and that's stressing you out, that doesn't give you permission to take it out on other people.
Quoted 6 lines · David S. Miller
From: Russell King <[email protected]>
Date: Wed, 23 Nov 2005 22:15:48 +0000Quoted 3 lines
I leave it up to you how to proceed. Effectively I'm now completely out of the loop on this with no hardware to worry about. Sorry.
Quoted 6 lines
Quoted 4 lines
Finally, please don't assign any blame for this in my direction; I reported it and I kept bugging people about it, and in spite of my best efforts there was very little which was forthcoming. Obviously that wasn't enough.
I think you're being unreasonable.
I think you're being unreasonable telling me that I'm being unreasonable.
Quoted 7 lines
They've worked on a fix for the problem, and now you're unable to test the fix, and you're angry at them because they took so long to code up the fix.
If you're overextended and have too much work to do and that's stressing you out, that doesn't give you permission to take it out on other people.
No. It's quite simple.
I've worked on trying to replicate the problem today. Tomorrow I'm out at a meeting and since I'm no longer working on the problematical hardware, it is being returned.
That means there's about 15 minutes left before I go to sleep before having to be up early tomorrow to go on a 2 hour journey to attend a meeting. What do you want me to do with those 15 minutes? Perform a miracle maybe?
David, I ask you to retract your unreasonable mail. I'm being quite calm here. I'm just pointing out the facts that as of *now* I'm no longer in a position to test.
I was rather hoping that being crystal clear about the reasons about _why_ I'm no longer able to continue participating in his problem that I would be seen not to be unreasonable.
I guess I'm just cursed.
Sorry.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core
David S. Miller
maintainerFrom: Russell King <[email protected]>
Date: Wed, 23 Nov 2005 22:53:19 +0000
Quoted 4 lines
That means there's about 15 minutes left before I go to sleep before having to be up early tomorrow to go on a 2 hour journey to attend a meeting. What do you want me to do with those 15 minutes? Perform a miracle maybe?
It's perfectly fine that you are not able to test the fix. But being so visibly angry about it, that's the part I don't get.
How about a "I'm not able to test this due to lack of access to the necessary hardware, but I did give it a try although unsuccessful. Perhaps someone else can lend a hand so we can resolve this for good?"
That's the "calm" response.
Quoted 8 lines · Russell King
Quoted 2 lines · Russell King
Well, I've run 2.6.15-rc2 on what I think was the ARM platform which exhibited the problem, but it doesn't show up.
The test was merely a "did it successfully BOOTP" because I can't get it to mount and run
/sbin/initfrom the jffs2 rootfs which 2.5.70 was perfectly happy to earlier today. However, the failure point seemed to be when NFS tried to use the card.
If you you are referring to the ARM Integrator/AP platform, I tested it earlier this year, with a 2.6.12 kernel, and the e100.c driver seemed to be OK with an NFS-mounted root filesystem and the IP address got via kernel DHCP. I had problems getting the eepro100.c driver to work though, but I didn't dig any further since e100.c seemed OK.
I'll give it another try early next week with 2.6.15-rc2 and let you know whether I see any problems.
Signature · 1 line
Catalin