1 files changed, 178 insertions, 0 deletions
diff --git a/Documentation/networking/de4x5.txt b/Documentation/networking/de4x5.txt
new file mode 100644
index 000000000000..c8e4ca9b2c3e
--- /dev/null
+++ b/Documentation/networking/de4x5.txt
@@ -0,0 +1,178 @@
+    Originally,   this  driver  was    written  for the  Digital   Equipment
+    Corporation series of EtherWORKS Ethernet cards:
+        DE425 TP/COAX EISA
+        DE434 TP PCI
+        DE435 TP/COAX/AUI PCI
+        DE450 TP/COAX/AUI PCI
+        DE500 10/100 PCI Fasternet
+    but it  will  now attempt  to  support all  cards which   conform to the
+    Digital Semiconductor   SROM   Specification.    The  driver   currently
+    recognises the following chips:
+        DC21040  (no SROM) 
+        DC21041[A]  
+        DC21140[A] 
+        DC21142 
+        DC21143 
+    So far the driver is known to work with the following cards:
+        KINGSTON
+        Linksys
+        ZNYX342
+        SMC8432
+        SMC9332 (w/new SROM)
+        ZNYX31[45]
+        ZNYX346 10/100 4 port (can act as a 10/100 bridge!) 
+    The driver has been tested on a relatively busy network using the DE425,
+    DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
+    16M of data to a DECstation 5000/200 as follows:
+                TCP           UDP
+             TX     RX     TX     RX
+    DE425   1030k  997k   1170k  1128k
+    DE434   1063k  995k   1170k  1125k
+    DE435   1063k  995k   1170k  1125k
+    DE500   1063k  998k   1170k  1125k  in 10Mb/s mode
+    All  values are typical (in   kBytes/sec) from a  sample  of 4 for  each
+    measurement. Their error is +/-20k on a quiet (private) network and also
+    depend on what load the CPU has.
+    =========================================================================
+    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).  Loadable module support  under PCI and EISA has been
+    achieved by letting the driver autoprobe as if it were compiled into the
+    kernel. Do make sure  you're not sharing  interrupts with anything  that
+    cannot accommodate  interrupt  sharing!
+    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 de4x5.c from the  /linux/drivers/net directory to your favourite
+    temporary directory.
+    2) for fixed  autoprobes (not  recommended),  edit the source code  near
+    line 5594 to reflect the I/O address  you're using, or assign these when
+    loading by:
+                   insmod de4x5 io=0xghh           where g = bus number
+                                                        hh = device number   
+       NB: autoprobing for modules is now supported by default. You may just
+           use:
+                   insmod de4x5
+           to load all available boards. For a specific board, still use
+           the 'io=?' above.
+    3) compile  de4x5.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 de4x5 configuration turned off and reboot.
+    5) insmod de4x5 [io=0xghh]
+    6) run the net startup bits for your new eth?? interface(s) manually 
+    (usually /etc/rc.inet[12] at boot time). 
+    7) enjoy!
+    To unload a module, turn off the associated interface(s) 
+    'ifconfig eth?? down' then 'rmmod de4x5'.
+    Automedia detection is included so that in  principle you can disconnect
+    from, e.g.  TP, reconnect  to BNC  and  things will still work  (after a
+    pause whilst the   driver figures out   where its media went).  My tests
+    using ping showed that it appears to work....
+    By  default,  the driver will  now   autodetect any  DECchip based card.
+    Should you have a need to restrict the driver to DIGITAL only cards, you
+    can compile with a  DEC_ONLY define, or if  loading as a module, use the
+    'dec_only=1'  parameter. 
+    I've changed the timing routines to  use the kernel timer and scheduling
+    functions  so that the  hangs  and other assorted problems that occurred
+    while autosensing the  media  should be gone.  A  bonus  for the DC21040
+    auto  media sense algorithm is  that it can now  use one that is more in
+    line with the  rest (the DC21040  chip doesn't  have a hardware  timer).
+    The downside is the 1 'jiffies' (10ms) resolution.
+    IEEE 802.3u MII interface code has  been added in anticipation that some
+    products may use it in the future.
+    The SMC9332 card  has a non-compliant SROM  which needs fixing -  I have
+    patched this  driver to detect it  because the SROM format used complies
+    to a previous DEC-STD format.
+    I have removed the buffer copies needed for receive on Intels.  I cannot
+    remove them for   Alphas since  the  Tulip hardware   only does longword
+    aligned  DMA transfers  and  the  Alphas get   alignment traps with  non
+    longword aligned data copies (which makes them really slow). No comment.
+    I  have added SROM decoding  routines to make this  driver work with any
+    card that  supports the Digital  Semiconductor SROM spec. This will help
+    all  cards running the dc2114x  series chips in particular.  Cards using
+    the dc2104x  chips should run correctly with  the basic  driver.  I'm in
+    debt to <mjacob@feral.com> for the  testing and feedback that helped get
+    this feature working.  So far we have  tested KINGSTON, SMC8432, SMC9332
+    (with the latest SROM complying  with the SROM spec  V3: their first was
+    broken), ZNYX342  and  LinkSys. ZNYX314 (dual  21041  MAC) and  ZNYX 315
+    (quad 21041 MAC)  cards also  appear  to work despite their  incorrectly
+    wired IRQs.
+    I have added a temporary fix for interrupt problems when some SCSI cards
+    share the same interrupt as the DECchip based  cards. The problem occurs
+    because  the SCSI card wants to  grab the interrupt  as a fast interrupt
+    (runs the   service routine with interrupts turned   off) vs.  this card
+    which really needs to run the service routine with interrupts turned on.
+    This driver will  now   add the interrupt service   routine  as  a  fast
+    interrupt if it   is bounced from the   slow interrupt.  THIS IS NOT   A
+    RECOMMENDED WAY TO RUN THE DRIVER  and has been done  for a limited time
+    until  people   sort  out their  compatibility    issues and the  kernel
+    interrupt  service code  is  fixed.   YOU  SHOULD SEPARATE OUT  THE FAST
+    INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not
+    run on the same interrupt. PCMCIA/CardBus is another can of worms...
+    Finally, I think  I have really  fixed  the module  loading problem with
+    more than one DECchip based  card.  As a  side effect, I don't mess with
+    the  device structure any  more which means that  if more than 1 card in
+    2.0.x is    installed (4  in   2.1.x),  the  user   will have   to  edit
+    linux/drivers/net/Space.c  to make room for  them. Hence, module loading
+    is  the preferred way to use   this driver, since  it  doesn't have this
+    limitation.
+    Where SROM media  detection is used and  full duplex is specified in the
+    SROM,  the feature is  ignored unless  lp->params.fdx  is set at compile
+    time  OR during  a   module load  (insmod  de4x5   args='eth??:fdx' [see
+    below]).  This is because there  is no way  to automatically detect full
+    duplex   links  except through   autonegotiation.    When I  include the
+    autonegotiation feature in  the SROM autoconf  code, this detection will
+    occur automatically for that case.
+    Command line  arguments are  now allowed, similar to  passing  arguments
+    through LILO. This will allow a per adapter board set  up of full duplex
+    and media. The only lexical constraints are:  the board name (dev->name)
+    appears in  the list before its parameters.  The list of parameters ends
+    either at the end of the parameter list or with another board name.  The
+    following parameters are allowed:
+            fdx        for full duplex
+            autosense  to set the media/speed; with the following 
+                       sub-parameters:
+                       TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO
+    Case sensitivity is important  for  the sub-parameters. They *must*   be
+    upper case. Examples:
+        insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'.
+    For a compiled in driver, in linux/drivers/net/CONFIG, place e.g.
+        DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"' 
+    Yes,  I know full duplex  isn't permissible on BNC  or AUI; they're just
+    examples. By default, full duplex is turned  off and AUTO is the default
+    autosense setting. In  reality, I expect only the  full duplex option to
+    be used. Note the use of single quotes in the two examples above and the
+    lack of commas to separate items.

diff --git a/Documentation/networking/de4x5.txt b/Documentation/networking/de4x5.txt new file mode 100644 index 000000000000..c8e4ca9b2c3e --- /dev/null +++ b/Documentation/networking/de4x5.txt
@@ -0,0 +1,178 @@
	1	Originally, this driver was written for the Digital Equipment
	2	Corporation series of EtherWORKS Ethernet cards:
	3
	4	DE425 TP/COAX EISA
	5	DE434 TP PCI
	6	DE435 TP/COAX/AUI PCI
	7	DE450 TP/COAX/AUI PCI
	8	DE500 10/100 PCI Fasternet
	9
	10	but it will now attempt to support all cards which conform to the
	11	Digital Semiconductor SROM Specification. The driver currently
	12	recognises the following chips:
	13
	14	DC21040 (no SROM)
	15	DC21041[A]
	16	DC21140[A]
	17	DC21142
	18	DC21143
	19
	20	So far the driver is known to work with the following cards:
	21
	22	KINGSTON
	23	Linksys
	24	ZNYX342
	25	SMC8432
	26	SMC9332 (w/new SROM)
	27	ZNYX31[45]
	28	ZNYX346 10/100 4 port (can act as a 10/100 bridge!)
	29
	30	The driver has been tested on a relatively busy network using the DE425,
	31	DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
	32	16M of data to a DECstation 5000/200 as follows:
	33
	34	TCP UDP
	35	TX RX TX RX
	36	DE425 1030k 997k 1170k 1128k
	37	DE434 1063k 995k 1170k 1125k
	38	DE435 1063k 995k 1170k 1125k
	39	DE500 1063k 998k 1170k 1125k in 10Mb/s mode
	40
	41	All values are typical (in kBytes/sec) from a sample of 4 for each
	42	measurement. Their error is +/-20k on a quiet (private) network and also
	43	depend on what load the CPU has.
	44
	45	=========================================================================
	46
	47	The ability to load this driver as a loadable module has been included
	48	and used extensively during the driver development (to save those long
	49	reboot sequences). Loadable module support under PCI and EISA has been
	50	achieved by letting the driver autoprobe as if it were compiled into the
	51	kernel. Do make sure you're not sharing interrupts with anything that
	52	cannot accommodate interrupt sharing!
	53
	54	To utilise this ability, you have to do 8 things:
	55
	56	0) have a copy of the loadable modules code installed on your system.
	57	1) copy de4x5.c from the /linux/drivers/net directory to your favourite
	58	temporary directory.
	59	2) for fixed autoprobes (not recommended), edit the source code near
	60	line 5594 to reflect the I/O address you're using, or assign these when
	61	loading by:
	62
	63	insmod de4x5 io=0xghh where g = bus number
	64	hh = device number
	65
	66	NB: autoprobing for modules is now supported by default. You may just
	67	use:
	68
	69	insmod de4x5
	70
	71	to load all available boards. For a specific board, still use
	72	the 'io=?' above.
	73	3) compile de4x5.c, but include -DMODULE in the command line to ensure
	74	that the correct bits are compiled (see end of source code).
	75	4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
	76	kernel with the de4x5 configuration turned off and reboot.
	77	5) insmod de4x5 [io=0xghh]
	78	6) run the net startup bits for your new eth?? interface(s) manually
	79	(usually /etc/rc.inet[12] at boot time).
	80	7) enjoy!
	81
	82	To unload a module, turn off the associated interface(s)
	83	'ifconfig eth?? down' then 'rmmod de4x5'.
	84
	85	Automedia detection is included so that in principle you can disconnect
	86	from, e.g. TP, reconnect to BNC and things will still work (after a
	87	pause whilst the driver figures out where its media went). My tests
	88	using ping showed that it appears to work....
	89
	90	By default, the driver will now autodetect any DECchip based card.
	91	Should you have a need to restrict the driver to DIGITAL only cards, you
	92	can compile with a DEC_ONLY define, or if loading as a module, use the
	93	'dec_only=1' parameter.
	94
	95	I've changed the timing routines to use the kernel timer and scheduling
	96	functions so that the hangs and other assorted problems that occurred
	97	while autosensing the media should be gone. A bonus for the DC21040
	98	auto media sense algorithm is that it can now use one that is more in
	99	line with the rest (the DC21040 chip doesn't have a hardware timer).
	100	The downside is the 1 'jiffies' (10ms) resolution.
	101
	102	IEEE 802.3u MII interface code has been added in anticipation that some
	103	products may use it in the future.
	104
	105	The SMC9332 card has a non-compliant SROM which needs fixing - I have
	106	patched this driver to detect it because the SROM format used complies
	107	to a previous DEC-STD format.
	108
	109	I have removed the buffer copies needed for receive on Intels. I cannot
	110	remove them for Alphas since the Tulip hardware only does longword
	111	aligned DMA transfers and the Alphas get alignment traps with non
	112	longword aligned data copies (which makes them really slow). No comment.
	113
	114	I have added SROM decoding routines to make this driver work with any
	115	card that supports the Digital Semiconductor SROM spec. This will help
	116	all cards running the dc2114x series chips in particular. Cards using
	117	the dc2104x chips should run correctly with the basic driver. I'm in
	118	debt to <mjacob@feral.com> for the testing and feedback that helped get
	119	this feature working. So far we have tested KINGSTON, SMC8432, SMC9332
	120	(with the latest SROM complying with the SROM spec V3: their first was
	121	broken), ZNYX342 and LinkSys. ZNYX314 (dual 21041 MAC) and ZNYX 315
	122	(quad 21041 MAC) cards also appear to work despite their incorrectly
	123	wired IRQs.
	124
	125	I have added a temporary fix for interrupt problems when some SCSI cards
	126	share the same interrupt as the DECchip based cards. The problem occurs
	127	because the SCSI card wants to grab the interrupt as a fast interrupt
	128	(runs the service routine with interrupts turned off) vs. this card
	129	which really needs to run the service routine with interrupts turned on.
	130	This driver will now add the interrupt service routine as a fast
	131	interrupt if it is bounced from the slow interrupt. THIS IS NOT A
	132	RECOMMENDED WAY TO RUN THE DRIVER and has been done for a limited time
	133	until people sort out their compatibility issues and the kernel
	134	interrupt service code is fixed. YOU SHOULD SEPARATE OUT THE FAST
	135	INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not
	136	run on the same interrupt. PCMCIA/CardBus is another can of worms...
	137
	138	Finally, I think I have really fixed the module loading problem with
	139	more than one DECchip based card. As a side effect, I don't mess with
	140	the device structure any more which means that if more than 1 card in
	141	2.0.x is installed (4 in 2.1.x), the user will have to edit
	142	linux/drivers/net/Space.c to make room for them. Hence, module loading
	143	is the preferred way to use this driver, since it doesn't have this
	144	limitation.
	145
	146	Where SROM media detection is used and full duplex is specified in the
	147	SROM, the feature is ignored unless lp->params.fdx is set at compile
	148	time OR during a module load (insmod de4x5 args='eth??:fdx' [see
	149	below]). This is because there is no way to automatically detect full
	150	duplex links except through autonegotiation. When I include the
	151	autonegotiation feature in the SROM autoconf code, this detection will
	152	occur automatically for that case.
	153
	154	Command line arguments are now allowed, similar to passing arguments
	155	through LILO. This will allow a per adapter board set up of full duplex
	156	and media. The only lexical constraints are: the board name (dev->name)
	157	appears in the list before its parameters. The list of parameters ends
	158	either at the end of the parameter list or with another board name. The
	159	following parameters are allowed:
	160
	161	fdx for full duplex
	162	autosense to set the media/speed; with the following
	163	sub-parameters:
	164	TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO
	165
	166	Case sensitivity is important for the sub-parameters. They must be
	167	upper case. Examples:
	168
	169	insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'.
	170
	171	For a compiled in driver, in linux/drivers/net/CONFIG, place e.g.
	172	DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"'
	173
	174	Yes, I know full duplex isn't permissible on BNC or AUI; they're just
	175	examples. By default, full duplex is turned off and AUTO is the default
	176	autosense setting. In reality, I expect only the full duplex option to
	177	be used. Note the use of single quotes in the two examples above and the
	178	lack of commas to separate items.