Merge with Linux 2.4.0-test9. Please check DECstation, I had a number

of rejects to fixup while integrating Linus patches.  I also found
that this kernel will only boot SMP on Origin; the UP kernel freeze
soon after bootup with SCSI timeout messages.  I commit this anyway
since I found that the last CVS versions had the same problem.

38 files changed, 2962 insertions, 924 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index 9b0e67bf1..c12ed2e6d 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -25,7 +25,10 @@ document.
 Smotrite file <http://oblom.rnc.ru/linux/kernel/Changes.ru>, yavlyaushisya
 russkim perevodom dannogo documenta.
 
-Last updated: August 15, 2000
+Visite <http://www2.adi.uam.es/~ender/tecnico/> para obtener la traducción
+al español de este documento en varios formatos.
+
+Last updated: August 28, 2000
 
 Chris Ricker (kaboom@gatech.edu or chris.ricker@genetics.utah.edu).
 
@@ -44,10 +47,10 @@ with pcmcia-cs.
 
 o  Gnu C                  2.7.2.3                 # gcc --version
 o  Gnu make               3.77                    # make --version
-o  binutils               2.9.1.0.22              # ld -v
+o  binutils               2.9.1.0.25              # ld -v
 o  util-linux             2.10o                   # kbdrate -v
-o  modutils               2.3.13                  # insmod -V
-o  e2fsprogs              1.18                    # /sbin/tune2fs --version
+o  modutils               2.3.15                  # insmod -V
+o  e2fsprogs              1.18                    # tune2fs --version
 o  pcmcia-cs              3.1.19                  # cardmgr -V
 o  PPP                    2.4.0                   # pppd --version
 o  isdn4k-utils           3.1beta7                # isdnctrl 2>&1|grep version
@@ -257,16 +260,16 @@ Binutils
 ------------
 o  <ftp://ftp.valinux.com/pub/support/hjl/binutils/2.9.1/binutils-2.9.1.0.25.tar.gz>
 
-2.9.5 series
+2.10 series
 ------------
-o  <ftp://ftp.valinux.com/pub/support/hjl/binutils/binutils-2.9.5.0.46.tar.bz2>
+o  <ftp://ftp.valinux.com/pub/support/hjl/binutils/binutils-2.10.0.24.tar.bz2>
 
 System utilities
 ****************
 
 Util-linux
 ----------
-o  <ftp://ftp.win.tue.nl/pub/linux-local/util-linux/util-linux-2.10o.tar.gz>
+o  <ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/util-linux-2.10o.tar.gz>
 
 Ksymoops
 --------
@@ -274,7 +277,7 @@ o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3>
 
 Modutils
 --------
-o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.13.tar.gz>
+o  <ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3/modutils-2.3.15.tar.gz>
 
 Mkinitrd
 --------
@@ -291,7 +294,7 @@ o  <http://linux.msede.com/lvm/>
 
 Pcmcia-cs
 ---------
-o  <ftp://projects.sourceforge.org/pub/pcmcia/pcmcia-cs-3.1.19.tar.gz>
+o  <ftp://pcmcia-cs.sourceforge.org/pub/pcmcia-cs/pcmcia-cs-3.1.19.tar.gz>
 
 Jade
 ----
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index 153a6878e..27df3b63c 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -1088,22 +1088,25 @@ CONFIG_BLK_DEV_IDEDOUBLER
 
 Support for PowerMac IDE devices (must also enable IDE)
 CONFIG_BLK_DEV_IDE_PMAC
-  No help for CONFIG_BLK_DEV_IDE_PMAC
+  This driver provides support for the built-in IDE controller on most
+  of the recent Apple Power Macintoshes and PowerBooks.
+  If unsure, say Y.
 
 PowerMac IDE DMA support
 CONFIG_BLK_DEV_IDEDMA_PMAC
-  No help for CONFIG_BLK_DEV_IDEDMA_PMAC
+  This option allows the driver for the built-in IDE controller on
+  Power Macintoshes and PowerBooks to use DMA (direct memory access)
+  to transfer data to and from memory.  Saying Y is safe and improves
+  performance.
 
 Use DMA by default
-CONFIG_IDEDMA_PMAC_AUTO
-  Prior to kernel version 2.1.112, Linux used to automatically use
-  DMA for IDE drives and chipsets which support it. Due to concerns
-  about a couple of cases where buggy hardware may have caused damage,
-  the default is now to NOT use DMA automatically. To revert to the
-  previous behaviour, say Y to this question.
-
-  If you suspect your hardware is at all flakey, say N here.
-  Do NOT email the IDE kernel people regarding this issue!
+CONFIG_BLK_DEV_IDEDMA_PMAC_AUTO
+  This option allows the driver for the built-in IDE controller on
+  Power Macintoshes and PowerBooks to use DMA automatically, without
+  it having to be explicitly enabled.  This option is provided because
+  of concerns about a couple of cases where using DMA on buggy PC
+  hardware may have caused damage.  Saying Y should be safe on all
+  Apple machines.
 
 Macintosh Quadra/Powerbook IDE interface support
 CONFIG_BLK_DEV_MAC_IDE
@@ -4910,6 +4913,14 @@ CONFIG_PHONE
   it as a module, say M here and read Documentation/modules.txt. The
   module will be called phonedev.o.
 
+Compaq Smart Array support
+CONFIG_BLK_CPQ_CISS_DA
+   This is the driver for Compaq Smart Array controllers.
+   Everyone using these boards should say Y here.
+   See "linux/Documentation/cciss.txt" for the current list of
+   boards supported by this driver, and for further information
+   on the use of this driver.
+
 QuickNet Internet LineJack/PhoneJack support
 CONFIG_PHONE_IXJ
   Say M if you have a telephony card manufactured by Quicknet
@@ -5358,9 +5369,10 @@ CONFIG_AIC7XXX_RESET_DELAY
 IBM ServeRAID Support
 CONFIG_SCSI_IPS
   This is support for the IBM ServeRAID hardware RAID controllers.
-  
-  Please consult the SCSI-HOWTO, available from
-  http://www.linuxdoc.org/docs.html#howto . 
+  See http://www.developer.ibm.com/welcome/netfinity/serveraid.html
+  for more information.  If this driver does not work correctly
+  without modification please contact the author by email at
+  ipslinux@us.ibm.com.
 
   You can build this driver as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want),
@@ -7864,6 +7876,9 @@ CONFIG_COMX
   and using COMX interfaces. Further info on these cards can be found
   at http://www.itc.hu or <info@itc.hu>.
 
+  You must say Y to "/proc file system support" (CONFIG_PROC_FS) to
+  use this driver.
+
   If you want to compile this as a module, say M and read
   Documentation/modules.txt. The module will be called comx.o.
 
@@ -7903,6 +7918,25 @@ CONFIG_COMX_HW_MIXCOM
   Documentation/modules.txt. The module will be called
   comx-hw-mixcom.o.
 
+i810 TCO support
+CONFIG_I810_TCO
+  Hardware driver for the TCO timer built into the Intel i810 and i815
+  chipset family. The TCO (Total Cost of Ownership) timer is a watchdog
+  timer that will reboot the machine after it's second expiration. The
+  expiration time can be configured by commandline argument
+  "i810_margin=<n>" where <n> is the counter initial value. It is
+  decremented every 0.6 secs, the default is 50 which gives a timeout
+  of 30 seconds and one minute until reset.
+
+  On some motherboards the driver may fail to reset the chipset's
+  NO_REBOOT flag which prevents the watchdog from rebooting the machine.
+  If this is the case you will get a kernel message like
+  "i810tco init: failed to reset NO_REBOOT flag".
+
+  If you want to compile this as a module, say M and read
+  Documentation/modules.txt. The module will be called
+  i810-tco.o.
+  
 MultiGate Cisco-HDLC and synchronous PPP protocol support
 CONFIG_COMX_PROTO_PPP
   Cisco-HDLC and synchronous PPP protocol driver for all MultiGate
@@ -8133,8 +8167,10 @@ CONFIG_NI65
   module, say M here and read Documentation/modules.txt as well as
   Documentation/networking/net-modules.txt.
 
-RealTek 8129 (not 8019/8029!) support (EXPERIMENTAL)
+RealTek 8129 (not 8019/8029/8139!) support (EXPERIMENTAL)
 CONFIG_RTL8129
+  This is NOT for RTL-8139 cards.  Instead, select the 8139too driver
+  (CONFIG_8139TOO).
   This is a driver for the Fast Ethernet PCI network cards based on
   the RTL8129 chip. If you have one of those, say Y and
   read the Ethernet-HOWTO, available from
@@ -8257,6 +8293,11 @@ CONFIG_SK98LIN
   - SK-9844 (dual link   1000Base-SX)
   - SK-9821 (single link 1000Base-T)
   - SK-9822 (dual link   1000Base-T)
+  - SK-9861 (single link Volition connector)
+  - SK-9862 (dual link   Volition connector)
+  The driver also supports the following adapters from Allied Telesyn:
+  - AT2970...
+
   The dual link adapters support a link-failover feature.
   Read Documentation/networking/sk98lin.txt for information about
   optional driver parameters.
@@ -8663,6 +8704,18 @@ CONFIG_EEXPRESS
   Documentation/networking/net-modules.txt. The module will be called
   eexpress.o.
 
+Packet Engines Hamachi GNIC-II support
+CONFIG_HAMACHI
+  If you have a Gigabit Ethernet card of this type, say Y and read
+  the Ethernet-HOWTO, available from
+  http://www.linuxdoc.org/docs.html#howto .
+
+  If you want to compile this as a module ( = code which can be
+  inserted in and removed from the running kernel whenever you want),
+  say M here and read Documentation/modules.txt as well as
+  Documentation/networking/net-modules.txt. The module will be called
+  hamachi.o.
+
 HP PCLAN+ (27247B and 27252A) support
 CONFIG_HPLAN_PLUS
   If you have a network (Ethernet) card of this type, say Y and read
@@ -8986,23 +9039,31 @@ CONFIG_ES3210
   module, say M here and read Documentation/modules.txt as well as
   Documentation/networking/net-modules.txt.
 
-SMC EtherPower II (EXPERIMENTAL)
+SMC EtherPower II
 CONFIG_EPIC100
-  If you have an SMC EtherPower II 9432 PCI Ethernet network card
-  which is based on the SMC83c170, say Y and read the Ethernet-HOWTO,
-  available from http://www.linuxdoc.org/docs.html#howto .
-
-  This driver is also available as a module ( = code which can be
-  inserted in and removed from the running kernel whenever you want).
-  The module will be called epic100.o. If you want to compile it as a
-  module, say M here and read Documentation/modules.txt as well as
-  Documentation/networking/net-modules.txt.
+  This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
+  which is based on the SMC83c17x (EPIC/100).
+  More specific information and updates are available from
+  http://www.scyld.com/network/epic100.html
 
 SGI Seeq ethernet controller support
 CONFIG_SGISEEQ
   Say Y here if you have an Seeq based Ethernet network card. This is
   used in many Silicon Graphics machines.
 
+Sundance "Alta" PCI Ethernet support
+CONFIG_SUNDANCE
+  This driver is for the Sundance "Alta" chip.
+  More specific information and updates are available from
+  http://www.scyld.com/network/sundance.html
+
+Winbond W89c840 PCI Ethernet support
+CONFIG_WINBOND_840
+  This driver is for the Winbond W89c840 chip.  It also works with
+  the TX9882 chip on the Compex RL100-ATX board.
+  More specific information and updates are available from
+  http://www.scyld.com/network/drivers.html
+
 Zenith Z-Note support (EXPERIMENTAL)
 CONFIG_ZNET
   The Zenith Z-Note notebook computer has a built-in network
@@ -9960,10 +10021,24 @@ CONFIG_USB_WMFORCE
   The module will be called wmforce.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
 
+Use input layer for ADB devices
+CONFIG_INPUT_ADBHID
+  Say Y here if you want to have ADB (Apple Desktop Bus) HID devices
+  such as keyboards, mice, joysticks, or graphic tablets handled by the
+  input layer.  If you say Y here, make sure to say Y to the
+  corresponding drivers "Keyboard support" (CONFIG_INPUT_KEYBDEV),
+  "Mouse Support" (CONFIG_INPUT_MOUSEDEV) and "Event interface support"
+  (CONFIG_INPUT_EVDEV) as well.
+
+  If you say N here, you still have the option of using the old ADB
+  keyboard and mouse drivers.
+
+  If unsure, say Y.
+
 Keyboard support
 CONFIG_INPUT_KEYBDEV
-  Say Y here if you want your USB HID keyboard to be able to serve as
-  a system keyboard.
+  Say Y here if you want your USB HID keyboard (or an ADB keyboard
+  handled by the input layer) to be able to serve as a system keyboard.
 
   This driver is also available as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want).
@@ -9972,10 +10047,11 @@ CONFIG_INPUT_KEYBDEV
 
 Mouse support
 CONFIG_INPUT_MOUSEDEV
-  Say Y here if you want your USB HID mouse to be accessible as
-  char devices 13:32+ - /dev/input/mouseX and 13:63 - /dev/input/mice
-  as an emulated PS/2 mouse.  That way, all user space programs will
-  be able to use your mouse.
+  Say Y here if you want your USB HID mouse (or ADB mouse handled by
+  the input layer) to be accessible as char devices 13:32+ -
+  /dev/input/mouseX and 13:63 - /dev/input/mice as an emulated ImPS/2
+  mouse.  That way, all user space programs will be able to use your
+  mouse.
   
   If unsure, say Y.
 
@@ -10010,8 +10086,8 @@ CONFIG_INPUT_JOYDEV
 
 Event interface support
 CONFIG_INPUT_EVDEV
-  Say Y here if you want your USB HID device events be accessible
-  under char device 13:64+ - /dev/inputX in a generic way.
+  Say Y here if you want your USB or ADB HID device events be accessible
+  under char device 13:64+ - /dev/input/eventX in a generic way.
   This is the future ...
 
 USB Scanner support
@@ -10226,7 +10302,8 @@ USB ADMtek Pegasus-based ethernet device support
 CONFIG_USB_PEGASUS
   Say Y if you want to use your USB ethernet device. Supported
   cards until now are:
-    ADMtek AN986 (eval. board)
+    ADMtek AN986 Pegasus (eval. board)
+    ADMtek ADM8511 Pegasus II (eval. board)
     Accton 10/100
     Billington USB-100
     Corega FEter USB-TX
@@ -10236,6 +10313,8 @@ CONFIG_USB_PEGASUS
     LANEED Ethernet LD-USB/TX
     SMC 202
     SOHOware NUB Ethernet
+    
+  Any Pegasus II based board also are supported.
   If you have devices with vendor IDs other than noted above
   you should add them in the driver code and send a message
   to me (petkan@dce.bg) for update.
@@ -11290,6 +11369,21 @@ CONFIG_SMB_FS
   want), say M here and read Documentation/modules.txt. The module
   will be called smbfs.o. Most people say N, however.
 
+use nls by default
+CONFIG_SMB_NLS_DEFAULT
+  Enabling this will make smbfs use nls translations by default. You
+  need to specify the local charset (CONFIG_NLS_DEFAULT) in the nls
+  settings and you need to give the default nls for the SMB server as
+  CONFIG_SMB_NLS_REMOTE.
+
+  The nls settings can be changed at mount time, if your smbmount
+  supports that, using the codepage and iocharset parameters.
+
+  Currently no smbmount distributed with samba supports this, it is
+  assumed future versions will. In the meantime you can get an
+  unofficial patch for samba 2.0.7 from:
+  http://www.hojdpunkten.ac.se/054/samba/index.html
+
 nls support setting
 CONFIG_SMB_NLS_REMOTE
   This setting allows you to specify a default value for which
@@ -15406,6 +15500,42 @@ CONFIG_PMAC_PBOOK
   have it autoloaded. The act of removing the module shuts down the
   sound hardware for more power savings.
 
+Mac-on-Linux support
+CONFIG_MOL
+  This option enables low-level support for Mac-on-Linux.
+  MOL lets you run MacOS and Linux simultaneously. Please
+  visit <http://www.maconlinux.org> for more information.
+  If unsure, say Y.
+
+ADB raw keycode support
+CONFIG_MAC_ADBKEYCODES
+  This provides support for sending raw ADB keycodes to console
+  devices.  This is the default up to 2.4.0, but in future this may be
+  phased out in favor of generic Linux keycodes. If you say Y here, you
+  can dynamically switch via the
+      /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
+  sysctl and with the "keyboard_sends_linux_keycodes=" kernel argument.
+  
+  If unsure, say Y here.
+
+Mouse button 2+3 emulation support
+CONFIG_MAC_EMUMOUSEBTN
+  This provides generic support for emulating the 2nd and 3rd mouse
+  button with keypresses. If you say Y here, the emulation is still
+  disabled by default. The emulation is controlled by these sysctl entries:
+      /proc/sys/dev/mac_hid/mouse_button_emulation
+      /proc/sys/dev/mac_hid/mouse_button2_keycode
+      /proc/sys/dev/mac_hid/mouse_button3_keycode
+
+Enhanced Real Time Clock Support
+CONFIG_PPC_RTC
+  If you say Y here and create a character special file /dev/rtc with
+  major number 10 and minor number 135 using mknod ("man mknod"), you
+  will get access to the real time clock (or hardware clock) built 
+  into your computer.
+  
+  If unsure, say Y here.
+
 Support for Open Firmware device tree in /proc
 CONFIG_PROC_DEVICETREE
   This option adds a device-tree directory under /proc which contains
@@ -15896,12 +16026,18 @@ CONFIG_BLK_CPQ_DA
 # ARM options
 #
 ARM System type
-CONFIG_ARCH_ARC
+CONFIG_ARCH_ARCA5K
   This selects what ARM system you wish to build the kernel for. It
   also selects to some extent the CPU type. If you are unsure what
   to set this option to, please consult any information supplied with
   your system.
 
+2MB physical memory
+CONFIG_PAGESIZE_16
+  Say Y here if your Archimedes or A5000 system has only 2MB of
+  memory, otherwise say N.  The resulting kernel will not run on a
+  machine with 4MB of memory.
+
 Include support for the CATS
 CONFIG_ARCH_CATS
   Say Y here if you intend to run this kernel on the CATS.
@@ -16001,6 +16137,27 @@ CONFIG_SA1100_VICTOR
   http://www.visuaide.com/pagevictor.en.html for information on
   this system.
 
+Support ARM610 processor
+CONFIG_CPU_ARM6
+  Say Y here if you wish to include support for the ARM610 processor.
+
+Support ARM710 processor
+CONFIG_CPU_ARM7
+  Say Y here if you wish to include support for the ARM710 processor.
+
+Support StrongARM(R) SA-110 processor
+CONFIG_CPU_SA110
+  Say Y here if you wish to include support for the Intel(R)
+  StrongARM(R) SA-110 processor.
+
+Support ARM720 processor
+CONFIG_CPU_ARM720
+  Say Y here if you wish to include support for the ARM720 processor.
+
+Support ARM920
+CONFIG_CPU_ARM920
+  Say Y here if you wish to include support for the ARM920 processor.
+
 Math emulation
 CONFIG_NWFPE
   Say Y to include the NWFPE floating point emulator in the kernel.
@@ -16115,8 +16272,8 @@ CONFIG_ALIGNMENT_TRAP
 
 21285 serial port support
 CONFIG_SERIAL_21285
-  If you have a machine based on a 21285 (Footbridge) StrongARM/PCI
-  bridge you can enable its onboard serial port by enabling this
+  If you have a machine based on a 21285 (Footbridge) StrongARM(R)/
+  PCI bridge you can enable its onboard serial port by enabling this
   option. The device has major ID 4, minor 64.
 
 Console on 21285 serial port
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index 5dd11a173..0ffccdee2 100644
--- a/Documentation/DMA-mapping.txt
+++ b/Documentation/DMA-mapping.txt
@@ -345,13 +345,13 @@ to use the pci_dma_sync_*() interfaces.
 			 * the DMA transfer with the CPU first
 			 * so that we see updated contents.
 			 */
-			pci_dma_sync_single(cp->pdev, cp->rx_buf, cp->rx_len,
+			pci_dma_sync_single(cp->pdev, cp->rx_dma, cp->rx_len,
 					    PCI_DMA_FROMDEVICE);
 
 			/* Now it is safe to examine the buffer. */
 			hp = (struct my_card_header *) cp->rx_buf;
 			if (header_is_ok(hp)) {
-				pci_unmap_single(cp->pdev, cp->rx_buf, cp->rx_len,
+				pci_unmap_single(cp->pdev, cp->rx_dma, cp->rx_len,
 						 PCI_DMA_FROMDEVICE);
 				pass_to_upper_layers(cp->rx_buf);
 				make_and_setup_new_rx_buf(cp);
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 855282be6..113aa69fa 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -55,11 +55,11 @@ mcabook.sgml: mcabook.tmpl $(TOPDIR)/arch/i386/kernel/mca.c
 	$(TOPDIR)/scripts/docgen $(TOPDIR)/arch/i386/kernel/mca.c \
 		<mcabook.tmpl >mcabook.sgml
 
-videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/char/videodev.c
-	$(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/char/videodev.c \
+videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/media/video/videodev.c
+	$(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \
 		<videobook.tmpl >videobook.sgml
 
-APISOURCES :=	$(TOPDIR)/drivers/char/videodev.c \
+APISOURCES :=	$(TOPDIR)/drivers/media/video/videodev.c \
 		$(TOPDIR)/arch/i386/kernel/mca.c \
 		$(TOPDIR)/arch/i386/kernel/mtrr.c \
 		$(TOPDIR)/drivers/char/misc.c \
@@ -72,6 +72,7 @@ APISOURCES :=	$(TOPDIR)/drivers/char/videodev.c \
 		$(TOPDIR)/drivers/sound/sound_firmware.c \
 		$(TOPDIR)/drivers/net/wan/syncppp.c \
 		$(TOPDIR)/drivers/net/wan/z85230.c \
+		$(TOPDIR)/fs/locks.c \
 		$(TOPDIR)/fs/devfs/base.c \
 		$(TOPDIR)/kernel/pm.c \
 		$(TOPDIR)/kernel/ksyms.c \
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index c5d7ca3fc..0c445af2f 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -61,6 +61,10 @@
      <sect1><title>Registration and Superblocks</title>
 !Efs/super.c
      </sect1>
+     <sect1><title>File Locks</title>
+!Efs/locks.c
+!Ifs/locks.c
+     </sect1>
   </chapter>
 
   <chapter id="netcore">
@@ -137,7 +141,7 @@
 
   <chapter id="viddev">
      <title>Video4Linux</title>
-!Edrivers/char/videodev.c
+!Edrivers/media/video/videodev.c
   </chapter>
 
   <chapter id="snddev">
diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
index 597413bf9..2174af671 100644
--- a/Documentation/DocBook/videobook.tmpl
+++ b/Documentation/DocBook/videobook.tmpl
@@ -1657,7 +1657,7 @@ static struct video_buffer capture_fb;
 
   <chapter id="pubfunctions">
      <title>Public Functions Provided</title>
-!Edrivers/char/videodev.c
+!Edrivers/media/video/videodev.c
   </chapter>
 
 </book>
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
new file mode 100644
index 000000000..29c597385
--- /dev/null
+++ b/Documentation/SubmittingDrivers
@@ -0,0 +1,112 @@
+Submitting Drivers For The Linux Kernel
+---------------------------------------
+
+This document is intended to explain how to submit device drivers to the
+Linux 2.2 and 2.4test kernel trees. Note that if you are interested in video
+card drivers you should probably talk to XFree86 (http://wwww.xfree86.org) 
+instead.
+
+Allocating Device Numbers
+-------------------------
+
+Major and minor numbers for devices are allocated by the Linux assigned name
+and number authority (currently better known as H Peter Anvin). The
+site is http://www.lanana.org/. This also deals with allocating numbers for
+devices that are not going to be submitted to the mainstream kernel.
+
+If you don't use assigned numbers then when you device is submitted it will
+get given an assigned number even if that is different from values you may
+have shipped to customers before.
+
+Who To Submit Drivers To
+------------------------
+
+Linux 2.0:
+	No new drivers are accepted for this kernel tree
+
+Linux 2.2:
+	If the code area has a general maintainer then please submit it to
+	the maintainer listed in MAINTAINERS in the kernel file. If the
+	maintainer does not respond or you cannot find the appropriate
+	maintainer then please contact Alan Cox <alan@lxorguk.ukuu.org.uk>
+
+Linux 2.4test:
+	This kernel tree is under active development. The same rules apply
+	as 2.2 but you may wish to submit your driver via linux-kernel (see
+	resources) and follow that list to track changes in API's. These
+	should no longer be occuring as we are now in a code freeze.
+	The final contact point for Linux 2.4 submissions is 	
+	<torvalds@transmeta.com>.
+
+What Criteria Determine Acceptance
+----------------------------------
+
+Licensing:	The code must be released to us under the GNU public license. 
+		We don't insist on any kind of exclusively GPL licensing,
+		and if you wish the driver to be useful to other communities
+		such as BSD you may well wish to release under multiple
+		licenses.
+
+Interfaces:	If your driver uses existing interfaces and behaves like
+		other drivers in the same class it will be much more likely
+		to be accepted than if it invents gratuitous new ones. 
+		If you need to implement a common API over Linux and NT
+		drivers do it in userspace.
+
+Code:		Please use the Linux style of code formatting as documented
+		in Documentation/CodingStyle. If you have sections of code
+		that need to be in other formats, for example because they
+		are shared with a windows driver kit and you want to
+		maintain them just once seperate them out nicely and note
+		this fact.
+
+Portability:	Pointers are not always 32bits, people do not all have
+		floating point and you shouldn't use inline x86 assembler in 
+		your driver without careful thought. Pure x86 drivers
+		generally are not popular. If you only have x86 hardware it 
+		is hard to test portability but it is easy to make sure the
+		code can easily be made portable.
+
+Clarity:	It helps if anyone can see how to fix the driver. It helps
+		you because you get patches not bug reports. If you submit a
+		driver that intentionally obfuscates how the hardware works
+		it will go in the bitbucket.
+
+Control:	In general if there is active maintainance of a driver by
+		the author then patches will be redirected to them unless 
+		they are totally obvious and without need of checking.
+		If you want to be the contact and update point for the
+		driver it is a good idea to state this in the comments.
+
+What Criteria Do Not Determine Acceptance
+-----------------------------------------
+
+Vendor:		Being the hardware vendor and maintaining the driver is
+		often a good thing. If there is a stable working driver from
+		other people already in the tree don't expect 'we are the
+		vendor' to get your driver chosen. Ideally work with the 
+		existing driver author to build a single perfect driver.
+
+Author:		It doesn't matter if a large Linux company wrote the driver,
+		or you did. Nobody has any special access to the kernel
+		tree. Anyone who tells you otherwise isn't telling the
+		whole story.
+
+
+Resources
+---------
+
+Linux kernel master tree:
+	ftp.kernel.org:/pub/linux/kernel/...
+
+Linux kernel mailing list:		
+	linux-kernel@vger.kernel.org
+	[mail majordomo@vger.kernel.org to subscribe]
+
+Kernel traffic:
+	Weekly summary of kernel list activity (much easier to read)
+	[http://kt.linuxcare.com/kernel-traffic]
+
+Linux USB project:
+	http://sourceforge.net/projects/linux-usb/
+
diff --git a/Documentation/arm/README b/Documentation/arm/README
index 95e9bddd5..96bdfe3e2 100644
--- a/Documentation/arm/README
+++ b/Documentation/arm/README
@@ -52,6 +52,36 @@ Bug reports etc
   the problem, what you were doing, etc.
 
 
+Include files
+-------------
+
+  Several new include directories have been created under include/asm-arm,
+  which are there to reduce the clutter in the top-level directory.  These
+  directories, and their purpose is listed below:
+
+   arch-*	machine/platform specific header files
+   hardware	driver-internal ARM specific data structures/definitions
+   mach		descriptions of generic ARM to specific machine interfaces
+   proc-*	processor dependent header files (currently only two
+		categories)
+
+
+Machine/Platform support
+------------------------
+
+  The ARM tree contains support for a lot of different machine types.  To
+  continue supporting these differences, it has become necessary to split
+  machine-specific parts by directory.  For this, the machine category is
+  used to select which directories and files get included (we will use
+  $(MACHINE) to refer to the category)
+
+  To this end, we now have arch/arm/mach-$(MACHINE) directories which are
+  designed to house the non-driver files for a particular machine (eg, PCI,
+  memory management, architecture definitions etc).  For all future
+  machines, there should be a corresponding include/asm-arm/arch-$(MACHINE)
+  directory.
+
+
 Modules
 -------
 
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 578dcb315..3d003463d 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -47,7 +47,7 @@ changes occur:
 
 	This interface is used to handle whole address space
 	page table operations such as what happens during
-	fork, exit, and exec.
+	fork, and exec.
 
 3) void flush_tlb_range(struct mm_struct *mm,
 			unsigned long start, unsigned long end)
@@ -272,7 +272,7 @@ Here is the new interface:
 	for example, uses this technique.
 
 	The "address" parameter tells the virtual address where the
-	user has this page mapped.
+	user will ultimately this page mapped.
 
 	If D-cache aliasing is not an issue, these two routines may
 	simply call memcpy/memset directly and do nothing more.
diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
new file mode 100644
index 000000000..56d4d7a6a
--- /dev/null
+++ b/Documentation/cciss.txt
@@ -0,0 +1,47 @@
+This driver is for Compaq's SMART Array Controllers.
+
+Supported Cards:
+----------------
+
+This driver is known to work with the following cards:
+
+	* SA 5300
+
+If notes are not already created in the /dev/cciss directory
+
+# mkdev.cciss [ctlrs]
+
+Where ctlrs is the number of controllers you have (defaults to 1 if not
+specified).
+
+Device Naming:
+--------------
+
+You need some entries in /dev for the cciss device.  The mkdev.cciss script
+can make device nodes for you automatically.  Currently the device setup
+is as follows:
+
+Major numbers:
+	104	cciss0	
+	105	cciss1	
+	106	cciss2 
+	etc...
+
+Minor numbers:
+        b7 b6 b5 b4 b3 b2 b1 b0
+        |----+----| |----+----|
+             |           |
+             |           +-------- Partition ID (0=wholedev, 1-15 partition)
+             |
+             +-------------------- Logical Volume number
+
+The suggested device naming scheme is:
+/dev/cciss/c0d0			Controller 0, disk 0, whole device
+/dev/cciss/c0d0p1		Controller 0, disk 0, partition 1
+/dev/cciss/c0d0p2		Controller 0, disk 0, partition 2
+/dev/cciss/c0d0p3		Controller 0, disk 0, partition 3
+
+/dev/cciss/c1d1			Controller 1, disk 1, whole device
+/dev/cciss/c1d1p1		Controller 1, disk 1, partition 1
+/dev/cciss/c1d1p2		Controller 1, disk 1, partition 2
+/dev/cciss/c1d1p3		Controller 1, disk 1, partition 3
diff --git a/Documentation/cpqarray.txt b/Documentation/cpqarray.txt
index a2c9a0862..620e12b6e 100644
--- a/Documentation/cpqarray.txt
+++ b/Documentation/cpqarray.txt
@@ -17,6 +17,7 @@ This driver is known to work with the following cards:
 	* SA 4200
 	* SA 4250ES
 	* SA 431
+	* RAID LC2 Controller
 
 It should also work with some really old Disk array adapters, but I am
 unable to test against these cards:
diff --git a/Documentation/digiboard.txt b/Documentation/digiboard.txt
index b25fc158a..6a2da7fe6 100644
--- a/Documentation/digiboard.txt
+++ b/Documentation/digiboard.txt
@@ -8,11 +8,6 @@ The Digiboard Driver for Linux supports the following boards:
  switches) You can use up to 4 cards with this driver and it should work
  on other architectures than intel also.
 
-In case you have problems with this version (1.6.1) of this driver, please
-email directly to me as I made the last update. It you have a report about
-running it on other architectures than intel, email me, so I can document
-it here.
-
 A version of this driver has been taken by Digiboard to make a driver
 software package which supports also PC/Xem cards and newer PCI cards
 but it doesn't support the old PC/Xi cards and it isn't yet ported to
@@ -154,22 +149,12 @@ Sources of Information
 ----------------------
 
 Please contact digi directly digilnux@dgii.com. Forward any information of
-general interest to me.
+general interest to me so that I can include it on the webpage.
 
-Web page (mainly of historical interest): http://lameter.com/digi
+Web page: http://lameter.com/digi
 
 Christoph Lameter (christoph@lameter.com) Aug 14, 2000.
 
-Supporting Tools
-----------------
-
-Some (old) tools and more detailed information can be found at
-ftp://lameter.com/digi
-
-The "ditty" tool described in the Digiboard Manuals for other Unixes
-is also available.
-
-
 Device file creation
 --------------------
 
diff --git a/Documentation/fb/sa1100fb.txt b/Documentation/fb/sa1100fb.txt
new file mode 100644
index 000000000..b8de95aca
--- /dev/null
+++ b/Documentation/fb/sa1100fb.txt
@@ -0,0 +1,39 @@
+[This file is cloned from VesaFB/matroxfb]
+
+What is sa1100fb?
+=================
+
+This is a driver for a graphic framebuffer for the SA-1100 LCD
+controller.
+
+Configuration
+==============
+
+For most common passive displays, giving the option
+
+video=sa1100:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
+
+on the kernel command line should be enough to configure the
+controller. The bits per pixel (bpp) value should be 4, 8, 12, or
+16. LCCR values are display-specific and should be computed as
+documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
+displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
+are used for the lower panel.
+
+For active displays or displays requiring additional configuration
+(controlling backlights, powering on the LCD, etc.), the command line
+options may not be enough to configure the display. Adding sections to
+sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
+sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
+will probably be necessary.
+
+Accepted options:
+
+bpp:<value>	Configure for <value> bits per pixel
+lccr0:<value>	Configure LCD control register 0 (11.7.3)
+lccr1:<value>	Configure LCD control register 1 (11.7.4)
+lccr2:<value>	Configure LCD control register 2 (11.7.5)
+lccr3:<value>	Configure LCD control register 3 (11.7.6)
+
+--
+Mark Huang <mhuang@livetoy.com>
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
new file mode 100644
index 000000000..a5e34bb1f
--- /dev/null
+++ b/Documentation/filesystems/ext2.txt
@@ -0,0 +1,224 @@
+
+The Second Extended Filesystem
+==============================
+
+ext2 was originally released in January 1993.  Written by R\'emy Card,
+Theodore Ts'o and Stephen Tweedie, it was a major rewrite of the
+Extended Filesystem.  It is currently (February 1999) the predominant
+filesystem in use by Linux.  There are also implementations available
+for NetBSD, FreeBSD, the GNU HURD, Windows 95/98/NT, OS/2 and RISC OS.
+
+Options
+=======
+
+When mounting an ext2 filesystem, the following options are accepted.
+Defaults are marked with (*).
+
+bsddf			(*)	Makes `df' act like BSD.
+minixdf				Makes `df' act like Minix.
+
+check=none, nocheck		Perform no checks upon the filesystem.
+check=normal		(*)	Perform normal checks on the filesystem.
+check=strict			Perform extra checks on the filesystem.
+
+debug				For developers only.
+
+errors=continue		(*)	Keep going on a filesystem error.
+errors=remount-ro		Remount the filesystem read-only on an error.
+errors=panic			Panic and halt the machine if an error occurs.
+
+grpid, bsdgroups		Give objects the same group ID as their parent.
+nogrpid, sysvgroups	(*)	New objects have the group ID of their creator.
+
+resuid=n			The user which may use the reserved blocks.
+resgid=n			The group which may use the reserved blocks. 
+
+sb=n				Use alternate superblock at this location.
+
+grpquota,noquota,quota,usrquota	Quota options are silently ignored by ext2.
+
+
+Specification
+=============
+
+ext2 shares many properties with traditional Unix filesystems.  It has
+the concepts of blocks, inodes and directories.  It has space in the
+specification for Access Control Lists (ACLs), fragments, undeletion and
+compression though these are not yet implemented (some are available as
+separate patches).  There is also a versioning mechanism to allow new
+features (such as journalling) to be added in a maximally compatible
+manner.
+
+Blocks
+------
+
+The space in the device or file is split up into blocks.  These are
+a fixed size, of 1024, 2048 or 4096 bytes, which is decided when the
+filesystem is created.  Smaller blocks mean less wasted space per file,
+but require slightly more accounting overhead.
+
+Blocks are clustered into block groups in order to reduce fragmentation
+and minimise the amount of head seeking when reading a large amount of
+consecutive data.  Each block group has a descriptor and the array of
+descriptors is stored immediately after the superblock.  Two blocks at
+the start of each group are reserved for the block usage bitmap and
+the inode usage bitmap which show which blocks and inodes are used.
+Since each bitmap fits in a block, this means that the maximum size of
+a block group is 8 times the size of a block.
+
+The first (non-reserved) blocks in the block group are designated as
+the inode table for the block and the remainder are the data blocks.
+The block allocation algorithm attempts to allocate data blocks in the
+same block group as the inode which contains them.
+
+The Superblock
+--------------
+
+The superblock contains all the information about the configuration of
+the filing system.  It is stored in block 1 of the filesystem (numbering
+from 0) and it is essential to mounting it.  Since it is so important,
+backup copies of the superblock are stored in block groups throughout
+the filesystem.  The first revision of ext2 stores a copy at the start
+of every block group.  Later revisions can store a copy in only some
+block groups to reduce the amount of redundancy on large filesystems.
+The groups chosen are 0, 1 and powers of 3, 5 and 7.
+
+The information in the superblock contains fields such as how many
+inodes and blocks are in the filesystem and how many are unused, how
+many inodes and blocks are in a block group, when the filesystem was
+mounted, when it was modified, what version of the filesystem it is
+(see the Revisions section below) and which OS created it.
+
+If the revision of the filesystem is recent enough then there are extra
+fields, such as a volume name, a unique identifier, the inode size,
+support for compression, block preallocation and creating fewer backup
+superblocks.
+
+All fields in the superblock (as in all other ext2 structures) are stored
+on the disc in little endian format, so a filesystem is portable between
+machines without having to know what machine it was created on.
+
+Inodes
+------
+
+The inode (index node) is the fundamental concept in the ext2 filesystem.
+Each object in the filesystem is represented by an inode.  The inode
+structure contains pointers to the filesystem blocks which contain the
+data held in the object and all of the metadata about an object except
+its name.  The metadata about an object includes the permissions, owner,
+group, flags, size, number of blocks used, access time, change time,
+modification time, deletion time, number of links, fragments, version
+(for NFS) and ACLs.
+
+There are several reserved fields which are currently unused in the inode
+structure and several which are overloaded.  One field is used for the
+directory ACL if the inode is a directory and for the top 32 bits of
+the file size if the inode is a regular file.  The translator field is
+unused under Linux, but is used by the HURD to reference the inode of
+a program which will be used to interpret this object.  The HURD also
+has larger permissions, owner and group fields, so it uses some of the
+other unused by Linux fields to store the extra bits.
+
+There are pointers to the first 12 blocks which contain the file's data
+in the inode.  There is a pointer to an indirect block (which contains
+pointers to the next set of blocks), a pointer to a doubly-indirect
+block (which contains pointers to indirect blocks) and a pointer to a
+trebly-indirect block (which contains pointers to doubly-indirect blocks).
+
+The flags field contains some ext2-specific flags which aren't catered
+for by the standard chmod flags.  These flags can be listed with
+lsattr and changed with the chattr command.  There are flags for secure
+deletion, undeletable, compression, synchronous updates, immutability,
+append-only, dumpable, no-atime, and btree directories.  Not all of
+these are supported yet.
+
+Directories
+-----------
+
+A directory is a filesystem object and has an inode just like a file.
+It is a specially formatted file containing records which associate
+each name with an inode number.  Later revisions of the filesystem also
+encode the type of the object (file, directory, symlink, device, fifo,
+socket) in the directory entry for speed.  The current implementation
+of ext2 uses a linked list in directories; a planned enhancement will
+use btrees instead.  The current implementation also never shrinks
+directories once they have grown to accommodate more files.
+
+Special files
+-------------
+
+Symbolic links are also filesystem objects with inodes.  They deserve
+special mention because the data for them is stored within the inode
+itself if the symlink is less than 60 bytes long.  It uses the fields
+which would normally be used to store the pointers to blocks to store
+the data.  This is a worthwhile optimisation to make as it does not then
+take up a block, and most symlinks are less than 60 characters long.
+
+Character and block special devices never have data blocks assigned to
+them.  Instead, their device number is stored in the inode, again reusing
+the fields which would be used to point to the blocks.
+
+Revisions
+---------
+
+The revisioning mechanism used in ext2 is sophisticated.  The revisioning
+mechanism is not supported by version 0 (EXT2_GOOD_OLD_REV) of ext2 but
+was introduced in version 1.  There are three 32-bit fields, one for
+compatible features, one for read-only compatible features and one for
+incompatible features.
+
+Reserved Space
+--------------
+
+In ext2, there is a mechanism for reserving a certain number of blocks
+for a particular user (normally the super-user).  This is intended to
+allow for the system to continue functioning even if a user fills up
+all the available space.  It also keeps the filesystem from filling up
+entirely which helps combat fragmentation.
+
+Filesystem check
+----------------
+
+At boot time, most systems run a consistency check (e2fsck) on their
+filesystems.  The superblock of the ext2 filesystem contains several
+fields which indicate whether fsck should actually run (since checking
+the filesystem at boot can take a long time if it is large).  fsck will
+run if the filesystem was not unmounted without errors, if the maximum
+mount count has been exceeded or if the maximum time between checks has
+been exceeded.
+
+Metadata
+--------
+
+It is frequently claimed that the ext2 implementation of writing
+asynchronous metadata is faster than the ffs synchronous metadata
+scheme but less reliable.  Both methods are equally resolvable by their
+respective fsck programs.
+
+If you're exceptionally paranoid, there are 3 ways of making metadata
+writes synchronous:
+
+per-file if you have the source: use the O_SYNC argument to open()
+per-file if you don't have the source: use chattr +S
+per-filesystem: mount -o sync
+
+the first and last are not ext2 specific but do force the metadata to
+be written synchronously.
+
+References
+==========
+
+The kernel source	file:/usr/src/linux/fs/ext2/
+Design & Implementation	http://khg.redhat.com/HyperNews/get/fs/ext2intro.html
+Compression		http://debs.fuller.edu/e2compr/
+ACL support		ftp://tsx-11.mit.edu/pub/linux/ALPHA/ext2fs
+updated ACL work	http://aerobee.informatik.uni-bremen.de/acl_eng.html
+e2fsprogs 		ftp://tsx-11.mit.edu/pub/linux/packages/ext2fs
+
+Implementations for:
+OS/2			http://perso.wanadoo.fr/matthieu.willm/ext2-os2/
+Windows 95		http://www.yipton.demon.co.uk/
+Windows NT		http://www.cyco.nl/~andreys/ext2fsnt/
+			http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm
+DOS client		ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/
+RISC OS client		ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index c2314e0f1..5dcf02cfe 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -619,11 +619,6 @@ allocated file  handles  come close to the maximum, but the number of actually
 used ones  is  far  behind,  you've  encountered  a peak in your usage of file
 handles and you don't need to increase the maximum.
 
-However, there is still a per process limit of open files, which unfortunately
-can't be changed that easily. It is set to 1024 by default. To change this you
-have to  edit  the files limits.h and fs.h in the kernel source tree. Finally,
-change the definition of NR_OPEN and recompile the kernel.
-
 inode-state, inode-nr and inode-max
 -----------------------------------
 
diff --git a/Documentation/kbuild/00-INDEX b/Documentation/kbuild/00-INDEX
index b72963abb..398393455 100644
--- a/Documentation/kbuild/00-INDEX
+++ b/Documentation/kbuild/00-INDEX
@@ -6,3 +6,5 @@ commands.txt
 	- overview of kbuild commands
 config-language.txt
 	- specification of Config Language, the language in Config.in files
+makefiles.txt
+	- developer information for linux kernel makefiles
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
new file mode 100644
index 000000000..206272a47
--- /dev/null
+++ b/Documentation/kbuild/makefiles.txt
@@ -0,0 +1,1226 @@
+Linux Kernel Makefiles
+2000-September-14
+Michael Elizabeth Chastain, <mec@shout.net>
+
+
+
+=== Table of Contents
+
+This document describes the Linux kernel Makefiles.
+
+  1  Overview
+  2  Who does what
+  3  Makefile language
+  4  Variables passed down from the top
+  5  The structure of an arch Makefile
+     5.1  Architecture-specific variables
+     5.2  Vmlinux build variables
+     5.3  Post-vmlinux goals
+     5.4  Mandatory arch-specific goals
+  6  The structure of a subdirectory Makefile
+     6.1  Comments
+     6.2  Goal definitions
+     6.3  Adapter section
+     6.4  Rules.make section
+     6.5  Special rules
+  7  Rules.make variables
+     7.1  Subdirectories
+     7.2  Object file goals
+     7.3  Library file goals
+     7.4  Loadable module goals
+     7.5  Multi-part modules
+     7.6  Compilation flags
+     7.7  Miscellaneous variables
+  8  New-style variables
+  9  Compatibility with Linux Kernel 2.2
+ 10  Credits
+
+
+=== 1 Overview
+
+The Makefiles have five parts:
+
+    Makefile: the top Makefile.
+    .config: the kernel configuration file.
+    arch/*/Makefile: the arch Makefiles.
+    Subdirectory Makefiles: there are about 300 of these.
+    Rules.make: the common rules for all subdirectory Makefiles.
+
+The top Makefile reads the .config file, which comes from the
+kernel configuration process.
+
+The top Makefile is responsible for building two major products: vmlinux
+(the resident kernel image) and modules (any module files).  It builds
+these goals by recursively descending into the subdirectories of the
+kernel source tree.  The list of subdirectories which are visited depends
+upon the kernel configuration.
+
+The top Makefile textually includes an arch Makefile with the name
+arch/$(ARCH)/Makefile.  The arch Makefile supplies architecture-specific
+information to the top Makefile.
+
+Each subdirectory has a Makefile which carries out the commands passed
+down from above.  The subdirectory Makefile uses information from the
+.config file to construct various file lists, and then it textually
+includes the common rules in Rules.make.
+
+Rules.make defines rules which are common to all the subdirectory
+Makefiles.  It has a public interface in the form of certain variable
+lists.  It then declares rules based on those lists.
+
+
+
+=== 2 Who does what
+
+People have four different relationships with the kernel Makefiles.
+
+*Users* are people who build kernels.  These people type commands such as
+"make menuconfig" or "make bzImage".  They usually do not read or edit
+any kernel Makefiles (or any other source files).
+
+*Normal developers* are people who work on features such as device
+drivers, file systems, and network protocols.  These people need to
+maintain the subdirectory Makefiles for the subsystem that they are
+working on.  In order to do this effectively, they need some overall
+knowledge about the kernel Makefiles, plus detailed knowledge about the
+public interface for Rules.make.
+
+*Arch developers* are people who work on an entire architecture, such
+as sparc or ia64.  Arch developers need to know about the arch Makefiles
+as well as subdirectory Makefiles.
+
+*Kbuild developers* are people who work on the kernel build system itself.
+These people need to know about all aspects of the kernel Makefiles.
+
+This document is aimed towards normal developers and arch developers.
+
+
+
+=== 3 Makefile language
+
+The kernel Makefiles are designed to run with Gnu Make.  The Makefiles
+use only the documented features of Gnu Make, but they do use many
+Gnu extensions.
+
+Gnu Make supports elementary list-processing functions.  The kernel
+Makefiles use a novel style of list building and manipulation with few
+"if" statements.
+
+Gnu Make has two assignment operators, ":=" and "=".  ":=" performs
+immediate evaluation of the right-hand side and stores an actual string
+into the left-hand side.  "=" is like a formula definition; it stores the
+right-hand side in an unevaluated form and then evaluates this form each
+time the left-hand side is used.
+
+There are some cases where "=" is appropriate.  Usually, though, ":="
+is the right choice.
+
+All of the examples in this document were drawn from actual kernel
+sources.  The examples have been reformatted (white space changed, lines
+split), but are otherwise exactly the same.
+
+
+
+=== 4 Variables passed down from the top
+
+The top Makefile exports the following variables:
+
+    VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
+
+	These variables define the current kernel version.  A few arch
+	Makefiles actually use these values directly; they should use
+	$(KERNELRELEASE) instead.
+
+	$(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic
+	three-part version number, such as "2", "4", and "0".  These three
+	values are always numeric.
+
+	$(EXTRAVERSION) defines an even tinier sublevel for pre-patches
+	or additional patches.	It is usually some non-numeric string
+	such as "-pre4", and is often blank.
+
+    KERNELRELEASE
+
+	$(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable
+	for constructing installation directory names or showing in
+	version strings.  Some arch Makefiles use it for this purpose.
+
+    ARCH
+
+	This variable defines the target architecture, such as "i386",
+	"arm", or "sparc".   Many subdirectory Makefiles test $(ARCH)
+	to determine which files to compile.
+
+	By default, the top Makefile sets $(ARCH) to be the same as the
+	host system system architecture.  For a cross build, a user may
+	override the value of $(ARCH) on the command line:
+
+	    make ARCH=m68k ...
+
+    TOPDIR, HPATH
+	
+	$(TOPDIR) is the path to the top of the kernel source tree.
+	Subdirectory Makefiles need this so that they can include
+	$(TOPDIR)/Rules.make.
+
+	$(HPATH) is equal to $(TOPDIR)/include.  A few arch Makefiles
+	need to use this to do special things using include files.
+
+    SUBDIRS
+
+	$(SUBDIRS) is a list of directories which the top Makefile
+	enters in order to build either vmlinux or modules.  The actual
+	directories in $(SUBDIRS) depend on the kernel configuration.
+	The top Makefile defines this variable, and the arch Makefile
+	extends it.
+
+    HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
+    LINKFLAGS
+
+	$(HEAD), $(CORE_FILES), $(NETWORKS), $(DRIVERS), and $(LIBS)
+	specify lists of object files and libraries to be linked into
+	vmlinux.
+	
+	The files in $(HEAD) are linked first in vmlinux.
+
+	$(LINKFLAGS) specifies the flags to build vmlinux.
+
+	The top Makefile and the arch Makefile jointly define these
+	variables.  The top Makefile defines $(CORE_FILES), $(NETWORKS),
+	$(DRIVERS), and $(LIBS).  The arch Makefile defines $(HEAD)
+	and $(LINKFLAGS), and extends $(CORE_FILES) and $(LIBS).
+
+	Note: there are more names here than necessary.  $(NETWORKS),
+	$(DRIVERS), and even $(LIBS) could be subsumed into $(CORE_FILES).
+
+    CPP, CC, AS, LD, AR, NM, STRIP, OBJCOPY, OBJDUMP
+    CPPFLAGS, CFLAGS, CFLAGS_KERNEL, MODFLAGS, AFLAGS, LDFLAGS
+    PERL
+    GENKSYMS
+
+	These variables specify the commands and flags that Rules.make
+	uses to build goal files from source files.
+
+	$(CFLAGS_KERNEL) contains extra C compiler flags used to compile
+	resident kernel code.
+
+	$(MODFLAGS) contains extra C compiler flags used to compile code
+	for loadable kernel modules.  In the future, this flag may be
+	renamed to the more regular name $(CFLAGS_MODULE).
+
+	$(AFLAGS) contains assembler flags.
+
+	$(GENKSYMS) contains the command used to generate kernel symbol
+	signatures when CONFIG_MODVERSIONS is enabled.	The genksyms
+	command comes from the modutils package.
+
+    CROSS_COMPILE
+
+	This variable is a prefix path for other variables such as $(CC),
+	$(AS), and $(LD).  The arch Makefiles sometimes use and set this
+	variable explicitly.  Subdirectory Makefiles don't need to worry
+	about it.
+
+	The user may override $(CROSS_COMPILE) on the command line if
+	desired.
+
+    HOSTCC, HOSTCFLAGS
+
+	These variables define the C compiler and C compiler flags to
+	be used for compiling host side programs.  These are separate
+	variables because the target architecture can be different from
+	the host architecture.
+
+	If your Makefile compiles and runs a program that is executed
+	during the course of building the kernel, then it should use
+	$(HOSTCC) and $(HOSTCFLAGS).
+
+	For example, the subdirectory drivers/pci has a helper program
+	named gen-devlist.c.  This program reads a list of PCI ID's and
+	generates C code in the output files classlist.h and devlist.h.
+
+	Suppose that a user has an i386 computer and wants to build a
+	kernel for an ia64 machine.  Then the user would use an ia64
+	cross-compiler for most of the compilation, but would use a
+	native i386 host compiler to compile drivers/pci/gen-devlist.c.
+
+	For another example, kbuild helper programs such as
+	scripts/mkdep.c and scripts/lxdialog/*.c are compiled with
+	$(HOSTCC) rather than $(CC).
+
+    ROOT_DEV, SVGA_MODE, RAMDISK
+
+	End users edit these variables to specify certain information
+	about the configuration of their kernel.  These variables
+	are ancient!  They are also specific to the i386 architecture.
+	They really should be replaced with CONFIG_* options.
+
+    MAKEBOOT
+
+	This variable is defined and used only inside the main arch
+	Makefiles.  The top Makefile should not export it.
+
+    INSTALL_PATH
+
+	This variable defines a place for the arch Makefiles to install
+	the resident kernel image and System.map file.
+
+    INSTALL_MOD_PATH, MODLIB
+
+	$(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module
+	installation.  This variable is not defined in the Makefile but
+	may be passed in by the user if desired.
+
+	$(MODLIB) specifies the directory for module installation.
+	The top Makefile defines $(MODLIB) to
+	$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE).  The user may
+	override this value on the command line if desired.
+
+    CONFIG_SHELL
+
+	This variable is private between Makefile and Rules.make.
+	Arch makefiles and subdirectory Makefiles should never use this.
+
+    MODVERFILE
+
+	An internal variable.  This doesn't need to be exported, as it
+	is never used outside of the top Makefile.
+
+    MAKE, MAKEFILES
+
+	Some variables internal to Gnu Make.
+
+	$(MAKEFILES) in particular is used to force the arch Makefiles
+	and subdirectory Makefiles to read $(TOPDIR)/.config without
+	including it explicitly.  (This was an implementation hack and
+	could be fixed).
+
+
+
+=== 5 The structure of an arch Makefile
+
+
+
+--- 5.1 Architecture-specific variables
+
+The top Makefile includes one arch Makefile file, arch/$(ARCH)/Makefile.
+This section describes the functions of the arch Makefile.
+
+An arch Makefile extends some of the top Makefile's variables with
+architecture-specific values.
+
+    SUBDIRS
+
+	The top Makefile defines $(SUBDIRS).  The arch Makefile extends
+	$(SUBDIRS) with a list of architecture-specific directories.
+
+	Example:
+
+		# arch/alpha/Makefile
+
+		SUBDIRS := $(SUBDIRS) arch/alpha/kernel arch/alpha/mm \
+		           arch/alpha/lib arch/alpha/math-emu
+
+	This list may depend on the configuration:
+
+		# arch/arm/Makefile
+
+		ifeq ($(CONFIG_ARCH_ACORN),y)
+		SUBDIRS         += drivers/acorn
+		...
+		endif
+
+    CPP, CC, AS, LD, AR, NM, STRIP, OBJCOPY, OBJDUMP
+    CPPFLAGS, CFLAGS, CFLAGS_KERNEL, MODFLAGS, AFLAGS, LDFLAGS
+
+	The top Makefile defines these variables, and the arch Makefile
+	extends them.
+
+	Many arch Makefiles dynamically run the target C compiler to
+	probe what options it supports:
+
+		# arch/i386/Makefile
+
+		# only work around strength reduction bug(s) on older gcc versions
+		CFLAGS += $(shell if ! $(CC) -march=i486 -S -o /dev/null \
+			  -xc /dev/null >/dev/null 2>&1; \
+			  then echo "-fno-strength-reduce"; fi)
+
+		# prevent gcc from keeping the stack 16 byte aligned
+		CFLAGS += $(shell if $(CC) -mpreferred-stack-boundary=2 \
+			  -S -o /dev/null -xc /dev/null >/dev/null 2>&1; \
+			  then echo "-mpreferred-stack-boundary=2"; fi)
+
+	And, of course, $(CFLAGS) can depend on the configuration:
+
+		# arch/i386/Makefile
+
+		ifdef CONFIG_M386
+		CFLAGS += $(shell if $(CC) -march=i386 -S -o /dev/null \
+			  -xc /dev/null >/dev/null 2>&1; \
+			  then echo "-march=i386"; else echo "-m386"; fi)
+		endif
+
+		ifdef CONFIG_M486
+		CFLAGS += $(shell if $(CC) -march=i486 -S -o /dev/null \
+			  -xc /dev/null >/dev/null 2>&1; \
+			  then echo "-march=i486"; else echo "-m486"; fi)
+		endif
+
+		ifdef CONFIG_M586
+		CFLAGS += $(shell if $(CC) -march=i586 -S -o /dev/null \
+			  -xc /dev/null >/dev/null 2>&1; \
+			  then echo "-march=i586"; fi)
+		endif
+
+	Some arch Makefiles redefine the compilation commands in order
+	to add architecture-specific flags:
+
+		# arch/s390/Makefile
+
+		LD=$(CROSS_COMPILE)ld -m elf_s390
+		OBJCOPY=$(CROSS_COMPILE)objcopy -O binary -R .note -R .comment -S
+
+
+
+--- 5.2 Vmlinux build variables
+
+An arch Makefile co-operates with the top Makefile to define variables
+which specify how to build the vmlinux file.  Note that there is no
+corresponding arch-specific section for modules; the module-building
+machinery is all architecture-independent.
+
+    HEAD, CORE_FILES, LIBS
+    LINKFLAGS
+
+	The top Makefile defines the architecture-independent core of
+	thse variables, and the arch Makefile extends them.  Note that the
+	arch Makefile defines (not just extends) $(HEAD) and $(LINKFLAGS).
+
+	Example:
+
+		# arch/m68k/Makefile
+
+		ifndef CONFIG_SUN3
+		LINKFLAGS = -T $(TOPDIR)/arch/m68k/vmlinux.lds
+		else
+		LINKFLAGS = -T $(TOPDIR)/arch/m68k/vmlinux-sun3.lds -N
+		endif
+
+		...
+
+		ifndef CONFIG_SUN3
+		HEAD := arch/m68k/kernel/head.o
+		else
+		HEAD := arch/m68k/kernel/sun3-head.o
+		endif
+
+		SUBDIRS += arch/m68k/kernel arch/m68k/mm arch/m68k/lib
+		CORE_FILES := arch/m68k/kernel/kernel.o arch/m68k/mm/mm.o $(CORE_FILES)
+		LIBS += arch/m68k/lib/lib.a
+
+
+
+--- 5.3 Post-vmlinux goals
+
+An arch Makefile specifies goals that take the vmlinux file, compress
+it, wrap it in bootstrapping code, and copy the resulting files somewhere.
+This includes various kinds of installation commands.
+
+These post-vmlinux goals are not standardized across different
+architectures.  Here is a list of these goals and the architectures
+that support each of them (as of kernel version 2.4.0-test6-pre5):
+
+    balo		mips
+    bootimage		alpha
+    bootpfile		alpha, ia64
+    bzImage		i386, m68k
+    bzdisk		i386
+    bzlilo		i386
+    compressed		i386, m68k, mips, mips64, sh
+    dasdfmt		s390
+    Image		arm
+    image		s390
+    install		arm, i386
+    lilo		m68k
+    msb			alpha, ia64
+    my-special-boot	alpha, ia64
+    orionboot		mips
+    rawboot		alpha
+    silo		s390
+    srmboot		alpha
+    tftpboot.img	sparc, sparc64
+    vmlinux.64		mips64
+    vmlinux.aout	sparc64
+    zImage		arm, i386, m68k, mips, mips64, ppc, sh
+    zImage.initrd	ppc
+    zdisk		i386, mips, mips64, sh
+    zinstall		arm
+    zlilo		i386
+    znetboot.initrd	ppc
+
+
+
+--- 5.4 Mandatory arch-specific goals
+
+An arch Makefile must define the following arch-specific goals.
+These goals provide arch-specific actions for the corresponding goals
+in the top Makefile:
+
+    archclean		clean
+    archdep		dep
+    archmrproper	mrproper
+
+
+
+=== 6 The structure of a subdirectory Makefile
+
+A subdirectory Makefile has five sections.
+
+
+
+--- 6.1 Comments
+
+The first section is a comment header.  Just write what you would
+write if you were editing a C source file, but use "# ..." instead of
+"/* ... */".  Historically, many anonymous people have edited kernel
+Makefiles without leaving any change histories in the header; comments
+from them would have been valuable.
+
+
+
+--- 6.2 Goal definitions
+
+The second section is a bunch of definitions that are the heart of the
+subdirectory Makefile.  These lines define the files to be built, any
+special compilation options, and any subdirectories to be recursively
+entered.  The declarations in these lines depend heavily on the kernel
+configuration variables (CONFIG_* symbols).
+
+In some Makefiles ("old-style Makefiles"), the second section looks
+like this:
+
+	# drivers/parport/Makefile
+	ifeq ($(CONFIG_PARPORT_PC),y)
+	  LX_OBJS += parport_pc.o
+	else
+	  ifeq ($(CONFIG_PARPORT_PC),m)
+	    MX_OBJS += parport_pc.o
+	  endif
+	endif
+
+In most Makefiles ("new-style Makefiles"), the second section looks
+like this:
+
+	# drivers/block/Makefile
+	obj-$(CONFIG_MAC_FLOPPY)	+= swim3.o
+	obj-$(CONFIG_BLK_DEV_FD)	+= floppy.o
+	obj-$(CONFIG_AMIGA_FLOPPY)	+= amiflop.o
+	obj-$(CONFIG_ATARI_FLOPPY)	+= ataflop.o
+
+The new-style Makefiles are more compact and easier to get correct
+for certain features (such as CONFIG_* options that enable more than
+one file).  If you have a choice, please write a new-style Makefile.
+
+
+
+--- 6.3 Adapter section
+
+The third section is an adapter section.  In old-style Makefiles, this
+third section is not present.  In new-style Makefiles, the third section
+contains boilerplate code which converts from new-style variables to
+old-style variables.  This is because Rules.make processes only the
+old-style variables.
+
+
+
+--- 6.4 Rules.make section
+
+The fourth section is the single line:
+
+	include $(TOPDIR)/Rules.make
+
+
+
+--- 6.5 Special rules
+
+The fifth section contains any special Makefile rules needed that are
+not available through the common rules in Rules.make.
+
+
+
+=== 7 Rules.make variables
+
+The public interface of Rules.make consists of the following variables:
+
+
+
+--- 7.1 Subdirectories
+
+    ALL_SUB_DIRS, SUB_DIRS, MOD_IN_SUB_DIRS, MOD_SUB_DIRS
+
+	$(ALL_SUB_DIRS) is an unconditional list of *all* the
+	subdirectories in a given directory.  This list should not depend
+	on the kernel configuration.
+
+	$(SUB_DIRS) is a list of subdirectories which may contribute code
+	to vmlinux.  This list may depend on the kernel configuration.
+
+	$(MOD_SUB_DIRS) and $(MOD_IN_SUB_DIRS) are lists of subdirectories
+	which may build kernel modules.  Both names have exactly the
+	same meaning.  (In version 2.2 and earlier kernels, these
+	variables had different meanings -- hence the different names).
+
+	For new code, $(MOD_SUB_DIRS) is recommended and $(MOD_IN_SUB_DIRS)
+	is deprecated.
+
+	Example:
+
+		# fs/Makefile
+		ALL_SUB_DIRS = coda minix ext2 fat msdos vfat proc isofs nfs \
+			       umsdos ntfs hpfs sysv smbfs ncpfs ufs efs affs \
+			       romfs autofs hfs lockd nfsd nls devpts devfs \
+			       adfs partitions qnx4 udf bfs cramfs openpromfs \
+			       autofs4 ramfs jffs
+		SUB_DIRS :=
+
+		...
+
+		ifeq ($(CONFIG_EXT2_FS),y)
+		SUB_DIRS += ext2
+		else
+		  ifeq ($(CONFIG_EXT2_FS),m)
+		  MOD_SUB_DIRS += ext2
+		  endif
+		endif
+
+		ifeq ($(CONFIG_CRAMFS),y)
+		SUB_DIRS += cramfs
+		else
+		  ifeq ($(CONFIG_CRAMFS),m)
+		  MOD_SUB_DIRS += cramfs
+		  endif
+		endif
+
+	Example:
+
+		# drivers/net/Makefile
+		SUB_DIRS     := 
+		MOD_SUB_DIRS :=
+		MOD_IN_SUB_DIRS :=
+		ALL_SUB_DIRS := $(SUB_DIRS) fc hamradio irda pcmcia tokenring \
+				wan sk98lin arcnet skfp tulip appletalk
+
+		...
+
+		ifeq ($(CONFIG_IRDA),y)
+		SUB_DIRS += irda
+		MOD_IN_SUB_DIRS += irda
+		else
+		  ifeq ($(CONFIG_IRDA),m)
+		  MOD_IN_SUB_DIRS += irda
+		  endif
+		endif
+
+		ifeq ($(CONFIG_TR),y)
+		SUB_DIRS += tokenring
+		MOD_IN_SUB_DIRS += tokenring
+		else
+		  ifeq ($(CONFIG_TR),m)
+		  MOD_IN_SUB_DIRS += tokenring
+		  endif
+		endif
+
+
+
+--- 7.2 Object file goals
+
+    O_TARGET, O_OBJS, OX_OBJS
+
+	The subdirectory Makefile specifies object files for vmlinux in
+	the lists $(O_OBJS) and $(OX_OBJS).  These lists depend on the
+	kernel configuration.
+
+	The "X" in "OX_OBJS" stands for "eXport".  Files in $(OX_OBJS)
+	may use the EXPORT_SYMBOL macro to define public symbols which
+	loadable kernel modules can see.  Files in $(O_OBJS) may not use
+	EXPORT_SYMBOL (and you will get a funky error message if you try).
+
+	[Yes, it's kludgy to do this by hand.  Yes, you can define all
+	your objects as $(OX_OBJS) whether they define symbols or not;
+	but then you will notice a lot of extra compiles when you edit
+	any source file.  Blame CONFIG_MODVERSIONS for this.]
+
+	Rules.make compiles all the $(O_OBJS) and $(OX_OBJS) files.
+	It then calls "$(LD) -r" to merge these files into one .o file
+	with the name $(O_TARGET).  This $(O_TARGET) name also appears
+	in the top Makefile.
+
+	The order of files in $(O_OBJS) and $(OX_OBJS) is significant.
+	All $(OX_OBJS) files come first, in the order listed, followed by
+	all $(O_OBJS) files, in the order listed.  Duplicates in the lists
+	are allowed: the first instance will be linked into $(O_TARGET)
+	and succeeding instances will be ignored.  (Note: Rules.make may
+	emit warning messages for duplicates, but this is harmless).
+
+	Example:
+
+		# arch/alpha/kernel/Makefile
+		O_TARGET := kernel.o
+		O_OBJS   := entry.o traps.o process.o osf_sys.o irq.o \
+			    irq_alpha.o signal.o setup.o ptrace.o time.o \
+			    semaphore.o
+		OX_OBJS  := alpha_ksyms.o
+
+		ifdef CONFIG_SMP
+		O_OBJS   += smp.o irq_smp.o
+		endif
+
+		ifdef CONFIG_PCI
+		O_OBJS   += pci.o pci_iommu.o
+		endif
+
+	Even if a subdirectory Makefile has an $(O_TARGET), the .config
+	options still control whether or not its $(O_TARGET) goes into
+	vmlinux.  See the $(M_OBJS) example below.
+
+
+
+--- 7.3 Library file goals
+
+    L_TARGET, L_OBJS, LX_OBJS
+
+	These names are similar to the O_* names.  Once again, $(L_OBJS)
+	and $(LX_OBJS) specify object files for the resident kernel;
+	once again, the lists depend on the current configuration; and
+	once again, the files that call EXPORT_SYMBOL go on the "X" list.
+
+	The difference is that "L" stands for "Library".  After making
+	$(L_OBJS) and $(LX_OBJS), Rules.make uses the "$(AR) rcs" command
+	to put these files into an archive file (a library) with the
+	name $(L_TARGET).  This name also appears in the top Makefile.
+
+	Example:
+
+		# arch/i386/lib/Makefile
+		L_TARGET = lib.a
+		L_OBJS  = checksum.o old-checksum.o delay.o \
+			usercopy.o getuser.o putuser.o iodebug.o
+
+		ifdef CONFIG_X86_USE_3DNOW
+		L_OBJS += mmx.o
+		endif
+
+		ifdef CONFIG_HAVE_DEC_LOCK
+		L_OBJS += dec_and_lock.o
+		endif
+
+	The order of files in $(L_OBJS) and $(LX_OBJS) is not significant.
+	Duplicates in the lists are allowed.  (Note: Rules.make may emit
+	warning messages for duplicates, but this is harmless).
+
+	A subdirectory Makefile can specify either an $(O_TARGET),
+	an $(L_TARGET), or both.  Here is a discussion of the differences.
+
+	All of the files in an $(O_TARGET) are guaranteed to appear in
+	the resident vmlinux image.  In an $(L_TARGET), only the files
+	that satisfy undefined symbol references from other files will
+	appear in vmlinux.
+
+	In a conventional link process, the linker processes some
+	object files and creates a list of unresolved external symbols.
+	The linker then looks in a set of libraries to resolve these
+	symbols.  Indeed, the Linux kernel used to be linked this way,
+	with the bulk of the code stored in libraries.
+
+	But vmlinux contains two types of object files that cannot be
+	fetched out of libraries this way:
+
+	    (1) object files that are purely EXPORT_SYMBOL definitions
+	    (2) object files that use module_init or __initcall initializers
+		(instead of an initialization routine called externally)
+
+	These files contain autonomous initializer sections which provide
+	code and data without being explicitly called.	If these files
+	were stored in $(L_TARGET) libraries, the linker would fail
+	to include them in vmlinux.  Thus, most subdirectory Makefiles
+	specify an $(O_TARGET) and do not use $(L_TARGET).
+
+	Other considerations: $(O_TARGET) leads to faster re-link times
+	during development activity, but $(L_TARGET) gives better error
+	messages for unresolved symbols.
+
+
+
+--- 7.4 Loadable module goals
+
+    M_OBJS, MX_OBJS
+
+	$(M_OBJS) and $(MX_OBJS) specify object files which are built
+	as loadable kernel modules.  As usual, the "X" in $(MX_OBJS)
+	stands for "eXport"; source files that use EXPORT_SYMBOL must
+	appear on an $(MX_OBJS) list.
+
+	A module may be built from one source file or several source
+	files.	In the case of one source file, the subdirectory
+	Makefile simply adds the file to either $(M_OBJS) or $(MX_OBJS),
+	as appropriate.
+
+	Example:
+
+		# drivers/net/irda/Makefile
+		ifeq ($(CONFIG_IRTTY_SIR),y)
+		L_OBJS += irtty.o
+		else
+		  ifeq ($(CONFIG_IRTTY_SIR),m)
+		  M_OBJS += irtty.o
+		  endif
+		endif
+
+		ifeq ($(CONFIG_IRPORT_SIR),y)
+		LX_OBJS += irport.o
+		else
+		  ifeq ($(CONFIG_IRPORT_SIR),m)
+		  MX_OBJS += irport.o
+		  endif
+		endif
+
+	If a kernel module is built from several source files, there
+	are two ways to specify the set of source files.  One way is to
+	build a single module for the entire subdirectory.  This way is
+	popular in the file system and network protocol stacks.
+
+	Example:
+
+		# fs/ext2/Makefile
+		O_TARGET := ext2.o
+		O_OBJS   := acl.o balloc.o bitmap.o dir.o file.o fsync.o \
+			    ialloc.o inode.o ioctl.o namei.o super.o symlink.o \
+			    truncate.o
+		M_OBJS   := $(O_TARGET)
+
+	In this example, the module name will be ext2.o.  Because this
+	file has the same name has $(O_TARGET), Rules.make will use
+	the $(O_TARGET) rule to build ext2.o: it will run "$(LD) -r"
+	on the list of $(O_OBJS) files.
+
+	Note that this subdirectory Makefile defines both an $(O_TARGET)
+	and an $(M_OBJS).  The control code, up in fs/Makefile, will
+	select between these two.  If CONFIG_EXT2_FS=y, then fs/Makefile
+	will build $(O_TARGET); and if CONFIG_EXT_FS=m, then fs/Makefile
+	will build $(M_OBJS) instead.  (Yes, this is a little delicate
+	and a little confusing).
+
+
+
+--- 7.5 Multi-part modules
+
+    MI_OBJS, MIX_OBJS
+
+	Some kernel modules are composed of several object files
+	linked together, but do not include every object file in their
+	subdirectory.  $(MI_OBJS) and $(MIX_OBJS) are for this case.
+
+	"M" stands for Module.
+	"I" stands for Intermediate.
+	"X", as usual, stands for "eXport symbol".
+
+	Example:
+
+		# drivers/sound/Makefile
+		gus-objs  := gus_card.o gus_midi.o gus_vol.o gus_wave.o ics2101.o
+		pas2-objs := pas2_card.o pas2_midi.o pas2_mixer.o pas2_pcm.o
+		sb-objs	  := sb_card.o
+
+		gus.o: $(gus-objs)
+			$(LD) -r -o $@ $(gus-objs)
+
+		pas2.o: $(pas2-objs)
+			$(LD) -r -o $@ $(pas2-objs)
+
+		sb.o: $(sb-objs)
+			$(LD) -r -o $@ $(sb-objs)
+
+	The kernel modules gus.o, pas2.o, and sb.o are the *composite
+	files*.  The object files gus_card.o, gus_midi.o, gus_vol.o,
+	gus_wave.o, ics2101.o, pas2_card.o, pas2_midi.o, pas2_mixer.o,
+	pas2_pcm.o, and sb_card.o are *component files*.  The component
+	files are also called *intermediate files*.
+
+	In another part of drivers/sound/Makefile (not shown), all of
+	the component files are split out.  For the resident drivers:
+	the component object files go onto $(O_OBJS) and $(OX_OBJS)
+	lists, depending on whether they export symbols or not; and the
+	composite files are never built.  For the kernel modules: the
+	component object files go onto $(MI_OBJS) and $(MIX_OBJS);
+	the composite files go onto $(M_OBJS).
+
+	The subdirectory Makefile must also specify the linking rule
+	for a multi-object-file module:
+
+		# drivers/sound/Makefile
+
+		gus.o: $(gus-objs)
+			$(LD) -r -o $@ $(gus-objs)
+
+		pas2.o: $(pas2-objs)
+			$(LD) -r -o $@ $(pas2-objs)
+
+		sb.o: $(sb-objs)
+			$(LD) -r -o $@ $(sb-objs)
+
+
+
+--- 7.6 Compilation flags
+
+    EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
+
+	$(EXTRA_CFLAGS) specifies options for compiling C files with
+	$(CC).	The options in this variable apply to all $(CC) commands
+	for files in the current directory.
+
+	Example:
+
+		# drivers/sound/emu10k1/Makefile
+		EXTRA_CFLAGS += -I.
+		ifdef DEBUG
+		    EXTRA_CFLAGS += -DEMU10K1_DEBUG
+		endif
+
+	$(EXTRA_CFLAGS) does not apply to subdirectories of the current
+	directory.  Also, it does not apply to files compiled with
+	$(HOSTCC).
+
+	This variable is necessary because the top Makefile owns the
+	variable $(CFLAGS) and uses it for compilation flags for the
+	entire tree.
+
+	$(EXTRA_AFLAGS) is a similar string for per-directory options
+	when compiling assembly language source.
+
+	Example: at the time of writing, there were no examples of
+	$(EXTRA_AFLAGS) in the kernel corpus.
+
+	$(EXTRA_LDFLAGS) and $(EXTRA_ARFLAGS) are similar strings for
+	per-directory options to $(LD) and $(AR).
+
+	Example: at the time of writing, there were no examples of
+	$(EXTRA_LDFLAGS) or $(EXTRA_ARFLAGS) in the kernel corpus.
+
+    CFLAGS_$@, AFLAGS_$@
+
+	$(CFLAGS_$@) specifies per-file options for $(CC).  The $@
+	part has a literal value which specifies the file that it's for.
+
+	Example:
+
+		# drivers/scsi/Makefile
+		CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
+		CFLAGS_gdth.o    = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
+				     -DGDTH_STATISTICS
+		CFLAGS_seagate.o =   -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
+
+	These three lines specify compilation flags for aha152x.o,
+	gdth.o, and seagate.o
+
+	$(AFLAGS_$@) is a similar feature for source files in assembly
+	languages.
+
+	Example:
+
+		# arch/arm/kernel/Makefile
+		AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
+		AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
+
+	Rules.make has a feature where an object file depends on the
+	value of $(CFLAGS_$@) that was used to compile it.  (It also
+	depends on the values of $(CFLAGS) and $(EXTRA_CFLAGS)).  Thus,
+	if you change the value of $(CFLAGS_$@) for a file, either by
+	editing the Makefile or overriding the value some other way,
+	Rules.make will do the right thing and re-compile your source
+	file with the new options.
+
+	Note: because of a deficiency in Rules.make, assembly language
+	files do not have flag dependencies.  If you edit $(AFLAGS_$@)
+	for such a file, you will have to remove the object file in order
+	to re-build from source.
+
+    LD_RFLAG
+
+	This variable is used, but never defined.  It appears to be a
+	vestige of some abandoned experiment.
+
+
+
+--- 7.7 Miscellaneous variables
+
+    IGNORE_FLAGS_OBJS
+
+	$(IGNORE_FLAGS_OBJS) is a list of object files which will not have
+	their flag dependencies automatically tracked.	This is a hackish
+	feature, used to kludge around a problem in the implementation
+	of flag dependencies.  (The problem is that flag dependencies
+	assume that a %.o file is built from a matching %.S or %.c file.
+	This is sometimes not true).
+
+    USE_STANDARD_AS_RULE
+
+	This is a transition variable.	If $(USE_STANDARD_AS_RULE)
+	is defined, then Rules.make will provide standard rules for
+	assembling %.S files into %.o files or %.s files (%.s files
+	are useful only to developers).
+
+	If $(USE_STANDARD_AS_RULE) is not defined, then Rules.make
+	will not provide these standard rules.	In this case, the
+	subdirectory Makefile must provide its own private rules for
+	assembling %.S files.
+
+	In the past, all Makefiles provided private %.S rules.	Newer
+	Makefiles should define USE_STANDARD_AS_RULE and use the standard
+	Rules.make rules.  As soon as all the Makefiles across all
+	architectures have been converted to USE_STANDARD_AS_RULE, then
+	Rules.make can drop the conditional test on USE_STANDARD_AS_RULE.
+	After that, all the other Makefiles can drop the definition of
+	USE_STANDARD_AS_RULE.
+
+
+
+=== 8 New-style variables
+
+The "new-style variables" are simpler and more powerful than the
+"old-style variables".  As a result, many subdirectory Makefiles shrank
+more than 60%.  This author hopes that, in time, all arch Makefiles and
+subdirectory Makefiles will convert to the new style.
+
+Rules.make does not understand new-style variables.  Thus, each new-style
+Makefile has a section of boilerplate code that converts the new-style
+variables into old-style variables.  There is also some mixing, where
+people define most variables using "new style" but then fall back to
+"old style" for a few lines.
+
+    obj-y obj-m obj-n obj-
+
+	These variables replace $(O_OBJS), $(OX_OBJS), $(M_OBJS),
+	and $(MX_OBJS).
+
+	Example:
+
+		# drivers/block/Makefile
+		obj-$(CONFIG_MAC_FLOPPY)        += swim3.o
+		obj-$(CONFIG_BLK_DEV_FD)        += floppy.o
+		obj-$(CONFIG_AMIGA_FLOPPY)      += amiflop.o
+		obj-$(CONFIG_ATARI_FLOPPY)      += ataflop.o
+
+	Notice the use of $(CONFIG_...) substitutions on the left hand
+	side of an assignment operator.  This gives Gnu Make the power
+	of associative indexing!  Each of these assignments replaces
+	eight lines of code in an old-style Makefile.
+
+	After executing all of the assignments, the subdirectory
+	Makefile has built up four lists: $(obj-y), $(obj-m), $(obj-n),
+	and $(obj-).
+
+	$(obj-y) is a list of files to include in vmlinux.
+	$(obj-m) is a list of files to build as single-file modules.
+	$(obj-n) and $(obj-) are ignored.
+
+	Each list may contain duplicates items; duplicates are
+	automatically removed later.  Also, if a file appears in both
+	$(obj-y) and $(obj-m), it will automatically be removed from
+	the $(obj-m) list.
+
+	Example:
+
+		# drivers/net/Makefile
+
+		...
+		obj-$(CONFIG_OAKNET) += oaknet.o 8390.o
+		...
+		obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
+		...
+		obj-$(CONFIG_STNIC) += stnic.o 8390.o
+		...
+		obj-$(CONFIG_MAC8390) += daynaport.o 8390.o
+		...
+
+	In this example, four different drivers require the code in
+	8390.o.  If one or more of these four drivers are built into
+	vmlinux, then 8390.o will also be built into vmlinux, and will
+	*not* be built as a module -- even if another driver which needs
+	8390.o is built as a module.  (The modular driver is able to
+	use services of the 8390.o code in the resident vmlinux image).
+
+    export-objs
+
+	$(export-objs) is a list of all the files in the subdirectory
+	which potentially export symbols.  The canonical way to construct
+	this list is:
+
+	    grep -l EXPORT_SYMBOL *.c
+
+	(but watch out for sneaky files that call EXPORT_SYMBOL from an
+	included header file!)
+
+	This is a potential list, independent of the kernel configuration.
+	All files that export symbols go into $(export-objs).  The
+	boilerplate code then uses the $(export-objs) list to separate
+	the real file lists into $(*_OBJS) and $(*X_OBJS).
+
+	Experience has shown that maintaining the proper X's in an
+	old-style Makefile is difficult and error-prone.  Maintaining the
+	$(export-objs) list in a new-style Makefile is simpler and easier
+	to audit.
+
+    list-multi
+    $(foo)-objs
+
+	Some kernel modules are composed of multiple object files linked
+	together.  $(list-multi) is a list of such kernel modules.
+	This is a static list; it does not depend on the configuration.
+
+	For each kernel module in $(list-multi) there is another list
+	of all the object files which make up that module.  For a kernel
+	module named foo.o, its object file list is foo-objs.
+
+	Example:
+
+		# drivers/scsi/Makefile
+		list-multi	:= scsi_mod.o sr_mod.o initio.o a100u2w.o
+
+		...
+
+		scsi_mod-objs	:= hosts.o scsi.o scsi_ioctl.o constants.o \
+				   scsicam.o scsi_proc.o scsi_error.o \
+				   scsi_obsolete.o scsi_queue.o scsi_lib.o \
+				   scsi_merge.o scsi_dma.o scsi_scan.o \
+				   scsi_syms.o
+		sr_mod-objs	:= sr.o sr_ioctl.o sr_vendor.o
+		initio-objs	:= ini9100u.o i91uscsi.o
+		a100u2w-objs	:= inia100.o i60uscsi.o
+
+	The subdirectory Makefile puts the modules onto obj-* lists in
+	the usual configuration-dependent way:
+
+		obj-$(CONFIG_SCSI)		+= scsi_mod.o
+		obj-$(CONFIG_BLK_DEV_SR)	+= sr_mod.o
+		obj-$(CONFIG_SCSI_INITIO)	+= initio.o
+		obj-$(CONFIG_SCSI_INIA100)	+= a100u2w.o
+
+	Suppose that CONFIG_SCSI=y.  Then vmlinux needs to link in all
+	14 components of scsi_mod.o, so these components will go onto
+	$(O_OBJS) and $(OX_OBJS).  The composite file scsi_mod.o will
+	never be created.  The boilerplate conversion code produces this
+	result with a few lines of list processing commands.
+
+	Suppose that CONFIG_BLK_DEV_SR=m.  Then the 3 components
+	of sr_mod.o will linked together with "$(LD) -r" to make the
+	kernel module sr_mod.o, so these 3 components need to go onto
+	the $(MI_OBJS) and $(MIX_OBJS) lists; the composite file sr_mod.o
+	goes onto $(M_OBJS).  The boilerplate conversion code takes care
+	of this, too.
+
+	And suppose CONFIG_SCSI_INITIO=n.  Then initio.o goes onto the
+	$(obj-n) list and that's the end of it.  Its component files
+	are not compiled, and the composite file is not created.
+
+	Finally, the subdirectory Makefile needs to define rules to
+	build each multi-object kernel module from its component list.
+	Example:
+
+		# drivers/scsi/Makefile
+
+		scsi_mod.o: $(scsi_mod-objs)
+			$(LD) -r -o $@ $(scsi_mod-objs)
+
+		sr_mod.o: $(sr_mod-objs)
+			$(LD) -r -o $@ $(sr_mod-objs)
+
+		initio.o: $(initio-objs)
+			$(LD) -r -o $@ $(initio-objs)
+
+		a100u2w.o: $(a100u2w-objs)
+			$(LD) -r -o $@ $(a100u2w-objs)
+
+	These rules are very regular; it would be nice for the boilerplate
+	code or Rules.make to synthesize these rules automatically.
+	But until that happens, the subdirectory Makefile needs to define
+	these rules explicitly.
+
+    subdir-y subdir-m subdir-n subdir-
+
+	These variables replace $(ALL_SUB_DIRS), $(SUB_DIRS) and
+	$(MOD_SUB_DIRS).
+
+	Example:
+
+		# drivers/Makefile
+		subdir-$(CONFIG_PCI)		+= pci
+		subdir-$(CONFIG_PCMCIA)		+= pcmcia
+		subdir-$(CONFIG_MTD)		+= mtd
+		subdir-$(CONFIG_SBUS)		+= sbus
+
+	These variables work similar to obj-*, but are used for
+	subdirectories instead of object files.
+
+	After executing all of the assignments, the subdirectory
+	Makefile has built up four lists: $(subdir-y), $(subdir-m),
+	$(subdir-n), and $(subdir-).
+
+	$(subdir-y) is a list of directories that should be entered
+		for making vmlinux.
+	$(subdir-m) is a list of directories that should be entered
+		for making modules.
+	$(subdir-n) and $(subdir-) are only used for collecting a list
+		of all subdirectories of this directory.
+
+	Each list besides subdir-y may contain duplicates items; duplicates
+	are automatically removed later.
+
+    mod-subdirs
+
+	$(mod-subdirs) is a list of all the the subdirectories that should
+	be added to $(subdir-m), too if they appear in $(subdir-y)
+
+	Example:
+
+		# fs/Makefile
+		mod-subdirs :=	nls
+
+	This means nls should be added to (subdir-y) and $(subdir-m) if
+	CONFIG_NFS = y.
+
+
+=== 9 Compatibility with Linux Kernel 2.2
+
+Most of the information in this document also applies to 2.2, although
+there is no indication of which things have changed when.  Here are some
+hints for writing subdirectory Makefiles that are compatible with Linux
+kernel 2.2.
+
+You can write either an old-style Makefile or a new-style Makefile
+with a boilerplate adapter section.  See the 2.2 version of
+drivers/sound/Makefile for a copy of the boilerplate code.
+
+In 2.2, Rules.make makes a distinction between $(MOD_SUB_DIRS)
+and $(MOD_IN_SUB_DIRS).  If you have a single directory with no
+subdirectories, this will not matter to you.  If you have a whole
+tree, then you need to know the difference between $(MOD_SUB_DIRS)
+and $(MOD_IN_SUB_DIRS).  For example code: $(MOD_SUB_DIRS) is used
+extensively in fs/Makefile; $(MOD_IN_SUB_DIRS) is used extensively in
+drivers/net/Makefile.
+
+If you are already using MOD_LIST_NAME, go ahead and keep using it.
+If you don't already have a MOD_LIST_NAME, go ahead and keep not using
+one; your module will be a 'misc' module in 2.2.
+
+Assembly language rules were a mess in 2.2.  If you have assembly language
+files, this author recommends that you write your own explicit rules
+for each file by name.
+
+
+
+=== 10 Credits
+
+Thanks to the members of the linux-kbuild mailing list for reviewing
+drafts of this document, with particular thanks to Peter Samuelson
+and Thomas Molina.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index d3c8bbdaa..495c9a0be 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -516,6 +516,8 @@ running once the system is up.
 
 	stram_swap=	[HW]
 
+	swiotlb=        [IA-64] Number of I/O TLB slabs.
+ 
 	switches=	[HW, M68K]
 
 	sym53c416=	[HW,SCSI]
diff --git a/Documentation/mkdev.cciss b/Documentation/mkdev.cciss
new file mode 100644
index 000000000..fbbaf30a7
--- /dev/null
+++ b/Documentation/mkdev.cciss
@@ -0,0 +1,40 @@
+#!/bin/sh
+# Script to create device nodes for SMART array controllers
+# Usage:
+#	mkdev.cciss [num controllers] [num log volumes] [num partitions]
+#
+# With no arguments, the script assumes 1 controller, 16 logical volumes,
+# and 16 partitions/volume, which is adequate for most configurations.
+#
+# If you had 5 controllers and were planning on no more than 4 logical volumes
+# each, using a maximum of 8 partitions per volume, you could say:
+#
+# mkdev.cciss 5 4 8
+#
+# Of course, this has no real benefit over "mkdev.cciss 5" except that it
+# doesn't create so many device nodes in /dev/cciss.
+
+NR_CTLR=${1-1}
+NR_VOL=${2-16}
+NR_PART=${3-16}
+
+if [ ! -d /dev/cciss ]; then
+	mkdir -p /dev/cciss
+fi
+
+C=0; while [ $C -lt $NR_CTLR ]; do
+	MAJ=`expr $C + 104`
+	D=0; while [ $D -lt $NR_VOL ]; do
+		P=0; while [ $P -lt $NR_PART ]; do
+			MIN=`expr $D \* 16 + $P`
+			if [ $P -eq 0 ]; then
+				mknod /dev/cciss/c${C}d${D} b $MAJ $MIN
+			else
+				mknod /dev/cciss/c${C}d${D}p${P} b $MAJ $MIN
+			fi
+			P=`expr $P + 1`
+		done
+		D=`expr $D + 1`
+	done
+	C=`expr $C + 1`
+done
diff --git a/Documentation/networking/8139too.txt b/Documentation/networking/8139too.txt
index f27811a2a..1c5c8afc9 100644
--- a/Documentation/networking/8139too.txt
+++ b/Documentation/networking/8139too.txt
@@ -1,6 +1,6 @@
 
 		"8139too" Fast Ethernet driver for Linux
-	  Improved support for RTL-8139 Fast Ethernet adapters
+	  Improved support for RTL-8139 10/100 Fast Ethernet adapters
 
 	 Copyright 2000 Jeff Garzik <jgarzik@mandrakesoft.com>
 
@@ -8,6 +8,7 @@
 	      Architectures supported (all PCI platforms):
 		    x86, Alpha AXP, PowerPC, Sparc64
 
+		    Kernel versions supported: 2.4.x
 
 
 
@@ -130,6 +131,8 @@ James Fidell, Taso Hatzi, Peter K - intrepid test team
 
 And thanks to every supporter free software.
 
+(see top of 8139too.c for further credits and kudos)
+
 
 
 Submitting Bug Reports
@@ -156,38 +159,59 @@ 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.
+2) ethtool support
 
-3) PPC platform has stability problems.
+3) PPC platform has stability problems. (XXX: verify this is still true)
 
 4) Sparc64 platform not tested at all.
 
-5) Identify and fix "rx wedge" when ping flooded. (WIP)
-
-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)  (WIP)
 
 9) Better documentation.  (patches welcome)
 
-10) (rtl8139-diag modified from Becker version, DONE)
-User-mode (or maybe optional /proc) diagnostics program.
-
 11) RTL8139C support untested.
 
-12) 10base-T support flaky or slow
+12) 10base-T support flaky or slow (todo: verify this is still true)
 
 
 
 
 Change History
 --------------
+
+Version 0.9.10 - September 12, 2000
+
+* Never wrap an Rx packet (faster Rx interrupt handling)
+* Clear all TxAborted conditions (bug fix)
+* Correct copyright
+* More credits
+* Update NWay doc URL
+* Clean up commonly used ifdef switches
+* Reorg info displayed at bootup/modprobe time
+* Remove some unneeded spinlocks
+* Misc cosmetic code cleanup
+* Always print interrupt status for abnormal interrupts
+* Use RealTek-recommended FIFO and DMA burst settings (1024 bytes)
+
+
+Version 0.9.9 - September 9, 2000
+
+* Fix oops-able bug in Rx ring wrap calculation (David Ford)
+* Use PIO instead of MMIO when USE_IO_OPS is defined
+* Move Rx error handling out of Rx interrupt handler, resulting in
+  tighter Rx interrupt processing
+
+
+Version 0.9.8 - September 7, 2000
+
+* Propagate request_irq error value (andrew morton)
+* Correct potential oops bug in PCI DMA unmap code
+* Fix bugs related to counting/discounting of 32-bit CRC in each Rx packet
+* Fix 16/32-bit bug in interrupt status check
+* Timer cleanups (andrew morton)
+
+
 Version 0.9.7 - June 11, 2000
 
 * Fix support for older chips (RTL8139 early chips should now work again)
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index aaccf6bc0..143c191f9 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -1,666 +1,688 @@
-

-NOTE

-----

-

-This document was contributed by Cirrus Logic for kernel 2.2.5.  This version

-has been updated for 2.3.48 by Andrew Morton <andrewm@uow.edu.au>

-

-Cirrus make a copy of this driver available at their website, as

-described below.  In general, you should use the driver version which

-comes with your Linux distribution.

-

-

-

-CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS

-Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>

-===============================================================================

- 

-

-TABLE OF CONTENTS

-

-1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS

-    1.1 Product Overview 

-    1.2 Driver Description

-	1.2.1 Driver Name

-	1.2.2 File in the Driver Package

-    1.3 System Requirements

-    1.4 Licensing Information

-

-2.0 ADAPTER INSTALLATION and CONFIGURATION

-    2.1 CS8900-based Adapter Configuration

-    2.2 CS8920-based Adapter Configuration 

-

-3.0 LOADING THE DRIVER AS A MODULE

-

-4.0 COMPILING THE DRIVER

-    4.1 Compiling the Driver as a Loadable Module

-    4.2 Compiling the driver to support memory mode

-    4.3 Compiling the driver to support Rx DMA 

-    4.4 Compiling the Driver into the Kernel

-

-5.0 TESTING AND TROUBLESHOOTING

-    5.1 Known Defects and Limitations

-    5.2 Testing the Adapter

-        5.2.1 Diagnostic Self-Test

-        5.2.2 Diagnostic Network Test

-    5.3 Using the Adapter's LEDs

-    5.4 Resolving I/O Conflicts

-

-6.0 TECHNICAL SUPPORT

-    6.1 Contacting Cirrus Logic's Technical Support

-    6.2 Information Required Before Contacting Technical Support

-    6.3 Obtaining the Latest Driver Version

-    6.4 Current maintainer

-

-

-

-1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS

-===============================================================================

-

-

-1.1 PRODUCT OVERVIEW

-

-The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow 

-IEEE 802.3 standards and support half or full-duplex operation in ISA bus 

-computers on 10 Mbps Ethernet networks.  The adapters are designed for operation 

-in 16-bit ISA or EISA bus expansion slots and are available in 

-10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5 

-or fiber networks).  

-

-CS8920-based adapters are similar to the CS8900-based adapter with additional 

-features for Plug and Play (PnP) support and Wakeup Frame recognition.  As 

-such, the configuration procedures differ somewhat between the two types of 

-adapters.  Refer to the "Adapter Configuration" section for details on 

-configuring both types of adapters.

-

-

-1.2 DRIVER DESCRIPTION

-

-The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux

-v2.3.48 or greater kernel.  It can be compiled directly into the kernel

-or loaded at run-time as a device driver module.

-

-1.2.1 Driver Name: cs89x0

-

-1.2.2 Files in the Driver Archive:

-

-The files in the driver at Cirrus' website include:

-

-  readme.txt         - this file

-  build              - batch file to compile cs89x0.c.

-  cs89x0.c           - driver C code

-  cs89x0.h           - driver header file

-  cs89x0.o           - pre-compiled module (for v2.2.5 kernel)

-  config/Config.in   - sample file to include cs89x0 driver in the kernel.

-  config/Makefile    - sample file to include cs89x0 driver in the kernel.

-  config/Space.c     - sample file to include cs89x0 driver in the kernel.

-

-

-

-1.3 SYSTEM REQUIREMENTS

-

-The following hardware is required:

-

-   * Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter   

-

-   * IBM or IBM-compatible PC with:

-     * An 80386 or higher processor

-     * 16 bytes of contiguous IO space available between 210h - 370h

-     * One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).

-

-   * Appropriate cable (and connector for AUI, 10BASE-2) for your network

-     topology.

-

-The following software is required:

-

-* LINUX kernel version 2.3.48 or higher

-

-   * CS8900/20 Setup Utility (DOS-based)

-

-   * LINUX kernel sources for your kernel (if compiling into kernel)

-

-   * GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel 

-     or a module)   

-

-

-

-1.4 LICENSING INFORMATION

-

-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, version 1.

-

-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.

-

-For a full copy of the GNU General Public License, write to the Free Software

-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

-

-

-

-2.0 ADAPTER INSTALLATION and CONFIGURATION

-===============================================================================

-

-Both the CS8900 and CS8920-based adapters can be configured using parameters 

-stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup 

-Utility if you want to change the adapter's configuration in EEPROM.  

-

-When loading the driver as a module, you can specify many of the adapter's 

-configuration parameters on the command-line to override the EEPROM's settings 

-or for interface configuration when an EEPROM is not used. (CS8920-based 

-adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.

-

-Since the CS8900/20 Setup Utility is a DOS-based application, you must install 

-and configure the adapter in a DOS-based system using the CS8900/20 Setup 

-Utility before installation in the target LINUX system.  (Not required if 

-installing a CS8900-based adapter and the default configuration is acceptable.)

-     

-

-2.1 CS8900-BASED ADAPTER CONFIGURATION

-

-CS8900-based adapters shipped from Cirrus Logic have been configured 

-with the following "default" settings:

-

-  Operation Mode:      Memory Mode

-  IRQ:                 10

-  Base I/O Address:    300

-  Memory Base Address: D0000

-  Optimization:	       DOS Client

-  Transmission Mode:   Half-duplex

-  BootProm:            None

-  Media Type:	       Autodetect (3-media cards) or 

-                       10BASE-T (10BASE-T only adapter)

-

-You should only change the default configuration settings if conflicts with 

-another adapter exists. To change the adapter's configuration, run the 

-CS8900/20 Setup Utility. 

-

-

-2.2 CS8920-BASED ADAPTER CONFIGURATION

-

-CS8920-based adapters are shipped from Cirrus Logic configured as Plug

-and Play (PnP) enabled.  However, since the cs89x0 driver does NOT

-support PnP, you must install the CS8920 adapter in a DOS-based PC and

-run the CS8900/20 Setup Utility to disable PnP and configure the

-adapter before installation in the target Linux system.  Failure to do

-this will leave the adapter inactive and the driver will be unable to

-communicate with the adapter.  

-

-

-        **************************************************************** 

-        *                    CS8920-BASED ADAPTERS:                    *

-        *                                                              * 

-        * CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT.  * 

-        * THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST  *

-        * RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND   *

-        * TO ACTIVATE THE ADAPTER.                                     *

-        ****************************************************************

-

-

-

-

-3.0 LOADING THE DRIVER AS A MODULE

-===============================================================================

-

-If the driver is compiled as a loadable module, you can load the driver module

-with the 'modprobe' command.  Many of the adapter's configuration parameters can 

-be specified as command-line arguments to the load command.  This facility 

-provides a means to override the EEPROM's settings or for interface 

-configuration when an EEPROM is not used.

-

-Example:

-

-    insmod cs89x0.o io=0x200 irq=0xA media=aui

-

-This example loads the module and configures the adapter to use an IO port base

-address of 200h, interrupt 10, and use the AUI media connection.  The following

-configuration options are available on the command line:

-

-* io=###               - specify IO address (200h-360h)

-* irq=##               - specify interrupt level

-* use_dma=1            - Enable DMA

-* dma=#                - specify dma channel (Driver is compiled to support

-                         Rx DMA only)

-* dmasize=# (16 or 64) - DMA size 16K or 64K.  Default value is set to 16.

-* media=rj45           - specify media type

-   or media=bnc

-   or media=aui

-   or medai=auto

-* duplex=full          - specify forced half/full/autonegotiate duplex

-   or duplex=half

-   or duplex=auto

-* debug=#              - debug level (only available if the driver was compiled

-                         for debugging)

-

-NOTES:

-

-a) If an EEPROM is present, any specified command-line parameter

-   will override the corresponding configuration value stored in

-   EEPROM.

-

-b) The "io" parameter must be specified on the command-line.  

-

-c) In case you can not re-load the driver because Linux system

-   returns the "device or resource busy" message, try to re-load it by

-   increment the IO port address by one.  The driver will write

-   commands to the IO base addresses to reset the data port pointer. 

-   You can specify an I/O address with an address value one greater

-   than the configured address.  Example, to scan for an adapter

-   located at IO base 0x300, specify an IO address of 0x301.  

-

-d) The "duplex=auto" parameter is only supported for the CS8920.

-

-e) The minimum command-line configuration required if an EEPROM is

-   not present is:

-

-   io 

-   irq 

-   media type (no autodetect)

-

-f) The following additional parameters are CS89XX defaults (values

-   used with no EEPROM or command-line argument).

-

-   * DMA Burst = enabled

-   * IOCHRDY Enabled = enabled

-   * UseSA = enabled

-   * CS8900 defaults to half-duplex if not specified on command-line

-   * CS8920 defaults to autoneg if not specified on command-line

-   * Use reset defaults for other config parameters

-   * dma_mode = 0

-

-g) You can use ifconfig to set the adapter's Ethernet address.

-

-h) Many Linux distributions use the 'modprobe' command to load

-   modules.  This program uses the '/etc/conf.modules' file to

-   determine configuration information which is passed to a driver

-   module when it is loaded.  All the configuration options which are

-   described above may be placed within /etc/conf.modules.

-

-   For example:

-

-   > cat /etc/conf.modules

-   ...

-   alias eth0 cs89x0

-   options cs89x0 io=0x0200 dma=5 use_dma=1

-   ...

-

-   In this example we are telling the module system that the

-   ethernet driver for this machine should use the cs89x0 driver.  We

-   are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'

-   arguments to the driver when it is loaded.

-

-i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or

-   7.  You will probably find that other DMA channels will not work.

-

-j) The cs89x0 supports DMA for receiving only.  DMA mode is

-   significantly more efficient.  Flooding a 400 MHz Celeron machine

-   with large ping packets consumes 82% of its CPU capacity in non-DMA

-   mode.  With DMA this is reduced to 45%.

-

-k) If your Linux kernel was compiled with inbuilt plug-and-play

-   support you will be able to find information about the cs89x0 card

-   with the command

-

-   cat /proc/isapnp

-

-l) If during DMA operation you find erratic behavior or network data

-   corruption you should use your PC's BIOS to slow the EISA bus clock.

-

-

-4.0 COMPILING THE DRIVER

-===============================================================================

-

-The cs89x0 driver can be compiled directly into the kernel or compiled into

-a loadable device driver module.

-

-

-4.1 COMPILING THE DRIVER AS A LOADABLE MODULE

-

-To compile the driver into a loadable module, use the following command 

-(single command line, without quotes):

-

-"gcc -D__KERNEL__ -I/usr/src/linux/include -I/usr/src/linux/net/inet -Wall 

--Wstrict-prototypes -O2 -fomit-frame-pointer -DMODULE -DCONFIG_MODVERSIONS 

--c cs89x0.c"

-

-4.2 COMPILING THE DRIVER TO SUPPORT MEMORY MODE

-

-Support for memory mode was not carried over into the 2.3 series kernels.

-

-4.3 COMPILING THE DRIVER TO SUPPORT Rx DMA

-

-The compile-time optionality for DMA was removed in the 2.3 kernel

-series.  DMA support is now unconditionally part of the driver.  It is

-enabled by the 'use_dma=1' module option.

-

-4.4 COMPILING THE DRIVER INTO THE KERNEL

-

-If your Linux distribution already has support for the cs89x0 driver

-then simply copy the source file to the /usr/src/linux/drivers/net

-directory to replace the original ones and run the make utility to

-rebuild the kernel.  See Step 3 for rebuilding the kernel.

-

-If your Linux does not include the cs89x0 driver, you need to edit three 

-configuration files, copy the source file to the /usr/src/linux/drivers/net

-directory, and then run the make utility to rebuild the kernel.

-

-1. Edit the following configuration files by adding the statements as

-indicated.  (When possible, try to locate the added text to the section of the

-file containing similar statements).

-

-

-a.) In /usr/src/linux/drivers/net/Config.in, add:

-

-tristate 'CS89x0 support' CONFIG_CS89x0

-

-Example:

-

-     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

-       tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I

-     fi

-

-     tristate 'CS89x0 support' CONFIG_CS89x0

-

-     tristate 'NE2000/NE1000 support' CONFIG_NE2000

-     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

-       tristate 'NI5210 support' CONFIG_NI52

-

-

-b.) In /usr/src/linux/drivers/net/Makefile, add the following lines: 

-

-ifeq ($(CONFIG_CS89x0),y)

-L_OBJS += cs89x0.o

-else

-  ifeq ($(CONFIG_CS89x0),m)

-  M_OBJS += cs89x0.o

-  endif

-endif

-

-

-c.) In /linux/drivers/net/Space.c file, add the line:

-

-extern int cs89x0_probe(struct device *dev);

-

-

-Example:

-

- extern int ultra_probe(struct device *dev);

- extern int wd_probe(struct device *dev);

- extern int el2_probe(struct device *dev);

-

- extern int cs89x0_probe(struct device *dev);

-

- extern int ne_probe(struct device *dev);

- extern int hp_probe(struct device *dev);

- extern int hp_plus_probe(struct device *dev);

-

-

-Also add:

-

- #ifdef CONFIG_CS89x0

- 	{ cs89x0_probe,0 },

- #endif

-

-

-2.) Copy the driver source files (cs89x0.c and cs89x0.h) 

-into the /usr/src/linux/drivers/net directory.

-

-

-3.) Go to /usr/src/linux directory and run 'make config' followed by 'make dep' 

-and finally 'make' (or make bzImage) to rebuild the kernel. 

-

-4.) Use the DOS 'setup' utility to disable plug and play on the NIC.

-

-

-5.0 TESTING AND TROUBLESHOOTING

-===============================================================================

-

-5.1 KNOWN DEFECTS and LIMITATIONS

-

-Refer to the RELEASE.TXT file distributed as part of this archive for a list of 

-known defects, driver limitations, and work arounds.

-

-

-5.2 TESTING THE ADAPTER

-

-Once the adapter has been installed and configured, the diagnostic option of 

-the CS8900/20 Setup Utility can be used to test the functionality of the 

-adapter and its network connection.  Use the diagnostics 'Self Test' option to

-test the functionality of the adapter with the hardware configuration you have

-assigned. You can use the diagnostics 'Network Test' to test the ability of the

-adapter to communicate across the Ethernet with another PC equipped with a 

-CS8900/20-based adapter card (it must also be running the CS8900/20 Setup 

-Utility).

-

-         NOTE: The Setup Utility's diagnostics are designed to run in a

-         DOS-only operating system environment.  DO NOT run the diagnostics 

-         from a DOS or command prompt session under Windows 95, Windows NT, 

-         OS/2, or other operating system.

-

-To run the diagnostics tests on the CS8900/20 adapter:

-

-   1.) Boot DOS on the PC and start the CS8900/20 Setup Utility.

-

-   2.) The adapter's current configuration is displayed.  Hit the ENTER key to

-       get to the main menu.

-

-   4.) Select 'Diagnostics' (ALT-G) from the main menu.  

-       * Select 'Self-Test' to test the adapter's basic functionality.

-       * Select 'Network Test' to test the network connection and cabling.

-

-

-5.2.1 DIAGNOSTIC SELF-TEST

-

-The diagnostic self-test checks the adapter's basic functionality as well as 

-its ability to communicate across the ISA bus based on the system resources 

-assigned during hardware configuration.  The following tests are performed:

-

-   * IO Register Read/Write Test

-     The IO Register Read/Write test insures that the CS8900/20 can be 

-     accessed in IO mode, and that the IO base address is correct.

-

-   * Shared Memory Test

-     The Shared Memory test insures the CS8900/20 can be accessed in memory 

-     mode and that the range of memory addresses assigned does not conflict 

-     with other devices in the system.

-

-   * Interrupt Test

-     The Interrupt test insures there are no conflicts with the assigned IRQ

-     signal.

-

-   * EEPROM Test

-     The EEPROM test insures the EEPROM can be read.

-

-   * Chip RAM Test

-     The Chip RAM test insures the 4K of memory internal to the CS8900/20 is

-     working properly.

-

-   * Internal Loop-back Test

-     The Internal Loop Back test insures the adapter's transmitter and 

-     receiver are operating properly.  If this test fails, make sure the 

-     adapter's cable is connected to the network (check for LED activity for 

-     example).

-

-   * Boot PROM Test

-     The Boot PROM  test insures the Boot PROM is present, and can be read.

-     Failure indicates the Boot PROM  was not successfully read due to a

-     hardware problem or due to a conflicts on the Boot PROM address

-     assignment. (Test only applies if the adapter is configured to use the

-     Boot PROM option.)

-

-Failure of a test item indicates a possible system resource conflict with 

-another device on the ISA bus.  In this case, you should use the Manual Setup 

-option to reconfigure the adapter by selecting a different value for the system

-resource that failed.

-

-

-5.2.2 DIAGNOSTIC NETWORK TEST

-

-The Diagnostic Network Test verifies a working network connection by 

-transferring data between two CS8900/20 adapters installed in different PCs 

-on the same network. (Note: the diagnostic network test should not be run 

-between two nodes across a router.) 

-

-This test requires that each of the two PCs have a CS8900/20-based adapter

-installed and have the CS8900/20 Setup Utility running.  The first PC is 

-configured as a Responder and the other PC is configured as an Initiator.  

-Once the Initiator is started, it sends data frames to the Responder which 

-returns the frames to the Initiator.

-

-The total number of frames received and transmitted are displayed on the 

-Initiator's display, along with a count of the number of frames received and 

-transmitted OK or in error.  The test can be terminated anytime by the user at 

-either PC.

-

-To setup the Diagnostic Network Test:

-

-    1.) Select a PC with a CS8900/20-based adapter and a known working network

-        connection to act as the Responder.  Run the CS8900/20 Setup Utility 

-        and select 'Diagnostics -> Network Test -> Responder' from the main 

-        menu.  Hit ENTER to start the Responder.

-

-    2.) Return to the PC with the CS8900/20-based adapter you want to test and

-        start the CS8900/20 Setup Utility. 

-

-    3.) From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.

-        Hit ENTER to start the test.

- 

-You may stop the test on the Initiator at any time while allowing the Responder

-to continue running.  In this manner, you can move to additional PCs and test 

-them by starting the Initiator on another PC without having to stop/start the 

-Responder.

- 

-

-

-5.3 USING THE ADAPTER'S LEDs

-

-The 2 and 3-media adapters have two LEDs visible on the back end of the board 

-located near the 10Base-T connector.  

-

-Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T 

-connection.  (Only applies to 10Base-T.  The green LED has no significance for

-a 10Base-2 or AUI connection.)

-

-TX/RX LED: The yellow LED lights briefly each time the adapter transmits or 

-receives data. (The yellow LED will appear to "flicker" on a typical network.)

-

-

-5.4 RESOLVING I/O CONFLICTS

-

-An IO conflict occurs when two or more adapter use the same ISA resource (IO 

-address, memory address or IRQ).  You can usually detect an IO conflict in one 

-of four ways after installing and or configuring the CS8900/20-based adapter:

-

-    1.) The system does not boot properly (or at all).

-

-    2.) The driver can not communicate with the adapter, reporting an "Adapter

-        not found" error message.

-

-    3.) You cannot connect to the network or the driver will not load.

-

-    4.) If you have configured the adapter to run in memory mode but the driver

-        reports it is using IO mode when loading, this is an indication of a

-        memory address conflict.

-

-If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a 

-diagnostic self-test.  Normally, the ISA resource in conflict will fail the 

-self-test.  If so, reconfigure the adapter selecting another choice for the 

-resource in conflict.  Run the diagnostics again to check for further IO 

-conflicts.

-

-In some cases, such as when the PC will not boot, it may be necessary to remove

-the adapter and reconfigure it by installing it in another PC to run the 

-CS8900/20 Setup Utility.  Once reinstalled in the target system, run the 

-diagnostics self-test to ensure the new configuration is free of conflicts 

-before loading the driver again.

-

-When manually configuring the adapter, keep in mind the typical ISA system 

-resource usage as indicated in the tables below.

-

-I/O Address    	Device                        IRQ      Device

------------    	--------                      ---      --------

- 200-20F       	Game I/O adapter               3       COM2, Bus Mouse

- 230-23F       	Bus Mouse                      4       COM1

- 270-27F       	LPT3: third parallel port      5       LPT2

- 2F0-2FF       	COM2: second serial port       6       Floppy Disk controller

- 320-32F       	Fixed disk controller          7       LPT1

-                                      	       8       Real-time Clock

-                                                 9       EGA/VGA display adapter    

-                                                12       Mouse (PS/2)                              

-Memory Address  Device                          13       Math Coprocessor

---------------  ---------------------           14       Hard Disk controller

-A000-BFFF	EGA Graphics Adpater

-A000-C7FF	VGA Graphics Adpater

-B000-BFFF	Mono Graphics Adapter

-B800-BFFF	Color Graphics Adapter

-E000-FFFF	AT BIOS

-

-

-

-

-6.0 TECHNICAL SUPPORT

-===============================================================================

-

-6.1 CONTACTING CIRRUS LOGIC'S TECHNICAL SUPPORT

-

-Cirrus Logic's CS89XX Technical Application Support can be reached at:

-

-Telephone  :(800) 888-5016 (from inside U.S. and Canada)

-           :(512) 442-7555 (from outside the U.S. and Canada)

-Fax        :(512) 912-3871

-Email      :ethernet@crystal.cirrus.com

-WWW        :http://www.cirrus.com

-

-

-6.2 INFORMATION REQUIRED BEFORE CONTACTING TECHNICAL SUPPORT

-

-Before contacting Cirrus Logic for technical support, be prepared to provide as 

-Much of the following information as possible. 

-

-1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)

-

-2.) Adapter configuration

-

-    * IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel

-    * Plug and Play enabled/disabled (CS8920-based adapters only)

-    * Configured for media auto-detect or specific media type (which type).    

-

-3.) PC System's Configuration

-

-    * Plug and Play system (yes/no)

-    * BIOS (make and version)

-    * System make and model

-    * CPU (type and speed)

-    * System RAM

-    * SCSI Adapter

-

-4.) Software

-

-    * CS89XX driver and version

-    * Your network operating system and version

-    * Your system's OS version 

-    * Version of all protocol support files

-

-5.) Any Error Message displayed.

-

-

-

-6.3 OBTAINING THE LATEST DRIVER VERSION

-

-You can obtain the latest CS89XX drivers and support software from Cirrus Logic's 

-Web site.  You can also contact Cirrus Logic's Technical Support (email:

-ethernet@crystal.cirrus.com) and request that you be registered for automatic 

-software-update notification.

-

-Cirrus Logic maintains a web page at http://www.cirrus.com with the

-the latest drivers and technical publications.

-

-

-6.4 Current maintainer

-

-In February 2000 the maintenance of this driver was assumed by Andrew

-Morton <andrewm@uow.edu.au>

-

-

+
+NOTE
+----
+
+This document was contributed by Cirrus Logic for kernel 2.2.5.  This version
+has been updated for 2.3.48 by Andrew Morton <andrewm@uow.edu.au>
+
+Cirrus make a copy of this driver available at their website, as
+described below.  In general, you should use the driver version which
+comes with your Linux distribution.
+
+
+
+CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>
+===============================================================================
+ 
+
+TABLE OF CONTENTS
+
+1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+    1.1 Product Overview 
+    1.2 Driver Description
+	1.2.1 Driver Name
+	1.2.2 File in the Driver Package
+    1.3 System Requirements
+    1.4 Licensing Information
+
+2.0 ADAPTER INSTALLATION and CONFIGURATION
+    2.1 CS8900-based Adapter Configuration
+    2.2 CS8920-based Adapter Configuration 
+
+3.0 LOADING THE DRIVER AS A MODULE
+
+4.0 COMPILING THE DRIVER
+    4.1 Compiling the Driver as a Loadable Module
+    4.2 Compiling the driver to support memory mode
+    4.3 Compiling the driver to support Rx DMA 
+    4.4 Compiling the Driver into the Kernel
+
+5.0 TESTING AND TROUBLESHOOTING
+    5.1 Known Defects and Limitations
+    5.2 Testing the Adapter
+        5.2.1 Diagnostic Self-Test
+        5.2.2 Diagnostic Network Test
+    5.3 Using the Adapter's LEDs
+    5.4 Resolving I/O Conflicts
+
+6.0 TECHNICAL SUPPORT
+    6.1 Contacting Cirrus Logic's Technical Support
+    6.2 Information Required Before Contacting Technical Support
+    6.3 Obtaining the Latest Driver Version
+    6.4 Current maintainer
+
+
+
+1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+===============================================================================
+
+
+1.1 PRODUCT OVERVIEW
+
+The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow 
+IEEE 802.3 standards and support half or full-duplex operation in ISA bus 
+computers on 10 Mbps Ethernet networks.  The adapters are designed for operation 
+in 16-bit ISA or EISA bus expansion slots and are available in 
+10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5 
+or fiber networks).  
+
+CS8920-based adapters are similar to the CS8900-based adapter with additional 
+features for Plug and Play (PnP) support and Wakeup Frame recognition.  As 
+such, the configuration procedures differ somewhat between the two types of 
+adapters.  Refer to the "Adapter Configuration" section for details on 
+configuring both types of adapters.
+
+
+1.2 DRIVER DESCRIPTION
+
+The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux
+v2.3.48 or greater kernel.  It can be compiled directly into the kernel
+or loaded at run-time as a device driver module.
+
+1.2.1 Driver Name: cs89x0
+
+1.2.2 Files in the Driver Archive:
+
+The files in the driver at Cirrus' website include:
+
+  readme.txt         - this file
+  build              - batch file to compile cs89x0.c.
+  cs89x0.c           - driver C code
+  cs89x0.h           - driver header file
+  cs89x0.o           - pre-compiled module (for v2.2.5 kernel)
+  config/Config.in   - sample file to include cs89x0 driver in the kernel.
+  config/Makefile    - sample file to include cs89x0 driver in the kernel.
+  config/Space.c     - sample file to include cs89x0 driver in the kernel.
+
+
+
+1.3 SYSTEM REQUIREMENTS
+
+The following hardware is required:
+
+   * Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter   
+
+   * IBM or IBM-compatible PC with:
+     * An 80386 or higher processor
+     * 16 bytes of contiguous IO space available between 210h - 370h
+     * One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).
+
+   * Appropriate cable (and connector for AUI, 10BASE-2) for your network
+     topology.
+
+The following software is required:
+
+* LINUX kernel version 2.3.48 or higher
+
+   * CS8900/20 Setup Utility (DOS-based)
+
+   * LINUX kernel sources for your kernel (if compiling into kernel)
+
+   * GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel 
+     or a module)   
+
+
+
+1.4 LICENSING INFORMATION
+
+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, version 1.
+
+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.
+
+For a full copy of the GNU General Public License, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+
+2.0 ADAPTER INSTALLATION and CONFIGURATION
+===============================================================================
+
+Both the CS8900 and CS8920-based adapters can be configured using parameters 
+stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup 
+Utility if you want to change the adapter's configuration in EEPROM.  
+
+When loading the driver as a module, you can specify many of the adapter's 
+configuration parameters on the command-line to override the EEPROM's settings 
+or for interface configuration when an EEPROM is not used. (CS8920-based 
+adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.
+
+Since the CS8900/20 Setup Utility is a DOS-based application, you must install 
+and configure the adapter in a DOS-based system using the CS8900/20 Setup 
+Utility before installation in the target LINUX system.  (Not required if 
+installing a CS8900-based adapter and the default configuration is acceptable.)
+     
+
+2.1 CS8900-BASED ADAPTER CONFIGURATION
+
+CS8900-based adapters shipped from Cirrus Logic have been configured 
+with the following "default" settings:
+
+  Operation Mode:      Memory Mode
+  IRQ:                 10
+  Base I/O Address:    300
+  Memory Base Address: D0000
+  Optimization:	       DOS Client
+  Transmission Mode:   Half-duplex
+  BootProm:            None
+  Media Type:	       Autodetect (3-media cards) or 
+                       10BASE-T (10BASE-T only adapter)
+
+You should only change the default configuration settings if conflicts with 
+another adapter exists. To change the adapter's configuration, run the 
+CS8900/20 Setup Utility. 
+
+
+2.2 CS8920-BASED ADAPTER CONFIGURATION
+
+CS8920-based adapters are shipped from Cirrus Logic configured as Plug
+and Play (PnP) enabled.  However, since the cs89x0 driver does NOT
+support PnP, you must install the CS8920 adapter in a DOS-based PC and
+run the CS8900/20 Setup Utility to disable PnP and configure the
+adapter before installation in the target Linux system.  Failure to do
+this will leave the adapter inactive and the driver will be unable to
+communicate with the adapter.  
+
+
+        **************************************************************** 
+        *                    CS8920-BASED ADAPTERS:                    *
+        *                                                              * 
+        * CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT.  * 
+        * THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST  *
+        * RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND   *
+        * TO ACTIVATE THE ADAPTER.                                     *
+        ****************************************************************
+
+
+
+
+3.0 LOADING THE DRIVER AS A MODULE
+===============================================================================
+
+If the driver is compiled as a loadable module, you can load the driver module
+with the 'modprobe' command.  Many of the adapter's configuration parameters can 
+be specified as command-line arguments to the load command.  This facility 
+provides a means to override the EEPROM's settings or for interface 
+configuration when an EEPROM is not used.
+
+Example:
+
+    insmod cs89x0.o io=0x200 irq=0xA media=aui
+
+This example loads the module and configures the adapter to use an IO port base
+address of 200h, interrupt 10, and use the AUI media connection.  The following
+configuration options are available on the command line:
+
+* io=###               - specify IO address (200h-360h)
+* irq=##               - specify interrupt level
+* use_dma=1            - Enable DMA
+* dma=#                - specify dma channel (Driver is compiled to support
+                         Rx DMA only)
+* dmasize=# (16 or 64) - DMA size 16K or 64K.  Default value is set to 16.
+* media=rj45           - specify media type
+   or media=bnc
+   or media=aui
+   or medai=auto
+* duplex=full          - specify forced half/full/autonegotiate duplex
+   or duplex=half
+   or duplex=auto
+* debug=#              - debug level (only available if the driver was compiled
+                         for debugging)
+
+NOTES:
+
+a) If an EEPROM is present, any specified command-line parameter
+   will override the corresponding configuration value stored in
+   EEPROM.
+
+b) The "io" parameter must be specified on the command-line.  
+
+c) In case you can not re-load the driver because Linux system
+   returns the "device or resource busy" message, try to re-load it by
+   increment the IO port address by one.  The driver will write
+   commands to the IO base addresses to reset the data port pointer. 
+   You can specify an I/O address with an address value one greater
+   than the configured address.  Example, to scan for an adapter
+   located at IO base 0x300, specify an IO address of 0x301.  
+
+d) The "duplex=auto" parameter is only supported for the CS8920.
+
+e) The minimum command-line configuration required if an EEPROM is
+   not present is:
+
+   io 
+   irq 
+   media type (no autodetect)
+
+f) The following additional parameters are CS89XX defaults (values
+   used with no EEPROM or command-line argument).
+
+   * DMA Burst = enabled
+   * IOCHRDY Enabled = enabled
+   * UseSA = enabled
+   * CS8900 defaults to half-duplex if not specified on command-line
+   * CS8920 defaults to autoneg if not specified on command-line
+   * Use reset defaults for other config parameters
+   * dma_mode = 0
+
+g) You can use ifconfig to set the adapter's Ethernet address.
+
+h) Many Linux distributions use the 'modprobe' command to load
+   modules.  This program uses the '/etc/conf.modules' file to
+   determine configuration information which is passed to a driver
+   module when it is loaded.  All the configuration options which are
+   described above may be placed within /etc/conf.modules.
+
+   For example:
+
+   > cat /etc/conf.modules
+   ...
+   alias eth0 cs89x0
+   options cs89x0 io=0x0200 dma=5 use_dma=1
+   ...
+
+   In this example we are telling the module system that the
+   ethernet driver for this machine should use the cs89x0 driver.  We
+   are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'
+   arguments to the driver when it is loaded.
+
+i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or
+   7.  You will probably find that other DMA channels will not work.
+
+j) The cs89x0 supports DMA for receiving only.  DMA mode is
+   significantly more efficient.  Flooding a 400 MHz Celeron machine
+   with large ping packets consumes 82% of its CPU capacity in non-DMA
+   mode.  With DMA this is reduced to 45%.
+
+k) If your Linux kernel was compiled with inbuilt plug-and-play
+   support you will be able to find information about the cs89x0 card
+   with the command
+
+   cat /proc/isapnp
+
+l) If during DMA operation you find erratic behavior or network data
+   corruption you should use your PC's BIOS to slow the EISA bus clock.
+
+m) If the cs89x0 driver is compiled directly into the kernel
+   (non-modular) then its I/O address is automatically determined by
+   ISA bus probing.  The IRQ number, media options, etc are determined
+   from the card's EEPROM.
+
+n) If the cs89x0 driver is compiled directly into the kernel, DMA
+   mode may be selected by providing the kernel with a boot option
+   'cs89x0_dma=N' where 'N' is the desired DMA channel number (5, 6 or 7).
+
+   Kernel boot options may be provided on the LILO command line:
+
+	LILO boot: linux cs89x0_dma=5
+
+   or they may be placed in /etc/lilo.conf:
+
+	image=/boot/bzImage-2.3.48
+	  append="cs89x0_dma=5"
+	  label=linux
+	  root=/dev/hda5
+	  read-only
+
+   The DMA Rx buffer size is hardwired to 16 kbytes in this mode.
+   (64k mode is not available).
+
+
+4.0 COMPILING THE DRIVER
+===============================================================================
+
+The cs89x0 driver can be compiled directly into the kernel or compiled into
+a loadable device driver module.
+
+
+4.1 COMPILING THE DRIVER AS A LOADABLE MODULE
+
+To compile the driver into a loadable module, use the following command 
+(single command line, without quotes):
+
+"gcc -D__KERNEL__ -I/usr/src/linux/include -I/usr/src/linux/net/inet -Wall 
+-Wstrict-prototypes -O2 -fomit-frame-pointer -DMODULE -DCONFIG_MODVERSIONS 
+-c cs89x0.c"
+
+4.2 COMPILING THE DRIVER TO SUPPORT MEMORY MODE
+
+Support for memory mode was not carried over into the 2.3 series kernels.
+
+4.3 COMPILING THE DRIVER TO SUPPORT Rx DMA
+
+The compile-time optionality for DMA was removed in the 2.3 kernel
+series.  DMA support is now unconditionally part of the driver.  It is
+enabled by the 'use_dma=1' module option.
+
+4.4 COMPILING THE DRIVER INTO THE KERNEL
+
+If your Linux distribution already has support for the cs89x0 driver
+then simply copy the source file to the /usr/src/linux/drivers/net
+directory to replace the original ones and run the make utility to
+rebuild the kernel.  See Step 3 for rebuilding the kernel.
+
+If your Linux does not include the cs89x0 driver, you need to edit three 
+configuration files, copy the source file to the /usr/src/linux/drivers/net
+directory, and then run the make utility to rebuild the kernel.
+
+1. Edit the following configuration files by adding the statements as
+indicated.  (When possible, try to locate the added text to the section of the
+file containing similar statements).
+
+
+a.) In /usr/src/linux/drivers/net/Config.in, add:
+
+tristate 'CS89x0 support' CONFIG_CS89x0
+
+Example:
+
+     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+       tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
+     fi
+
+     tristate 'CS89x0 support' CONFIG_CS89x0
+
+     tristate 'NE2000/NE1000 support' CONFIG_NE2000
+     if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+       tristate 'NI5210 support' CONFIG_NI52
+
+
+b.) In /usr/src/linux/drivers/net/Makefile, add the following lines: 
+
+ifeq ($(CONFIG_CS89x0),y)
+L_OBJS += cs89x0.o
+else
+  ifeq ($(CONFIG_CS89x0),m)
+  M_OBJS += cs89x0.o
+  endif
+endif
+
+
+c.) In /linux/drivers/net/Space.c file, add the line:
+
+extern int cs89x0_probe(struct device *dev);
+
+
+Example:
+
+ extern int ultra_probe(struct device *dev);
+ extern int wd_probe(struct device *dev);
+ extern int el2_probe(struct device *dev);
+
+ extern int cs89x0_probe(struct device *dev);
+
+ extern int ne_probe(struct device *dev);
+ extern int hp_probe(struct device *dev);
+ extern int hp_plus_probe(struct device *dev);
+
+
+Also add:
+
+ #ifdef CONFIG_CS89x0
+ 	{ cs89x0_probe,0 },
+ #endif
+
+
+2.) Copy the driver source files (cs89x0.c and cs89x0.h) 
+into the /usr/src/linux/drivers/net directory.
+
+
+3.) Go to /usr/src/linux directory and run 'make config' followed by 'make dep' 
+and finally 'make' (or make bzImage) to rebuild the kernel. 
+
+4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
+
+
+5.0 TESTING AND TROUBLESHOOTING
+===============================================================================
+
+5.1 KNOWN DEFECTS and LIMITATIONS
+
+Refer to the RELEASE.TXT file distributed as part of this archive for a list of 
+known defects, driver limitations, and work arounds.
+
+
+5.2 TESTING THE ADAPTER
+
+Once the adapter has been installed and configured, the diagnostic option of 
+the CS8900/20 Setup Utility can be used to test the functionality of the 
+adapter and its network connection.  Use the diagnostics 'Self Test' option to
+test the functionality of the adapter with the hardware configuration you have
+assigned. You can use the diagnostics 'Network Test' to test the ability of the
+adapter to communicate across the Ethernet with another PC equipped with a 
+CS8900/20-based adapter card (it must also be running the CS8900/20 Setup 
+Utility).
+
+         NOTE: The Setup Utility's diagnostics are designed to run in a
+         DOS-only operating system environment.  DO NOT run the diagnostics 
+         from a DOS or command prompt session under Windows 95, Windows NT, 
+         OS/2, or other operating system.
+
+To run the diagnostics tests on the CS8900/20 adapter:
+
+   1.) Boot DOS on the PC and start the CS8900/20 Setup Utility.
+
+   2.) The adapter's current configuration is displayed.  Hit the ENTER key to
+       get to the main menu.
+
+   4.) Select 'Diagnostics' (ALT-G) from the main menu.  
+       * Select 'Self-Test' to test the adapter's basic functionality.
+       * Select 'Network Test' to test the network connection and cabling.
+
+
+5.2.1 DIAGNOSTIC SELF-TEST
+
+The diagnostic self-test checks the adapter's basic functionality as well as 
+its ability to communicate across the ISA bus based on the system resources 
+assigned during hardware configuration.  The following tests are performed:
+
+   * IO Register Read/Write Test
+     The IO Register Read/Write test insures that the CS8900/20 can be 
+     accessed in IO mode, and that the IO base address is correct.
+
+   * Shared Memory Test
+     The Shared Memory test insures the CS8900/20 can be accessed in memory 
+     mode and that the range of memory addresses assigned does not conflict 
+     with other devices in the system.
+
+   * Interrupt Test
+     The Interrupt test insures there are no conflicts with the assigned IRQ
+     signal.
+
+   * EEPROM Test
+     The EEPROM test insures the EEPROM can be read.
+
+   * Chip RAM Test
+     The Chip RAM test insures the 4K of memory internal to the CS8900/20 is
+     working properly.
+
+   * Internal Loop-back Test
+     The Internal Loop Back test insures the adapter's transmitter and 
+     receiver are operating properly.  If this test fails, make sure the 
+     adapter's cable is connected to the network (check for LED activity for 
+     example).
+
+   * Boot PROM Test
+     The Boot PROM  test insures the Boot PROM is present, and can be read.
+     Failure indicates the Boot PROM  was not successfully read due to a
+     hardware problem or due to a conflicts on the Boot PROM address
+     assignment. (Test only applies if the adapter is configured to use the
+     Boot PROM option.)
+
+Failure of a test item indicates a possible system resource conflict with 
+another device on the ISA bus.  In this case, you should use the Manual Setup 
+option to reconfigure the adapter by selecting a different value for the system
+resource that failed.
+
+
+5.2.2 DIAGNOSTIC NETWORK TEST
+
+The Diagnostic Network Test verifies a working network connection by 
+transferring data between two CS8900/20 adapters installed in different PCs 
+on the same network. (Note: the diagnostic network test should not be run 
+between two nodes across a router.) 
+
+This test requires that each of the two PCs have a CS8900/20-based adapter
+installed and have the CS8900/20 Setup Utility running.  The first PC is 
+configured as a Responder and the other PC is configured as an Initiator.  
+Once the Initiator is started, it sends data frames to the Responder which 
+returns the frames to the Initiator.
+
+The total number of frames received and transmitted are displayed on the 
+Initiator's display, along with a count of the number of frames received and 
+transmitted OK or in error.  The test can be terminated anytime by the user at 
+either PC.
+
+To setup the Diagnostic Network Test:
+
+    1.) Select a PC with a CS8900/20-based adapter and a known working network
+        connection to act as the Responder.  Run the CS8900/20 Setup Utility 
+        and select 'Diagnostics -> Network Test -> Responder' from the main 
+        menu.  Hit ENTER to start the Responder.
+
+    2.) Return to the PC with the CS8900/20-based adapter you want to test and
+        start the CS8900/20 Setup Utility. 
+
+    3.) From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.
+        Hit ENTER to start the test.
+ 
+You may stop the test on the Initiator at any time while allowing the Responder
+to continue running.  In this manner, you can move to additional PCs and test 
+them by starting the Initiator on another PC without having to stop/start the 
+Responder.
+ 
+
+
+5.3 USING THE ADAPTER'S LEDs
+
+The 2 and 3-media adapters have two LEDs visible on the back end of the board 
+located near the 10Base-T connector.  
+
+Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T 
+connection.  (Only applies to 10Base-T.  The green LED has no significance for
+a 10Base-2 or AUI connection.)
+
+TX/RX LED: The yellow LED lights briefly each time the adapter transmits or 
+receives data. (The yellow LED will appear to "flicker" on a typical network.)
+
+
+5.4 RESOLVING I/O CONFLICTS
+
+An IO conflict occurs when two or more adapter use the same ISA resource (IO 
+address, memory address or IRQ).  You can usually detect an IO conflict in one 
+of four ways after installing and or configuring the CS8900/20-based adapter:
+
+    1.) The system does not boot properly (or at all).
+
+    2.) The driver can not communicate with the adapter, reporting an "Adapter
+        not found" error message.
+
+    3.) You cannot connect to the network or the driver will not load.
+
+    4.) If you have configured the adapter to run in memory mode but the driver
+        reports it is using IO mode when loading, this is an indication of a
+        memory address conflict.
+
+If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a 
+diagnostic self-test.  Normally, the ISA resource in conflict will fail the 
+self-test.  If so, reconfigure the adapter selecting another choice for the 
+resource in conflict.  Run the diagnostics again to check for further IO 
+conflicts.
+
+In some cases, such as when the PC will not boot, it may be necessary to remove
+the adapter and reconfigure it by installing it in another PC to run the 
+CS8900/20 Setup Utility.  Once reinstalled in the target system, run the 
+diagnostics self-test to ensure the new configuration is free of conflicts 
+before loading the driver again.
+
+When manually configuring the adapter, keep in mind the typical ISA system 
+resource usage as indicated in the tables below.
+
+I/O Address    	Device                        IRQ      Device
+-----------    	--------                      ---      --------
+ 200-20F       	Game I/O adapter               3       COM2, Bus Mouse
+ 230-23F       	Bus Mouse                      4       COM1
+ 270-27F       	LPT3: third parallel port      5       LPT2
+ 2F0-2FF       	COM2: second serial port       6       Floppy Disk controller
+ 320-32F       	Fixed disk controller          7       LPT1
+                                      	       8       Real-time Clock
+                                                 9       EGA/VGA display adapter    
+                                                12       Mouse (PS/2)                              
+Memory Address  Device                          13       Math Coprocessor
+--------------  ---------------------           14       Hard Disk controller
+A000-BFFF	EGA Graphics Adpater
+A000-C7FF	VGA Graphics Adpater
+B000-BFFF	Mono Graphics Adapter
+B800-BFFF	Color Graphics Adapter
+E000-FFFF	AT BIOS
+
+
+
+
+6.0 TECHNICAL SUPPORT
+===============================================================================
+
+6.1 CONTACTING CIRRUS LOGIC'S TECHNICAL SUPPORT
+
+Cirrus Logic's CS89XX Technical Application Support can be reached at:
+
+Telephone  :(800) 888-5016 (from inside U.S. and Canada)
+           :(512) 442-7555 (from outside the U.S. and Canada)
+Fax        :(512) 912-3871
+Email      :ethernet@crystal.cirrus.com
+WWW        :http://www.cirrus.com
+
+
+6.2 INFORMATION REQUIRED BEFORE CONTACTING TECHNICAL SUPPORT
+
+Before contacting Cirrus Logic for technical support, be prepared to provide as 
+Much of the following information as possible. 
+
+1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)
+
+2.) Adapter configuration
+
+    * IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel
+    * Plug and Play enabled/disabled (CS8920-based adapters only)
+    * Configured for media auto-detect or specific media type (which type).    
+
+3.) PC System's Configuration
+
+    * Plug and Play system (yes/no)
+    * BIOS (make and version)
+    * System make and model
+    * CPU (type and speed)
+    * System RAM
+    * SCSI Adapter
+
+4.) Software
+
+    * CS89XX driver and version
+    * Your network operating system and version
+    * Your system's OS version 
+    * Version of all protocol support files
+
+5.) Any Error Message displayed.
+
+
+
+6.3 OBTAINING THE LATEST DRIVER VERSION
+
+You can obtain the latest CS89XX drivers and support software from Cirrus Logic's 
+Web site.  You can also contact Cirrus Logic's Technical Support (email:
+ethernet@crystal.cirrus.com) and request that you be registered for automatic 
+software-update notification.
+
+Cirrus Logic maintains a web page at http://www.cirrus.com with the
+the latest drivers and technical publications.
+
+
+6.4 Current maintainer
+
+In February 2000 the maintenance of this driver was assumed by Andrew
+Morton <andrewm@uow.edu.au>
diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt
index 2af3964ef..9591c7e39 100644
--- a/Documentation/networking/sk98lin.txt
+++ b/Documentation/networking/sk98lin.txt
@@ -1,9 +1,9 @@
-(C)Copyright 1999 SysKonnect.
+(C)Copyright 1999-2000 SysKonnect.
 ===========================================================================
 
-sk98lin.txt created 11-Nov-1999
+sk98lin.txt created 12-Sept-2000
 
-Readme File for sk98lin.o v3.04
+Readme File for sk98lin.o v3.05
 SK-NET Gigabit Ethernet Adapter SK-98xx Driver for Linux
 
 This file contains
@@ -373,6 +373,12 @@ following information is available:
 (8) HISTORY
 ===========
 
+VERSION 3.05 (In-Kernel version)
+Problems fixed:
+- Failed for multiple adapters in kernel 2.4.0
+New features:
+- New versions of several common modules
+
 VERSION 3.04 (In-Kernel version)
 Problems fixed:
 - Driver start failed on UltraSPARC
diff --git a/Documentation/networking/tulip.txt b/Documentation/networking/tulip.txt
index b5a625422..5363811cb 100644
--- a/Documentation/networking/tulip.txt
+++ b/Documentation/networking/tulip.txt
@@ -142,6 +142,13 @@ tulip_core.c	- Driver core (a.k.a. where "everything else" goes)
 
 Version history
 ===============
+0.9.10 (September 6, 2000):
+* Simple interrupt mitigation (via jamal)
+* More PCI ids
+
+0.9.9 (August 11, 2000):
+* More PCI ids
+
 0.9.8 (July 13, 2000):
 * Correct signed/unsigned comparison for dummy frame index
 * Remove outdated references to struct enet_statistics
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt
index cbeb54cb8..5fa8e379a 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.txt
@@ -25,29 +25,24 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
   br_sigio.c  - bridge based on async io and SIGIO signal.
   However the best example is VTun http://vtun.sourceforge.net :))  
 
-2. Installation
-  Run './configure' to configure the driver.
-
-  Run 'make install' to compile and install driver module and to create 
-  /dev/net/tun device node.
-
-3. Loading driver module
-  Linux
-     To load TUN/TAP driver module run:
-	modprobe tun 
-     To configure automatic loading of the 'tun' module you have to add: 
-	alias char-major-195 tun
-     to the /etc/conf.modules, and run: 
+2. Configuration 
+  Create device node:
+     mknod /dev/net/tun c 10 200
+
+  Driver module autoloading
+     Make sure that "Kernel module loader" - module auto-loading support is enabled 
+     in your kernel. 
+
+     Add following line to the /etc/modules.conf:
+	alias char-major-10-200 tun
+     
+     Run:
         modprobe -a 
-     TUN/TAP driver will be automatically loaded when application access
-     /dev/net/tun.
-     If "Kernel module loader" - module auto-loading support is not enabled 
-     in your kernel then you can add 
-        modprobe tun 
-     to one of the startup rc files.
 
-4. Program interface 
-  4.1 Network device allocation:
+     Driver will be automatically loaded when application access /dev/net/tun.
+
+3. Program interface 
+  3.1 Network device allocation:
 
   int tun_alloc(char *dev)
   {
@@ -76,7 +71,7 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
       return fd;
   }              
  
-  4.2 Frame format:
+  3.2 Frame format:
   If flag IFF_NO_PI is not set each frame format is: 
      Flags [2 bytes]
      Proto [2 bytes]
@@ -120,7 +115,7 @@ Currently driver has been written for 3 Unices:
 
 4. What is TUN/TAP driver used for?
 As mentioned above, main purpose of TUN/TAP driver is tunneling. 
-It used by VTun (http://vtun.netpedia.net).
+It is used by VTun (http://vtun.sourceforge.net).
 
 5. How does Virtual network device actually work ? 
 Virtual network device can be viewed as a simple Point-to-Point or
@@ -146,5 +141,3 @@ to attach BPF to this interface.
 
 8. Does TAP driver support kernel Ethernet bridging?
 Yes. Linux and FreeBSD drivers support Ethernet bridging. 
-
-
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index b76e8732c..0f86aaba3 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -166,8 +166,9 @@ watchdog=N
 
   Sets the time duration (in milliseconds) after which the kernel
   decides that the transmitter has become stuck and needs to be reset. 
-  This is mainly for debugging purposes.  The default value is 400 (0.4
-  seconds).
+  This is mainly for debugging purposes, although it may be advantageous
+  to increase this value on LANs which have very high collision rates.
+  The default value is 400 (0.4 seconds).
 
 Additional resources
 --------------------
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 5510e5349..21ffe7b06 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -1,7 +1,8 @@
 Quick Summary
 -------------
 
-Install ksymoops from ftp://ftp.ocs.com.au/pub/ksymoops
+Install ksymoops from
+ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops
 Read the ksymoops man page.
 ksymoops < the_oops.txt
 
diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index b96f6c48f..2b9041d3e 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -188,6 +188,11 @@ pci_find_capability()		Find specified capability in device's capability
 				list.
 pci_module_init()		Inline helper function for ensuring correct
 				pci_driver initialization and error handling.
+pci_resource_start()		Returns bus start address for a given PCI region
+pci_resource_end()		Returns bus end address for a given PCI region
+pci_resource_len()		Returns the byte length of a PCI region
+pci_set_drvdata()		Set private driver data pointer for a pci_dev
+pci_get_drvdata()		Return private driver data pointer for a pci_dev
 
 
 7. Miscellaneous hints
diff --git a/Documentation/sound/AD1816 b/Documentation/sound/AD1816
index b43d13be8..c5085a9a7 100644
--- a/Documentation/sound/AD1816
+++ b/Documentation/sound/AD1816
@@ -1,52 +1,15 @@
 Documentation for the AD1816(A) sound driver
 ============================================
 
-NOTE: This driver is still EXPERIMENTAL, so don't use it on production
-systems!
-
-
 Installation:
 -------------
 
-To get your AD1816(A) based sound card work, you'll have to enable
-module support ("Enable loadable module support") and support for
-experimental code ("Prompt for development and/or incomplete
-code/drivers") during kernel configuration. Enable "Sound card
-support", "OSS modules support" and "Support for AD1816(A) based cards
-(EXPERIMENTAL)" in the sound configuration menu, too. Be sure, that
-you build "Support for AD1816(A) based cards (EXPERIMENTAL)" as a MODULE,
-otherwise you may run into problems later.
-Now build, install and reboot the new kernel as usual.
-
-Since the AD1816(A) is a P'n'P sound chip you'll usually have to
-configure it using the isapnptools. See isapnptools documentation for
-details on configuring P'n'P cards.
-
-After you have successfully configured the card using isapnp, you may
-load the AD1816 driver using modprobe. A typical modprobe call should
-look like this:
-
-  modprobe ad1816 io=0x530 irq=5 dma=1 dma2=3 ad1816_clockfreq=33000
-
-if your isapnp.conf file looks like this (relevant lines only):
-
- (INT 0 (IRQ 5 (MODE +E)))
- (DMA 0 (CHANNEL 1))
- (DMA 1 (CHANNEL 3))
- (IO 0 (BASE 0x0220))
- (IO 1 (BASE 0x0388))
- (IO 2 (BASE 0x0530))
-
-NOTE: Be sure, that you use the address IO 2 (in our example 0x530) when
-loading the module!
-
-If your setup was correct, you should see the following messages in  
-/var/log/messages (numbers may be different):
-
-Nov  6 17:07:26 tek01 kernel: ad1816_detect(530)
-Nov  6 17:07:26 tek01 kernel: ad1816_detect() - Detected OK
-Nov  6 17:07:26 tek01 kernel: AD1816 Version: 3
-
+To get your AD1816(A) based sound card work, you'll have to enable support for
+experimental code ("Prompt for development and/or incomplete code/drivers")
+and isapnp ("Plug and Play support", "ISA Plug and Play support"). Enable
+"Sound card support", "OSS modules support" and "Support for AD1816(A) based
+cards (EXPERIMENTAL)" in the sound configuration menu, too. Now build, install
+and reboot the new kernel as usual.
 
 Features:
 ---------
@@ -86,13 +49,7 @@ Troubleshooting:
 ----------------
 
 First of all you should check, if the driver has been loaded
-properly. If you get the following message in your /var/log/messages:
-
-Nov  6 17:06:31 tek01 kernel: ad1816_detect(530)
-Nov  6 17:06:31 tek01 kernel: Chip is not an AD1816 or chip is not active 
-
-you either used the wrong address for loading the driver, your chip is
-not an AD1816 or you forgot to initialize the card with isapnp.
+properly.
 
 If loading of the driver succeeds, but playback/capture fails, check
 if you used the correct values for irq, dma and dma2 when loading the module.
@@ -122,6 +79,6 @@ or:
 Bugreports, bugfixes and related questions should be sent via E-Mail to:
   tek@rbg.informatik.tu-darmstadt.de
 
-
 Thorsten Knabe <tek@rbg.informatik.tu-darmstadt.de>
-          Last modified: 1999/05/02
+Christoph Hellwig <hch@caldera.de>
+	Last modified: 2000/09/20
diff --git a/Documentation/sound/ESS b/Documentation/sound/ESS
index 38d97ba97..bba93b4d2 100644
--- a/Documentation/sound/ESS
+++ b/Documentation/sound/ESS
@@ -1,9 +1,10 @@
 Documentation for the ESS AudioDrive chips
 
-In 2.2 kernels the SoundBlaster driver not only tries to detect an ESS chip, it
+In 2.4 kernels the SoundBlaster driver not only tries to detect an ESS chip, it
 tries to detect the type of ESS chip too. The correct detection of the chip 
-doesn't always succeed however, so the default behaviour is 2.0 behaviour
-which means: only detect ES688 and ES1688.
+doesn't always succeed however, so unless you use the kernel isapnp facilities
+(and you chip is pnp capable) the default behaviour is 2.0 behaviour which
+means: only detect ES688 and ES1688.
 
 All ESS chips now have a recording level setting. This is a need-to-have for
 people who want to use their ESS for recording sound.
diff --git a/Documentation/sound/ESS1868 b/Documentation/sound/ESS1868
index 8fb778925..55e922f21 100644
--- a/Documentation/sound/ESS1868
+++ b/Documentation/sound/ESS1868
@@ -2,17 +2,21 @@ Documentation for the ESS1868F AudioDrive PnP sound card
 
 The ESS1868 sound card is a PnP ESS1688-compatible 16-bit sound card.
 
-Notes about configuring the sound card:
+It should be automatically detected by the Linux Kernel isapnp support when you
+load the sb.o module. Otherwise you should take care of:
 
   *  The ESS1868 does not allow use of a 16-bit DMA, thus DMA 0, 1, 2, and 3
      may only be used.
 
   *  isapnptools version 1.14 does work with ESS1868.  Earlier versions might
      not.
-  
+
   *  Sound support MUST be compiled as MODULES, not statically linked
      into the kernel.
-  
+
+
+NOTE: this is only needed when not using the kernel isapnp support!
+
 For configuring the sound card's I/O addresses, IRQ and DMA, here is a
 sample copy of the isapnp.conf directives regarding the ESS1868:
 
@@ -47,38 +51,5 @@ the sound modules with the proper I/O information.  Here is my setup:
 /sbin/insmod opl3 io=0x388
 /sbin/insmod v_midi
 
-opl3 is the FM synthesizer--I have not tried the SoftOSS wavetable
-synthesizer yet, but I assume it would work as well.  Also, doing:
-/sbin/insmod opl3
-/sbin/insmod adlib_card io=0x388
-works, but I believe the sound quality is a bit distorted when playing MIDI
-files.
-
-When using the above setup, my /proc/sound gives the following:
-
-OSS/Free:3.8s2++-971130
-Load type: Driver loaded as a module
-Kernel: Linux scitus.dyn.ml.org 2.1.104 #1 SMP Sun May 24 11:04:27 EDT 1998 i486
-Config options: 0
-
-Installed drivers: 
-
-Card config: 
-
-Audio devices:
-0: ESS ES1688 AudioDrive (rev 11) (3.1)
-
-Synth devices:
-0: Yamaha OPL-3
-
-Midi devices:
-0: Loopback MIDI Port 1
-1: Loopback MIDI Port 2
-
-Timers:
-0: System clock
-
-Mixers:
-0: Sound Blaster
-
-
+opl3 is the FM synthesizer
+/sbin/insmod opl3 io=0x388
diff --git a/Documentation/sound/INSTALL.awe b/Documentation/sound/INSTALL.awe
index 629084d60..72219acb2 100644
--- a/Documentation/sound/INSTALL.awe
+++ b/Documentation/sound/INSTALL.awe
@@ -9,12 +9,9 @@
 If you're using PnP cards, the initialization of PnP is required
 before loading this driver.  You have now three options:
   1. Use isapnptools.
-  2. Install PnP kernel driver patch.
+  2. Use in-kernel isapnp support.
   3. Initialize PnP on DOS/Windows, then boot linux by loadlin.
 In this document, only the case 1 case is treated.
-For the case 2, please refer to the instruction in PnP driver project.
-The home page of PnP driver project is the following URL:
-	http://www-jcr.lmh.ox.ac.uk/~pnp/
 
 ----------------------------------------------------------------
 * Installation on Red Hat 5.0 Sound Driver
diff --git a/Documentation/sound/Introduction b/Documentation/sound/Introduction
index 86aa069c1..289e03c7e 100644
--- a/Documentation/sound/Introduction
+++ b/Documentation/sound/Introduction
@@ -27,6 +27,8 @@ History:
                    added info on OSS and ALSA.
 1.1.1  19991031	   Added notes on sound-slot- and sound-service.
 			(Alan Cox)
+1.1.2  20000920    Modified for Kernel 2.4 (Christoph Hellwig)
+
 
 Modular Sound Drivers:
 ======================
@@ -46,17 +48,13 @@ Alan's comments in linux/drivers/sound/README.FIRST:
   forums for bug reporting.
 
 The modular sound drivers may be loaded via insmod or modprobe.  
-To support all the various sound modules, there are three general 
+To support all the various sound modules, there are two general 
 support modules that must be loaded first:
  
    soundcore.o:   Top level handler for the sound system, provides
                   a set of functions for registration of devices
                   by type.
 
-   soundlow.o:    Low-level sound drivers which are not part of 
-                  OSS/Lite (Open Sound System), including SB32/AWE
-                  synthesizer, etc.
-
    sound.o:       Common sound functions required by all modules.
 
 For the specific sound modules (e.g., sb.o for the Soundblaster), 
@@ -255,6 +253,9 @@ send me an E-MAIL.  PCI sound cards should not have this problem.a
 Since this was originally release, I have received a couple of 
 mails from people who have accomplished this!
 
+NOTE: In Linux 2.4 the Sound Blaster driver (and only this one yet)
+supports multiple cards with one module by default.
+Read the file 'Soundblaster' in this directory for details.
 
 Sound Problems:
 ===============
@@ -277,8 +278,7 @@ in the Sound-HOWTO).
       and /proc/dma.  Are you trying to use an address,
       IRQ or DMA port that another device is using?
   
-  C)  Check (cat) /proc/sys/pnp (if this exists, you 
-      may need a kernel patch to get this device).
+  C)  Check (cat) /proc/isapnp
   
   D)  Inspect your /var/log/messages file.  Often that will 
       indicate what IRQ or IO port could not be obtained.
@@ -332,8 +332,9 @@ Configuring Sound:
 
 There are several ways of configuring your sound:
 
-1)  Hardcoded in the kernel at compile time (not applicable when
-    using sound modules).  This was the OLD way!
+1)  On the kernel command line (when using the sound driver(s)
+    compiled in the kernel). Check the driver source and
+    documentation for details.
 
 2)  On the command line when using insmod or in a bash script
     using command line calls to load sound.
@@ -345,6 +346,10 @@ There are several ways of configuring your sound:
 5)  Via the OSS soundconf program (with the commercial version
     of the OSS driver.
 
+6)  By just loading the module and let isapnp do everything relevant
+    for you. This works only with a few drivers yet and - of course -
+    only with isapnp hardware.
+
 And I am sure, several other ways.  
 
 Anyone want to write a linuxconf module for configuring sound?
diff --git a/Documentation/sound/NEWS b/Documentation/sound/NEWS
new file mode 100644
index 000000000..0486771e2
--- /dev/null
+++ b/Documentation/sound/NEWS
@@ -0,0 +1,42 @@
+Linux 2.4 Sound Changes
+2000-September-25
+Christoph Hellwig, <hch@caldera.de>
+
+
+
+=== isapnp support
+
+The Linux 2.4 Kernel does have reliable in-kernel isapnp support.
+Some drivers (sb.o, ad1816.o awe_wave.o) do now support automatically
+detecting and configuring isapnp devices.
+If you have a not yet supported isapnp soundcard, mail me the content
+of '/proc/isapnp' on your system and some information about your card
+and its driver(s) so I can try to get isapnp working for it.
+
+
+
+=== soundcard resources on kernel commandline
+
+Before Linux 2.4 you had to specify the resources for sounddrivers
+statically linked into the kernel at compile time
+(in make config/menuconfig/xconfig). In Linux 2.4 the ressources are
+now specified at the boot-time kernel commandline (e.g. the lilo
+'append=' line or everything that's after the kernel name in grub).
+Read the Configure.help entry for your card for the parameters.
+
+
+=== softoss is gone
+
+In Linux 2.4 the softoss in-kernel software synthesizer is no more aviable.
+Use a user space software synthesizer like timidity instead.
+
+
+
+=== /dev/sndstat and /proc/sound are gone
+
+In older Linux versions those files exported some information about the
+OSS/Free configuration to userspace. In Linux 2.3 they were removed because
+they did not support the growing number of pci soundcards and there were
+some general problems with this interface.
+
+
diff --git a/Documentation/sound/PSS-updates b/Documentation/sound/PSS-updates
new file mode 100644
index 000000000..004e894af
--- /dev/null
+++ b/Documentation/sound/PSS-updates
@@ -0,0 +1,88 @@
+	This file contains notes for users of PSS sound cards who wish to use the 
+newly added features of the newest version of this driver.
+
+	The major enhancements present in this new revision of this driver is the 
+addition of two new module parameters that allow you to take full advantage of 
+all the features present on your PSS sound card.  These features include the 
+ability to enable both the builtin CDROM and joystick ports.
+
+pss_enable_joystick
+
+	This parameter is basically a flag.  A 0 will leave the joystick port 
+disabled, while a non-zero value would enable the joystick port.  The default 
+setting is pss_enable_joystick=0 as this keeps this driver fully compatable 
+with systems that were using previous versions of this driver.  If you wish to 
+enable the joystick port you will have to add pss_enable_joystick=1 as an 
+argument to the driver.  To actually use the joystick port you will then have 
+to load the joystick driver itself.  Just remember to load the joystick driver 
+AFTER the pss sound driver.
+
+pss_cdrom_port
+
+	This parameter takes a port address as its parameter.  Any available port 
+address can be specified to enable the CDROM port, except for 0x0 and -1 as 
+these values would leave the port disabled.  Like the joystick port, the cdrom 
+port will require that an appropiate CDROM driver be loaded before you can make 
+use of the newly enabled CDROM port.  Like the joystick port option above, 
+remember to load the CDROM driver AFTER the pss sound driver.  While it may 
+differ on some PSS sound cards, all the PSS sound cards that I have seen have a 
+builtin Wearnes CDROM port.  If this is the case with your PSS sound card you 
+should load aztcd with the appropiate port option that matches the port you 
+assigned to the CDROM port when you loaded your pss sound driver.  (ex. 
+modprobe pss pss_cdrom_port=0x340 && modprobe aztcd aztcd=0x340)  The default 
+setting of this parameter leaves the CDROM port disabled to maintain full 
+compatability with systems using previous versions of this driver.
+
+	Other options have also been added for the added convenience and utility 
+of the user.  These options are only available if this driver is loaded as a 
+module.
+
+pss_no_sound
+
+	This module parameter is a flag that can be used to tell the driver to 
+just configure non-sound components.  0 configures all components, a non-0 
+value will only attept to configure the CDROM and joystick ports.  This 
+parameter can be used by a user who only wished to use the builtin joystick 
+and/or CDROM port(s) of his PSS sound card.  If this driver is loaded with this 
+parameter and with the paramter below set to true then a user can safely unload 
+this driver with the following command "rmmod pss && rmmod ad1848 && rmmod 
+mpu401 && rmmod sound && rmmod soundcore" and retain the full functionality of 
+his CDROM and/or joystick port(s) while gaining back the memory previously used 
+by the sound drivers.  This default setting of this parameter is 0 to retain 
+full behavioral compatability with previous versions of this driver.
+
+pss_keep_settings
+
+	This parameter can be used to specify whether you want the driver to reset 
+all emulations whenever its unloaded.  This can be useful for those who are 
+sharing resources (io ports, IRQ's, DMA's) between different ISA cards.  This 
+flag can also be useful in that future versions of this driver may reset all 
+emulations by default on the driver's unloading (as it probably should), so 
+specifying it now will ensure that all future versions of this driver will 
+continue to work as expected.  The default value of this parameter is 1 to 
+retain full behavioral compatability with previous versions of this driver.
+
+pss_firmware
+
+	This parameter can be used to specify the file containing the firmware 
+code so that a user could tell the driver where that file is located instead 
+of having to put it in a predefined location with a predefined name.  The 
+default setting of this parameter is "/etc/sound/pss_synth" as this was the 
+path and filename the hardcoded value in the previous versions of this driver.
+
+Examples:
+
+# Normal PSS sound card system, loading of drivers.
+# Should be specified in an rc file (ex. Slackware uses /etc/rc.d/rc.modules).
+
+/sbin/modprobe pss pss_io=0x220 mpu_io=0x338 mpu_irq=9 mss_io=0x530 mss_irq=10 mss_dma=1 pss_cdrom_port=0x340 pss_enable_joystick=1
+/sbin/modprobe aztcd aztcd=0x340
+/sbin/modprobe joystick
+
+# System using the PSS sound card just for its CDROM and joystick ports.
+# Should be specified in an rc file (ex. Slackware uses /etc/rc.d/rc.modules).
+
+/sbin/modprobe pss pss_io=0x220 pss_cdrom_port=0x340 pss_enable_joystick=1 pss_no_sound=1
+/sbin/rmmod pss && /sbin/rmmod ad1848 && /sbin/rmmod mpu401 && /sbin/rmmod sound && /sbin/rmmod soundcore  # This line not needed, but saves memory.
+/sbin/modprobe aztcd aztcd=0x340
+/sbin/modprobe joystick
diff --git a/Documentation/usb/CREDITS b/Documentation/usb/CREDITS
index e05f4d43f..5eb41a557 100644
--- a/Documentation/usb/CREDITS
+++ b/Documentation/usb/CREDITS
@@ -5,6 +5,7 @@ order by last name).  I'm sure this list should be longer, its
 difficult to maintain, add yourself with a patch if desired.
 
   Georg Acher <acher@informatik.tu-muenchen.de>
+  David Brownell <dbrownell@users.sourceforge.net>
   Alan Cox <alan@lxorguk.ukuu.org.uk>
   Randy Dunlap <randy.dunlap@intel.com>
   Johannes Erdfelt <jerdfelt@sventech.com>
@@ -14,6 +15,7 @@ difficult to maintain, add yourself with a patch if desired.
   Greg Kroah-Hartman <greg@kroah.com>
   Pavel Machek <pavel@suse.cz>
   Paul Mackerras <paulus@cs.anu.edu.au>
+  Petko Manlolov <petkan@dce.bg>
   David E. Nelson <dnelson@jump.net>
   Vojtech Pavlik <vojtech@suse.cz>
   Bill Ryder <bryder@sgi.com>
@@ -112,6 +114,10 @@ THANKS file in Inaky's driver):
 	  serial converter, and the documentation for the device to
 	  allow a driver to be written.
 
+	- Thanks to ADMtek for providing Pegasus and Pegasus II
+	  evaluation boards, specs and valuable advices during
+	  the driver development.
+	
         And thanks go to (hey! in no particular order :)
 
         - Oren Tirosh <orenti@hishome.net>, for standing so patiently
diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt
index 6cfd89ef3..7d99567ad 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/usb/URB.txt
@@ -26,6 +26,7 @@ You only have read/write the data from/to the buffers in the completion
 handler, the continuous streaming itself is transparently done by the 
 URB-machinery.
 
+
 1.2. The URB structure
 
 typedef struct urb
@@ -43,7 +44,7 @@ typedef struct urb
 
 // status after each completion
 	int status;                     // returned status
-	unsigned int transfer_flags;    // ASAP, SP_OK, EARLY_COMPLETE
+	unsigned int transfer_flags;    // ASAP, SP_OK, etc.
 
 // for data stage (CTRL), BULK, INT and ISO
 	void *transfer_buffer;          // associated data buffer
@@ -68,6 +69,7 @@ typedef struct urb
 	iso_packet_descriptor_t  iso_frame_desc[0];
 } urb_t, *purb_t;
 
+
 1.3. How to get an URB?
 
 URBs are allocated with the following call
@@ -85,6 +87,7 @@ To free an URB, use
 This call also may free internal (host controller specific) memory in the
 future.
 
+
 1.4. What has to be filled in?
 
 Depending on the type of transaction, there are some macros 
@@ -102,10 +105,10 @@ For ASAP set USB_ISO_ASAP in transfer_flags.
 If short packets should NOT be tolerated, set USB_DISABLE_SPD in 
 transfer_flags.
 
-Usually, (to reduce restart time) the completion handler is called
-AFTER the URB re-submission. You can get the other way by setting
-USB_URB_EARLY_COMPLETE in transfer_flags. This is implicit for
-INT transfers.
+Usually, to reduce restart time, the completion handler is called
+AFTER the URB re-submission.  However, it is called BEFORE URB
+re-submission for INT transfers that are being continued.
+
 
 1.5. How to submit an URB?
 
@@ -133,9 +136,12 @@ execution cannot be scheduled later than 900 frames from the 'now'-time.
 The same applies to INT transfers, but here the seamless continuation is 
 independent of the transfer flags (implicitly ASAP).
 
+
 1.6. How to cancel an already running URB?
 
-Call
+For an URB which you've submitted, but which hasn't been returned to
+your driver by the host controller, call
+
 	int unlink_urb(purb_t purb)
 
 It removes the urb from the internal list and frees all allocated
@@ -143,6 +149,13 @@ HW descriptors. The status is changed to USB_ST_URB_KILLED. After
 unlink_urb() returns, you can safely free the URB with free_urb(urb)
 and all other possibly associated data (urb->context etc.)
 
+There is also an asynchronous unlink mode.  To use this, set the
+the USB_ASYNC_UNLINK flag in urb->transfer flags before calling
+usb_unlink_urb().  When using async unlinking, the URB will not
+normally be unlinked when unlink_urb() returns.  Instead, wait for
+the completion handler to be called.
+
+
 1.7. What about the completion handler?
 
 The completion handler is optional, but useful for fast data processing
@@ -158,6 +171,18 @@ In the completion handler, you should have a look at urb->status to
 detect any USB errors. Since the context parameter is included in the URB,
 you can pass information to the completion handler. 
 
+NOTE:  ***** WARNING *****
+AVOID using the urb->dev field in your completion handler; it's cleared
+as part of URB unlinking.  Instead, use urb->context to hold all the
+data your driver needs.
+
+NOTE:  ***** WARNING *****
+Also, NEVER SLEEP IN A COMPLETION HANDLER.  These are normally called
+during hardware interrupt processing.  If you can, defer substantial
+work to a tasklet (bottom half) to keep system latencies low.  You'll
+probably need to use spinlocks to protect data structures you manipulate
+in completion handlers.
+
 
 1.8. How to do isochronous (ISO) transfers?
 
@@ -184,11 +209,13 @@ queuing more than one ISO frame with ASAP to the same device&endpoint result
 in seamless ISO streaming. For continuous streaming you have to use URB
 linking. 
 
+
 1.9. How to start interrupt (INT) transfers?
 
-INT transfers are currently implemented with 8 different queues for intervals 
-for 1, 2, 4,... 128ms. Only one TD is allocated for each interrupt. After
-calling the completion handler, the TD is recycled.
+INT transfers are currently implemented with different queues for intervals 
+for 1, 2, 4,... 128ms. Only one URB is allocated for each interrupt. After
+calling the completion handler, that URB is recycled by the host controller
+driver (HCD).
 With the submission of one URB, the interrupt is scheduled until it is
 canceled by unlink_urb.
 
diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt
index 836661375..d1dccece5 100644
--- a/Documentation/usb/error-codes.txt
+++ b/Documentation/usb/error-codes.txt
@@ -42,6 +42,13 @@ USB_ST_URB_INVALID_ERROR
 
 -EMSGSIZE	endpoint message size is zero, do interface/alternate setting
 
+USB_ST_BANDWIDTH_ERROR
+-ENOSPC		The host controller's bandwidth is already consumed and
+		this request would push it past its allowed limit.
+
+-ESHUTDOWN	The host controller has been disabled due to some
+		problem that could not be worked around.
+
 
 **************************************************************************
 *                   Error codes returned by in urb->status               *
@@ -89,6 +96,8 @@ USB_ST_PARTIAL_ERROR
 USB_ST_URB_INVALID_ERROR
 -EINVAL			ISO madness, if this happens: Log off and go home
 
+-ECONNRESET		the URB is being unlinked asynchronously
+
 **************************************************************************
 *              Error codes returned by usbcore-functions                 *
 *           (expect also other submit and transfer status codes)         *
diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt
index b15e68176..304a1ec90 100644
--- a/Documentation/usb/ov511.txt
+++ b/Documentation/usb/ov511.txt
@@ -6,14 +6,16 @@ Author: Mark McClelland
 Homepage: http://alpha.dyndns.org/ov511
 
 NEW IN THIS VERSION:
- o Sensor detection fixes
- o More efficient/reliable buffer allocation
- o Many minor fixes
+ o Stability improvements
+ o Support for hue control
+ o 160x120 mostly working
+ o OV6620 color problems fixed
+ o More WebCam 3 detection improvements
 
 INTRODUCTION:
 
 This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
-Any camera using the OV511/OV511+ and the OV7610/20/20AE CCD should work.It 
+Any camera using the OV511/OV511+ and the OV7610/20/20AE CCD should work. It 
 supports streaming and capture of color or monochrome video via the Video4Linux
 API. Most V4L apps are compatible with it, but a few videoconferencing programs
 do not work yet. The following resolutions are supported: 640x480, 448x336,
@@ -195,20 +197,28 @@ MODULE PARAMETERS:
         both OV511 and OV511+ cameras, trial-and-error may be necessary for
         finding the optimum setting.
 
-  
+  NAME: retry_sync
+  TYPE: boolean
+  DEFAULT: 0
+  DESC: Prevent apps from timing out if frame is not done in time. This is
+        useful if you are having problems with Xawtv getting "stuck" on a frame
+        when your system is under heavy load.
+ 
 WORKING FEATURES:
- o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, and 320x240
- o YUV420 and YUV422P color
+ o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, 320x240, and
+   160x120
+ o RGB24, YUV420, YUV422, YUYV, and YUV422P color
  o Monochrome
- o Setting/getting of saturation, contrast and brightness (no hue yet; only
-   works with OV7610, not the OV7620 or OV7620AE)
+ o Setting/getting of saturation, contrast, brightness, and hue (only some of
+   them work the OV7620 and OV7620AE)
  o proc status reporting
 
 EXPERIMENTAL FEATURES:
  o fix_rgb_offset: Sometimes works, but other times causes errors with xawtv and
    corrupted frames. If you have a very fast CPU, you can try it.
  o Snapshot mode (only works with some read() based apps; see below for more)
- o read() support
+ o OV6620 sensor support
+ o GBR422 parsing
 
 TODO:
  o Fix the noise / grainy image problem.
@@ -216,25 +226,23 @@ TODO:
    frame rate quite a bit. OmniVision wouldn't tell me how the algorithm works,
    so we can't really work on that yet. Please kindly inform OmniVision that you
    would like them to release their specifications to the Linux community.
- o Get 160x120 working
- o YUV422 (and other color modes)
+ o YUV422
  o Get snapshot mode working with mmap().
  o Fix fixFrameRGBoffset(). It is not stable yet with streaming video.
- o Get hue (red/blue channel balance) adjustment working (in ov511_get_picture()
-   and ov511_set_picture())
  o Get autoadjust disable working
  o V4L2 support (Probably not until it goes into the kernel)
- o Fix I2C initialization. Some people are reporting problems with reading the
-   7610 registers. This could be due to timing differences, an excessive I2C
-   clock rate, or a problem with ov511_i2c_read().
+ o Creative WebCam III has problems initializing its sensor. This should be
+   fixed now, but if you still have problems let me know.
  o Get rid of the memory management functions (put them in videodev.c??)
- o Setting of contrast and brightness not working with 7620
+ o Setting of contrast and brightness not working with 7620/7620AE
  o Driver/camera state save/restore for when USB supports suspend/resume
  o Unstable on SMP systems
+ o OV7620/OV6620 experience frame corruption with moving objects
+ o OV6620 is too dark
 
 HOW TO CONTACT ME:
 
-You can email me at mmcclelland@delphi.com . Please prefix the subject line
+You can email me at mwm@i.am . Please prefix the subject line
 with "OV511: " so that I am certain to notice your message.
 
 CREDITS: