Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 930d52c0 authored by David S. Miller's avatar David S. Miller
Browse files

Merge branch 'legacy-isa-delete' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux



Paul Gortmaker says:

====================
The Ethernet-HowTo was maintained for roughly 10 years, from 1993 to 2003.
Fortunately sane hardware probing and auto detection (via PCI and ISA/PnP)
largely made the document a relic of the past, hence it being abandoned
a decade ago.

However, there is one last useful thing that we can extract from the
effort made in maintaining that document.  We can use it to guide us
with respect to what rare, experimental and/or super ancient 10Mbit
ISA drivers don't make sense to maintain in-tree anymore.

Nobody will argue that ISA is obsolete.  Availability went away at about
the time Pentium3 motherboards moved from 500MHz Slot1/SECC processors
to the green 500MHz Socket 370 Pentium3 chips, at the turn of the century.

In theory, it is possible that someone could still be running one of these
12+ year old P3 machines and want 3.9+ bleeding edge kernels (but unlikely).
In light of the above (remote) possibility, we can defer the removal of some
ISA network drivers that were highly popular and well tested.  Typically
that means the stuff more from the mid to late '90s, some with ISA PnP
support, like the 3c509, the wd/SMC 8390 based stuff, PCnet/lance etc.

But a lot of other drivers, typically from the early 1990s were for rare
hardware, and experimental (to the point of requiring a cron job that would
do a test ping, and then ifconfig down/up and/or a rmmod/insmod!).  And
some of these drivers (znet, and lp486e to name two) are physically tied
to platforms with on motherboard ethernet -- of 486 machines that date
from the early 1990s and can only have single digit amounts of memory.

What I'd like to achieve here with this series, is to get rid of those old
drivers that are no longer being used.  In an earlier discussion where
I'd proposed deleting a single driver, Alan suggested we instead dump
all the historical stuff in one go, to make it "...immediately obvious
where the break point is..."[1] and that it was "perfectly reasonable it
(and a pile of other ISA cards) ought to be shown the door"[2].  So that
is the goal here - make a clear line in the sand where the really ancient
stuff finally gets kicked to the curb.

Two old parallel port drivers are considered for removal here as well,
since in early 386/486 ISA machines, the parallel port was typically found
with the UARTS on the multi-I/O ISA controller card.  These drivers also date
from the early 1990's; parallel ports are no longer found on modern boards,
and their performance was not even capable of 10% of 10Mbit bandwidth.

Allow me a preemptive justification against the inevitable comments from
well meaning bystanders who suggest "why not just leave all this alone?".
Dead drivers cost us all if they are left in tree.  If you think that
is false, then please first consider:

-every time you type "git status", you are checking to see if modifications
 have been made by you to all that dead code.

-every time you type "git grep <regex>" you are searching through files
 which contain that dead code that simply does not interest you.

-every time you build a "allyesconfig" and an "allmodconfig" (don't tell
 me you skip this step before submitting your changes to a maintainer),
 you waste CPU cycles building this dead code.

-every time there is a tree wide API change, or cleanup, or file relocation,
 we pay the cost of updating dead code, or moving dead code.

-daily regression tests (take linux-next as the most transparent
 example) spend time building (and possibly running) this dead code.

-hard working people who regularly run auditing tools looking for lurking
 bugs (sparse/coverity/smatch/coccinelle) are wasting time checking for,
 and fixing bugs in this dead code.

This last one is key.  Please take a look at the git history for the
files that are proposed for removal here.  Look at the git history for
any one of them ("git whatchanged --follow drivers/net/.../driver.c")
Mentally sort the changes into two bins -- (1) the robotic tree-wide
changes, and (2) the "look I found a real run-time bug while using this"
category.  You will see that category #2 is essentially empty.

Further to that, realize that drivers don't simply disappear.  We are
not operating in the binary-only distribution space like other OS.  All
these drivers remain in the git history forever.  If a person is an
enthusiast for extreme legacy hardware, they are probably already
customizing their kernel source and building it themselves to support
such systems.  Also keep in mind that they could still build the 3.8
kernel exactly as-is, and run it (or a 3.8.x stable variant of it) for
several more years if they were really determined to cling to these old
experimental ISA drivers for some reason.

In summary, I hope that folks can be pragmatic about this, and not
get swept up in nostalgia.  Ask yourself whether it is realistic to
expect a person would have a genuine use case where they would
need to build a 3.9+ modern kernel and install it on some legacy hardware
that has no option but to absolutely _require_ one of the drivers
that are deleted here.

The following series was created with --irreversible-delete for
ease of review (it skips showing the content of files that are
deleted); however the complete patches can be pulled as per below.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 0cc8d8df 463d413c
Loading
Loading
Loading
Loading
+0 −4
Original line number Diff line number Diff line
@@ -52,8 +52,6 @@ de4x5.txt
	- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
decnet.txt
	- info on using the DECnet networking layer in Linux.
depca.txt
	- the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
dl2k.txt
	- README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
dm9000.txt
@@ -72,8 +70,6 @@ e1000e.txt
	- README for the Intel Gigabit Ethernet Driver (e1000e).
eql.txt
	- serial IP load balancing
ewrk3.txt
	- the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
fib_trie.txt
	- Level Compressed Trie (LC-trie) notes: a structure for routing.
filter.txt
+0 −203
Original line number Diff line number Diff line
Released 1994-06-13


	CONTENTS:

	1. Introduction.
	2. License.
	3. Files in this release.
	4. Installation.
	5. Problems and tuning.
	6. Using the drivers with earlier releases.
	7. Acknowledgments.


	1. INTRODUCTION.

	This is a set of Ethernet drivers for the D-Link DE-600/DE-620
	pocket adapters, for the parallel port on a Linux based machine.
	Some adapter "clones" will also work.  Xircom is _not_ a clone...
	These drivers _can_ be used as loadable modules,
	and were developed for use on Linux 1.1.13 and above.
	For use on Linux 1.0.X, or earlier releases, see below.

	I have used these drivers for NFS, ftp, telnet and X-clients on
	remote machines. Transmissions with ftp seems to work as
	good as can be expected (i.e. > 80k bytes/sec) from a
	parallel port...:-)  Receive speeds will be about 60-80% of this.
	Depending on your machine, somewhat higher speeds can be achieved.

	All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).


	2. LICENSE.

	This program is free software; you can redistribute it
	and/or modify it under the terms of the GNU General Public
	License as published by the Free Software Foundation; either
	version 2, or (at your option) any later version.

	This program is distributed in the hope that it will be
	useful, but WITHOUT ANY WARRANTY; without even the implied
	warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
	PURPOSE. See the GNU General Public License for more
	details.

	You should have received a copy of the GNU General Public
	License along with this program; if not, write to the Free
	Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
	02139, USA.


	3. FILES IN THIS RELEASE.

	README.DLINK  This file.
	de600.c       The Source (may it be with You :-) for the DE-600
	de620.c       ditto for the DE-620
	de620.h       Macros for de620.c

	If you are upgrading from the d-link tar release, there will
	also be a "dlink-patches" file that will patch Linux 1.1.18:
		linux/drivers/net/Makefile
		linux/drivers/net/CONFIG
		linux/drivers/net/MODULES
		linux/drivers/net/Space.c
		linux/config.in
	Apply the patch by:
	"cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
	The old source, "linux/drivers/net/d_link.c", can be removed.


	4. INSTALLATION.

	o Get the latest net binaries, according to current net.wisdom.

	o Read the NET-2 and Ethernet HOWTOs and modify your setup.

	o If your parallel port has a strange address or irq,
	  modify "linux/drivers/net/CONFIG" accordingly, or adjust
	  the parameters in the "tuning" section in the sources.

	If you are going to use the drivers as loadable modules, do _not_
	enable them while doing "make config", but instead make sure that
	the drivers are included in "linux/drivers/net/MODULES".

	If you are _not_ going to use the driver(s) as loadable modules,
	but instead have them included in the kernel, remember to enable
	the drivers while doing "make config".

	o To include networking and DE600/DE620 support in your kernel:
	  # cd /linux
	  (as modules:)
	  #  make config (answer yes on CONFIG_NET and CONFIG_INET)
	  (else included in the kernel:)
	  #  make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
	  # make clean
	  # make zImage (or whatever magic you usually do)

	o I use lilo to boot multiple kernels, so that I at least
	  can have one working kernel :-). If you do too, append
	  these lines to /etc/lilo/config:

		image = /linux/zImage
		label = newlinux
		root = /dev/hda2 (or whatever YOU have...)

	  # /etc/lilo/install

	o Do "sync" and reboot the new kernel with a D-Link
	  DE-600/DE-620 pocket adapter connected.

	o The adapter can be configured with ifconfig eth?
	  where the actual number is decided by the kernel
	  when the drivers are initialized.


	5. "PROBLEMS" AND TUNING,

	o If you see error messages from the driver, and if the traffic
	  stops on the adapter, try to do "ifconfig" and "route" once
	  more, just as in "rc.inet1".  This should take care of most
	  problems, including effects from power loss, or adapters that
	  aren't connected to the printer port in some way or another.
	  You can somewhat change the behaviour by enabling/disabling
	  the macro  SHUTDOWN_WHEN_LOST  in the "tuning" section.
	  For the DE-600 there is another macro, CHECK_LOST_DE600,
	  that you might want to read about in the "tuning" section.

	o Some machines have trouble handling the parallel port and
	  the adapter at high speed. If you experience problems:

	  DE-600:
	  - The adapter is not recognized at boot, i.e. an Ethernet
	    address of 00:80:c8:... is not shown, try to add another
	      "; SLOW_DOWN_IO"
	    at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
	    uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).

	  - You experience "timeout" messages: first try to add another
	      "; SLOW_DOWN_IO"
	    at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
	    increase the value (original value: 5) at
	    "if (tickssofar < 5)" near line 422.

	  DE-620:
	  - Your parallel port might be "sluggish".  To cater for
	    this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
	    in the "tuning" section. Your first step should be to enable
	    LOWSPEED, and after that you can "tune" the XXX_DELAY values.

	o If the adapter _is_ recognized at boot but you get messages
	  about "Network Unreachable", then the problem is probably
	  _not_ with the driver.  Check your net configuration instead
	  (ifconfig and route) in "rc.inet1".

	o There is some rudimentary support for debugging, look at
	  the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
	  when compiling, or include it in "linux/drivers/net/CONFIG".
	  IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
	  WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!


	6. USING THE DRIVERS WITH EARLIER RELEASES.

	The later 1.1.X releases of the Linux kernel include some
	changes in the networking layer (a.k.a. NET3). This affects
	these drivers in a few places.  The hints that follow are
	_not_ tested by me, since I don't have the disk space to keep
	all releases on-line.
	Known needed changes to date:
	- release patchfile: some patches will fail, but they should
	  be easy to apply "by hand", since they are trivial.
	  (Space.c: d_link_init() is now called de600_probe())
	- de600.c: change  "mark_bh(NET_BH)" to  "mark_bh(INET_BH)".
	- de620.c: (maybe) change the code around "netif_rx(skb);" to be
		   similar to the code around "dev_rint(...)" in de600.c


	7. ACKNOWLEDGMENTS.

	These drivers wouldn't have been done without the base
	(and support) from Ross Biro, and D-Link Systems Inc.
	The driver relies upon GPL-ed source from D-Link Systems Inc.
	and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.

	Additional input also from:
	Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
	and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>

	DE-600 alpha release primary victim^H^H^H^H^H^Htester:
	- Erik Proper <erikp@cs.kun.nl>.
	Good input also from several users, most notably
	- Mark Burton <markb@ordern.demon.co.uk>.

	DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
	- J. Joshua Kopper <kopper@rtsg.mot.com>
	- Olav Kvittem <Olav.Kvittem@uninett.no>
	- Germano Caronni <caronni@nessie.cs.id.ethz.ch>
	- Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>


	Happy hacking!

	Bjorn Ekwall == bj0rn@blox.se
+0 −92
Original line number Diff line number Diff line

DE10x
=====

Memory Addresses:

	SW1	SW2	SW3	SW4
64K	on	on	on	on	d0000	dbfff
	off	on	on	on	c0000	cbfff
	off	off	on	on	e0000	ebfff

32K	on	on	off	on	d8000	dbfff
	off	on	off	on	c8000	cbfff
	off	off	off	on	e8000	ebfff

DBR ROM	on	on			dc000	dffff
	off	on			cc000	cffff
	off	off			ec000	effff

Note  that the 2K  mode   is set  by   SW3/SW4  on/off or  off/off.  Address
assignment is through the RBSA register.

I/O Address:
	SW5
0x300	on
0x200	off

Remote Boot:
	SW6
Disable	on
Enable	off

Remote Boot Timeout:
	SW7
2.5min	on
30s	off

IRQ:
	SW8	SW9	SW10	SW11	SW12
2	on	off	off	off	off
3	off	on	off	off	off
4	off	off	on	off	off
5	off	off	off	on	off
7	off	off	off	off	on

DE20x
=====

Memory Size:

	SW3	SW4
64K	on	on
32K	off	on
2K	on 	off
2K	off	off

Start Addresses:

	SW1	SW2	SW3	SW4
64K	on	on	on	on	c0000	cffff
	on	off	on	on	d0000	dffff
	off	on	on	on	e0000	effff

32K	on	on	off	off	c8000	cffff
	on	off	off	off	d8000	dffff
	off	on	off	off	e8000	effff

Illegal	off	off	 -	 -	  -	  -

I/O Address:
	SW5
0x300	on
0x200	off

Remote Boot:
	SW6
Disable	on
Enable	off

Remote Boot Timeout:
	SW7
2.5min	on
30s	off

IRQ:
	SW8	SW9	SW10	SW11	SW12
5	on	off	off	off	off
9	off	on	off	off	off
10	off	off	on	off	off
11	off	off	off	on	off
15	off	off	off	off	on
+0 −46
Original line number Diff line number Diff line
The EtherWORKS 3  driver in this distribution is  designed to  work with all
kernels   >  1.1.33   (approx)  and  includes  tools   in  the  'ewrk3tools'
subdirectory   to  allow  set   up of   the   card,  similar  to  the  MSDOS
'NICSETUP.EXE' tools provided on  the DOS drivers  disk (type 'make' in that
subdirectory to make the tools).

The supported  cards are DE203,  DE204 and DE205.  All   other cards are NOT
supported - refer to 'depca.c' for running the LANCE based network cards and
'de4x5.c'  for the  DIGITAL   Semiconductor PCI  chip  based  adapters  from
Digital.

The ability to load  this driver as a  loadable module has been included and
used extensively  during the driver  development (to save those  long reboot
sequences). To utilise this ability, you have to do 8 things:

    0) have a copy of the loadable modules code installed on your system.
    1) copy ewrk3.c from the  /linux/drivers/net directory to your favourite
    temporary directory.
    2) edit the  source code near  line 1898 to reflect  the I/O address and
    IRQ you're using.
    3) compile  ewrk3.c, but include -DMODULE in  the command line to ensure
    that the correct bits are compiled (see end of source code).
    4) if you are wanting to add a new  card, goto 5. Otherwise, recompile a
    kernel with the ewrk3 configuration turned off and reboot.
    5) insmod ewrk3.o
          [Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
          [Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
    6) run the net startup bits for your new eth?? interface manually 
    (usually /etc/rc.inet[12] at boot time). 
    7) enjoy!

    Note that autoprobing is not allowed in loadable modules - the system is
    already up and running and you're messing with interrupts.

    To unload a module, turn off the associated interface 
    'ifconfig eth?? down' then 'rmmod ewrk3'.

The performance we've  achieved so far  has been measured through the 'ttcp'
tool   at 975kB/s.  This  measures  the  total  TCP  stack performance which
includes the   card,  so don't  expect   to get   much nearer  the  1.25MB/s
theoretical Ethernet rate.


Enjoy!

Dave
+0 −12
Original line number Diff line number Diff line
@@ -2974,11 +2974,6 @@ S: Maintained
F:	include/linux/netfilter_bridge/
F:	net/bridge/

ETHERTEAM 16I DRIVER
M:	Mika Kuoppala <miku@iki.fi>
S:	Maintained
F:	drivers/net/ethernet/fujitsu/eth16i.c

EXT2 FILE SYSTEM
M:	Jan Kara <jack@suse.cz>
L:	linux-ext4@vger.kernel.org
@@ -5370,13 +5365,6 @@ F: include/linux/sunrpc/
F:	include/uapi/linux/nfs*
F:	include/uapi/linux/sunrpc/

NI5010 NETWORK DRIVER
M:	Jan-Pascal van Best <janpascal@vanbest.org>
M:	Andreas Mohr <andi@lisas.de>
L:	netdev@vger.kernel.org
S:	Maintained
F:	drivers/net/ethernet/racal/ni5010.*

NILFS2 FILESYSTEM
M:	KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
L:	linux-nilfs@vger.kernel.org
Loading