Documentation/networking/device_drivers/dec/de4x5.rst

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