diff options
Diffstat (limited to 'Documentation/networking')
| -rw-r--r-- | Documentation/networking/8139too.txt | 194 | ||||
| -rw-r--r-- | Documentation/networking/fore200e.txt | 55 | ||||
| -rw-r--r-- | Documentation/networking/tulip.txt | 244 | ||||
| -rw-r--r-- | Documentation/networking/wavelan.txt | 114 |
4 files changed, 461 insertions, 146 deletions
diff --git a/Documentation/networking/8139too.txt b/Documentation/networking/8139too.txt new file mode 100644 index 000000000..6a75c7338 --- /dev/null +++ b/Documentation/networking/8139too.txt @@ -0,0 +1,194 @@ + + "8139too" Fast Ethernet driver for Linux + Improved support for RTL-8139 Fast Ethernet adapters + + Copyright 2000 Jeff Garzik <jgarzik@mandrakesoft.com> + + + Architectures supported (all PCI platforms): + x86, Alpha AXP, PowerPC, Sparc64 + + + + +Disclaimer +---------- + +THIS DRIVER IS A DEVELOPMENT RELEASE FOR A DEVELOPMENT KERNEL. DO NOT +USE IN A PRODUCTION ENVIRONMENT. + +DO NOT CONTACT DONALD BECKER FOR SUPPORT OF THIS DRIVER, his driver is +completely different and maintained independently of the 8139too code base. + + + +Requirements +------------ +Kernel 2.3.41 or later. +A Fast Ethernet adapter containing an RTL8139-based chip. + + + +Introduction +------------ + +The "8139too" Fast Ethernet driver for Linux 2.4.0 is a substantial +modification of the experimental rtl8139 driver from Donald Becker, +some versions of which appeared in 2.2.x and 2.3.x kernels. The +RTL-8139 is a very low-cost Fast Ethernet chip, which makes it very +popular. + +The step from 2.2.x to 2.4.x kernels brings many new features to Linux +device drivers. Features for MMIO resources, a standard hot-plug API, +and other interfaces are now becoming requirements, as drivers move +off the x86 platform. With that in mind, I have begun updating the +RTL-8139 driver to current 2.3.x (2.4) kernel standards and APIs, and +fixing the problems that users have been encountering. + + + +Features of 8139too +------------------- +[note - this list intended for people familiar with kernel drivers] + +** 100% MMIO, for full speed operation. All users (so far) have +reported performance increases over their existing RTL drivers. + +** Multi-platform support: x86, Alpha, PPC, ... + +** Use proper SMP spinlocking, fixing SMP interrupt bugs, making the +driver portable to non-x86 SMP platforms in the process. + +** Use new PCI driver API for seamless, low-maintenance hot-plug support + +** Several bugs fixes from original rtl8139 1.08r (October 5, 1999), +including the very common "transmit timeout" problem. + +* Use new resource allocation API, required for hot-plug support +* Use new register read/write macros +* initcall support (module_init/exit) +* vastly improved debug tracing support +* code formatting in many places for readability +* use new init_etherdev() facilities + +...and probably some other less important changes which I forgot. + + + +Installation +------------ + +OPTION 1: Build inside kernel tree (into kernel image, or as module) + + (overwrite 8139too driver in kernel tree with different version) + 1) cp 8139too.c $my_source_tree/drivers/net/8139too.c + +OPTION 2: Build outside kernel tree + + Use the included Makefile. + + + +Tested Adapters +--------------- +AOpen ALN-325C +KTI KF-230TX +KTI KF-230TX/2 + +(please add your adapter model to this list) + + + +Status of Platform Support +-------------------------- + +(see errata below for details) + +x86: tested, stable +Alpha AXP: tested, stable +PowerPC: tested, unstable +Sparc64: not tested + + + +Special Thanks +-------------- +The following people contributed invaluable testing time, feedback +and/or patches during the development of this driver. Thanks to all +of them. + +Donald Becker, Alan Cox, Richard Stallman, Linus Torvalds - inspiration + +Alan Cox, Gerard Roudier - insight on posted MMIO writes + +Martin Mares - code review + +Tigran Aivazian - testing, code review, and a bug fix + +Chmouel Boudjnah, Alexander Dietrich, Oleg Drokin, +James Fidell, Taso Hatzi, Peter K - intrepid test team + +And thanks to every supporter free software. + + + +Known Bugs / Errata / To-Do +--------------------------- +The following issues are known, and are actively being pursued. Patches +to resolve these issues is welcome. If a problem occurs which is not in +the list, please report it. That's why we do beta releases, after all... + + + +1) Work with Donald to merge fixes and updates into his driver. + +2) 2.2.x COMPATIBILITY SUPPORT IS BROKEN. DO NOT USE IT. +It is included only for enterprising hackers willing to help fix it. + +3) PPC platform has stability problems. + +4) Sparc64 platform not tested at all. + +5) Identify and fix "rx wedge" when ping flooded. + +7) N-Way auto-negotiation is known to fail in some cases. This problem +also occurs in the rtl8139 driver in kernels 2.2.x/2.3.x. Solution: +Following technique in sunhme and sunbmac, use a kernel timer to +manually perform autonegotiation in case the network or card cannot do +it automatically. (patches welcome) + +8) Much improved command line / module parameter setup. (patches and +suggestions welcome) + +9) Better documentation. (patches welcome) + +10) User-mode (or maybe optional /proc) diagnostics program. + + + + +Change History +-------------- +Version 0.9.3.3.2 - Feb 22, 2000 - second public beta release + +* Begin integration of Daniel Kobras' MMIO flush patch (disabled for now) +* Softnet logic updates to fix bugs and improve performance +* Dynamic sizing of I/O resources (0x80 for older chips, 0xFF for newer ones) +* Remove bogus SiS entries from PCI probe table +* Add support for cards + "Delta Electronics 8139 10/100BaseTX" + "Addtron Technolgy 8139 10/100BaseTX" +* Fix major bug with rx ring buffer size (also present in rtl8139.c 1.08r) +* PCI DMA mapping by Dave Miller +* Complete rewrite of SMP locking logic +* Hotplug support +* Call rtl8139_hw_start from rtl8139_open, and remove duplicated code + from rtl8139_open +* Reset NWay registers to sane defaults on rtl8139_open/hw_start +* Miscellaneous code cleanup + +Version 0.7.0 - Feb 7, 2000 - first public beta release + + +[EOF] + diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt new file mode 100644 index 000000000..13ee5327e --- /dev/null +++ b/Documentation/networking/fore200e.txt @@ -0,0 +1,55 @@ + +Fore PCA-200E/SBA-200E ATM NIC Firmware Copyright Notice +-------------------------------------------------------- + +Please read the fore200e_firmware_copyright file present +in the linux/drivers/atm directory for details and restrictions. + + +Firmware Updates +---------------- + +The FORE Systems 200E-series driver is shipped with firmware data being +uploaded to the ATM adapters at system boot time or at module loading time. +The supplied firmware images should work with all adapters. + +However, if you encounter problems (firmware doesn't start or the driver +is unable to read PROM data), you may consider trying another firmware +version. Alternative binary firmware images can be found somewhere on the +ForeThough CD-ROM supplied with your adapter by FORE Systems. + +You can also get the latest firmware images from FORE Systems at +http://www.fore.com. Register TACTics Online and go to +the 'software updates' pages. The firmware binaries are part of +the various ForeThough software distributions. + +Notice that different versions of the PCA-200E firmware exist, depending +on the endianess of the host architecture. The driver is shipped with +both little and big endian PCA firmware images. + +Name and location of the new firmware images can be set at kernel +configuration time. + + +Driver Rebuilding +----------------- + +1. Copy the new firmware binary files (with .bin, .bin1 or .bin2 suffix) + to some directory, such as linux/drivers/atm. + +2. Reconfigure your kernel to set the new firmware name and location. + Expected pathnames are absolute or relative to the drivers/atm directory. + +3. Delete the files drivers/atm/fore200e_pca_fw.[co] and/or fore200e_sba_fw.[co] + to ensure that the new firmware will be used when rebuilding the kernel or + the module. + +4. Rebuild and re-install your kernel or your module. + + +Feedback +-------- + +Feedback is welcome. Please send success stories/bug reports/ +patches/improvement/comments/flames to <lizzi@cnam.fr>. + diff --git a/Documentation/networking/tulip.txt b/Documentation/networking/tulip.txt index 4a83d1bf2..ecef178b0 100644 --- a/Documentation/networking/tulip.txt +++ b/Documentation/networking/tulip.txt @@ -1,110 +1,144 @@ Tulip Ethernet Card Driver + Maintained by Jeff Garzik <jgarzik@mandrakesoft.com> The Tulip driver is developed by Donald Becker and changed by -Takashi Manabe. This driver is designed to work with PCI Ethernet -cards which use the DECchip DC21x4x family. This driver hopefully -works with all of 1.2.x and 1.3.x kernels, but I tested only -with 1.2.13, 1.3.39, 1.3.49, 1.3.52, 1.3.57 and later. - -Hopefully, the de4x5.c driver will support all cards supported -by the tulip.c driver. However, the SMC's 9332dst card and some -cards do not work with the de4x5.c driver. So, if your card is -not a 9332dst, please try the de4x5.c driver first. - -Success List -============ - -+-------------------------------------+-----------+-------------+ -|vendor/card |chip |system | -+-------------------------------------+-----------+-------------+ -|SMC | | | -| EtherPower 10 PCI(8432T/8432BT) |21040/21041|Pentium | -+-------------------------------------+-----------+-------------+ -|SMC | | | -| EtherPower 10/100 PCI(9332DST) |21140 |Pentium/UDB | -+-------------------------------------+-----------+-------------+ -|DEC | | | -| EtherWorks 100/10 PCI(DE500-XA) |21140 |Pentium | -+-------------------------------------+-----------+-------------+ -|DEC | | | -| EtherWorks 10 PCI(DE450) |21041 |Pentium | -+-------------------------------------+-----------+-------------+ -|DEC | | | -| QSILVER's |21040 |UDB | -+-------------------------------------+-----------+-------------+ -|ZNYX | | | -| 312 etherarray |21040 |Pentium | -+-------------------------------------+-----------+-------------+ -|Allied Telesis | | | -| LA100PCI-T |21140 |Pentium/UDB | -+-------------------------------------+-----------+-------------+ -|Danpex ('Planet Japan' in Japan?) | | | -| EN-9400 |21040 |Pentium | -+-------------------------------------+-----------+-------------+ -|Cogent | | | -| EM110 |21140 |Pentium | -+-------------------------------------+-----------+-------------+ - -Pentium: PCI machine with Pentium CPU -UDB: Universal Desktop Box(aka Multia) with Alpha 21066 CPU - -Known bug(s) -============ -This driver's media detection is very simple and sometimes -it causes serious problem. The driver automatically switches -media when it causes timeout. If you want to specify or to fix -a media; - -- Modify TULIP_PORT in tulip.c, line 33. -- Uncomment the definition of TULIP_FIX_PORT in tulip.c, line 40. - -or - -- Use patched ifconfig command and specify 'link='. The patch - against ifconfig.c in net-tools-1.3.50-BETA6e is included in - this file. - -Thanks +Takashi Manabe and a cast of thousands. + + This driver is for the Digital "Tulip" Ethernet adapter interface. + It should work with most DEC 21*4*-based chips/ethercards, as well as + with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and ASIX. + + The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O + Center of Excellence in Space Data and Information Sciences + Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771 + + Additional information available at + http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html + + Theory of Operation + +Board Compatibility +=================== + +This device driver is designed for the DECchip "Tulip", Digital's +single-chip ethernet controllers for PCI. Supported members of the family +are the 21040, 21041, 21140, 21140A, 21142, and 21143. Similar work-alike +chips from Lite-On, Macronics, ASIX, Compex and other listed below are also +supported. + +These chips are used on at least 140 unique PCI board designs. The great +number of chips and board designs supported is the reason for the +driver size and complexity. Almost of the increasing complexity is in the +board configuration and media selection code. There is very little +increasing in the operational critical path length. + +Board-specific settings +======================= + +PCI bus devices are configured by the system at boot time, so no jumpers +need to be set on the board. The system BIOS preferably should assign the +PCI INTA signal to an otherwise unused system IRQ line. + +Some boards have EEPROMs tables with default media entry. The factory default +is usually "autoselect". This should only be overridden when using +transceiver connections without link beat e.g. 10base2 or AUI, or (rarely!) +for forcing full-duplex when used with old link partners that do not do +autonegotiation. + +Driver operation +================ + +Ring buffers +------------ + +The Tulip can use either ring buffers or lists of Tx and Rx descriptors. +This driver uses statically allocated rings of Rx and Tx descriptors, set at +compile time by RX/TX_RING_SIZE. This version of the driver allocates skbuffs +for the Rx ring buffers at open() time and passes the skb->data field to the +Tulip as receive data buffers. When an incoming frame is less than +RX_COPYBREAK bytes long, a fresh skbuff is allocated and the frame is +copied to the new skbuff. When the incoming frame is larger, the skbuff is +passed directly up the protocol stack and replaced by a newly allocated +skbuff. + +The RX_COPYBREAK value is chosen to trade-off the memory wasted by +using a full-sized skbuff for small frames vs. the copying costs of larger +frames. For small frames the copying cost is negligible (esp. considering +that we are pre-loading the cache with immediately useful header +information). For large frames the copying cost is non-trivial, and the +larger copy might flush the cache of useful data. A subtle aspect of this +choice is that the Tulip only receives into longword aligned buffers, thus +the IP header at offset 14 isn't longword aligned for further processing. +Copied frames are put into the new skbuff at an offset of "+2", thus copying +has the beneficial effect of aligning the IP header and preloading the +cache. + +Synchronization +--------------- +The driver runs as two independent, single-threaded flows of control. One +is the send-packet routine, which enforces single-threaded use by the +dev->tbusy flag. The other thread is the interrupt handler, which is single +threaded by the hardware and other software. + +The send packet thread has partial control over the Tx ring and 'dev->tbusy' +flag. It sets the tbusy flag whenever it's queuing a Tx packet. If the next +queue slot is empty, it clears the tbusy flag when finished otherwise it sets +the 'tp->tx_full' flag. + +The interrupt handler has exclusive control over the Rx ring and records stats +from the Tx ring. (The Tx-done interrupt can't be selectively turned off, so +we can't avoid the interrupt overhead by having the Tx routine reap the Tx +stats.) After reaping the stats, it marks the queue entry as empty by setting +the 'base' to zero. Iff the 'tp->tx_full' flag is set, it clears both the +tx_full and tbusy flags. + +Notes +===== + +Thanks to Duke Kamstra of SMC for long ago providing an EtherPower board. +Greg LaPolla at Linksys provided PNIC and other Linksys boards. +Znyx provided a four-port card for testing. + +References +========== + +http://cesdis.gsfc.nasa.gov/linux/misc/NWay.html +http://www.digital.com (search for current 21*4* datasheets and "21X4 SROM") +http://www.national.com/pf/DP/DP83840A.html +http://www.asix.com.tw/pmac.htm +http://www.admtek.com.tw/ + +Errata ====== -o becker@CESDIS.gsfc.nasa.gov (author of the tulip.c driver) -o davies@wanton.lkg.dec.com (author of the de4x5.c driver) - -o siekas@mailhost.tcs.tulane.edu - -o jheiss@calvin.caltech.edu (providing information about smc8432 card) -o goto@plathome.co.jp (lending me a DE450 card) -o ted@physics.ucsb.edu -o pmheuvel@xs4all.nl -o hjl@lucon.org (EN-9400) -o niles@axp745.gsfc.nasa.gov (ZNYX312) -o pkc@scs.carleton.ca (EM110) -o and testers... - ------------------------------------------------------------------------ -*** ifconfig.c-dist Wed Jan 17 07:25:36 1996 ---- ifconfig.c Tue Apr 9 15:24:25 1996 -*************** -*** 765,770 **** ---- 766,786 ---- - continue; - } - ifr.ifr_map.irq = atoi(*spp); -+ if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) { -+ fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno)); -+ goterr = 1; -+ } -+ spp++; -+ continue; -+ } -+ -+ if (!strcmp(*spp, "link")) { -+ if (*++spp == NULL) usage(); -+ if (ioctl(skfd, SIOCGIFMAP, &ifr) < 0) { -+ goterr = 1; -+ continue; -+ } -+ ifr.ifr_map.port = atoi(*spp); - if (ioctl(skfd, SIOCSIFMAP, &ifr) < 0) { - fprintf(stderr, "SIOCSIFMAP: %s\n", strerror(errno)); - goterr = 1; +The old DEC databooks were light on details. +The 21040 databook claims that CSR13, CSR14, and CSR15 should each be the last +register of the set CSR12-15 written. Hmmm, now how is that possible? + +The DEC SROM format is very badly designed not precisely defined, leading to +part of the media selection junkheap below. Some boards do not have EEPROM +media tables and need to be patched up. Worse, other boards use the DEC +design kit media table when it isn't correct for their board. + +We cannot use MII interrupts because there is no defined GPIO pin to attach +them. The MII transceiver status is polled using an kernel timer. + + +Source tree tour +---------------- +The following is a list of files comprising the Tulip ethernet driver in +drivers/net/tulip subdirectory. + +21142.c - 21142-specific h/w interaction +eeprom.c - EEPROM reading and parsing +interrupt.c - Interrupt handler +media.c - Media selection and MII support +pnic.c - PNIC-specific h/w interaction +timer.c - Main driver timer, and misc h/w timers +tulip.h - Private driver header +tulip_core.c - Driver core (a.k.a. where "everything else" goes) + + + +[EOF] + diff --git a/Documentation/networking/wavelan.txt b/Documentation/networking/wavelan.txt index a4a1f7921..82006e55d 100644 --- a/Documentation/networking/wavelan.txt +++ b/Documentation/networking/wavelan.txt @@ -1,41 +1,73 @@ -Sun Jul 2 01:38:33 EST 1995 - - As the date above certify, this ``readme'' is mostly -obsolete. Please read release notes and change list in -driver/net/wavelan.p.h, and consult my web page at : - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html - - Jean <jt@hpl.hp.com> - -1. At present the driver autoprobes for a WaveLAN card only at I/O address - 0x390. The version of the card that I use (NCR) supports four I/O addresses - (selectable via a pair of DIP switches). If you want the driver to - autoprobe a different subset of the four valid addresses then you will need - to edit .../drivers/net/wavelan.c (near line 714) and change the - initialisation of the `iobase[]' array. Normally, I use a LILO - configuration file directive to obviate the need for autoprobing entirely, - a course of action I heartily recommend. - -2. By default, the driver uses the Network ID (NWID) stored in the card's - Parameter Storage Area (PSA). However, the PSA NWID can be overridden by a - value passed explicitly as the third numeric argument to LILO's "ether=" - directive, either at the LILO prompt at boot time or within LILO's - configuration file. - For example, the following line from such a LILO configuration file would - auto-configure the IRQ value, set the I/O base to 0x390 and set the NWID to - 0x4321, all on a WaveLAN card labelled "eth0": - - .. - append ="ether=0,0x390,0x4321,eth0" - .. - -3. The driver uses the IRQ stored in the card's PSA. - To change this you will need to use the configuration/setup software that - accompanies each WaveLAN device. Yes, the driver should use the value passed - in via LILO and it will, just as soon as I can work out why that part of the - code doesn't work :-(. - -4. If you encounter any problems send me some email. - -Good luck, -Bruce Janson (bruce@cs.usyd.edu.au) + The Wavelan drivers saga + ------------------------ + + By Jean Tourrilhes <jt@hpl.hp.com> + + The Wavelan is a Radio network adapter designed by +Lucent. Under this generic name is hidden quite a variety of hardware, +and many Linux driver to support it. + The get the full story on Wireless LANs, please consult : + http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/ + +"wavelan" driver (old ISA Wavelan) +---------------- + o Config : Network device -> Wireless LAN -> AT&T WaveLAN + o Location : .../drivers/net/wavelan* + o in-line doc : .../drivers/net/wavelan.p.h + o on-line doc : + http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html + + This is the driver for the ISA version of the first generation +of the Wavelan, now discontinued. The device is 2 Mb/s, composed of a +Intel 82586 controler and a Lucent Modem, and is NOT 802.11 compliant. + The driver has been tested with the following hardware : + o Wavelan ISA 915 MHz (full length ISA card) + o Wavelan ISA 915 MHz 2.0 (half length ISA card) + o Wavelan ISA 2.4 GHz (full length ISA card, fixed frequency) + o Wavelan ISA 2.4 GHz 2.0 (half length ISA card, frequency selectable) + o Above cards with the optional DES encryption feature + +"wavelan_cs" driver (old Pcmcia Wavelan) +------------------- + o Config : Network device -> PCMCIA network -> + Pcmcia Wireless LAN -> AT&T/Lucent WaveLAN + o Location : .../drivers/net/pcmcia/wavelan* + o in-line doc : .../drivers/net/pcmcia/wavelan_cs.h + o on-line doc : + http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html + + This is the driver for the PCMCIA version of the first +generation of the Wavelan, now discontinued. The device is 2 Mb/s, +composed of a Intel 82593 controler (totally different from the 82586) +and a Lucent Modem, and NOT 802.11 compatible. + The driver has been tested with the following hardware : + o Wavelan Pcmcia 915 MHz 2.0 (Pcmcia card + separate + modem/antenna block) + o Wavelan Pcmcia 2.4 GHz 2.0 (Pcmcia card + separate + modem/antenna block) + +"wvlan_cs" driver (Wavelan IEEE, GPL) +----------------- + o Config : Not yet in kernel + o Location : Pcmcia package 3.1.10+ + o on-line doc : http://www.fasta.fh-dortmund.de/users/andy/wvlan/ + + This is the driver for the current generation of Wavelan IEEE, +which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11 +Mb/s, with or without encryption, all implemented in Lucent specific +DSP (the Hermes). + This is a GPL full source PCMCIA driver (ISA is just a Pcmcia +card with ISA-Pcmcia bridge). + +"wavelan2_cs" driver (Wavelan IEEE, binary) +-------------------- + o Config : Not yet in kernel + o Location : ftp://sourceforge.org/pcmcia/contrib/ + + This driver support exactly the same hardware as the previous +driver, the main difference is that it is based on a binary library +and supported by Lucent. + + I hope it clears the confusion ;-) + + Jean |