Merge with Linux 2.3.41.

16 files changed, 952 insertions, 243 deletions

diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index 4ea28a70c..701089489 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -4444,15 +4444,6 @@ CONFIG_SCSI_IPS
   does not work correctly without modification please contact the
   author by email at ipslinux@us.ibm.com.
 
-IBM ServeRAID Support
-CONFIG_SCSI_IPS
-  This is support for the IBM ServeRAID hardware RAID controllers.
-  Consult the SCSI-HOWTO, available via anonymous FTP from
-  ftp://metalab.unc.edu/pub/Linux/docs/HOWTO, and the file
-  README.ips in drivers/scsi for more information.  If this driver
-  does not work correctly without modification please contact the
-  author by email at ipslinux@us.ibm.com.
-
 BusLogic SCSI support
 CONFIG_SCSI_BUSLOGIC
   This is support for BusLogic MultiMaster and FlashPoint SCSI Host
@@ -8031,8 +8022,8 @@ CONFIG_USB_UHCI
   The module will be called usb-uhci.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
   
-OHCI-HCD (Compaq, iMacs, OPTi, SiS, ALi, ...) support?
-CONFIG_USB_OHCI_HCD
+OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support?
+CONFIG_USB_OHCI
   The Open Host Controller Interface is a standard by
   Compaq/Microsoft/National for accessing the USB PC hardware (also
   called USB host controller). If your USB host controller conforms
@@ -8041,11 +8032,11 @@ CONFIG_USB_OHCI_HCD
   chipsets - like SiS (actual 610, 610 and so on) or ALi (ALi IV, ALi V,
   Aladdin Pro..) - conform to this standard.
 
-  You may want to read the file Documentation/usb/ohci-hcd.txt.
+  You may want to read the file Documentation/usb/ohci.txt.
 
   This code 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 usb-ohci-hcd.o. If you want to compile it
+  The module will be called usb-ohci.o. If you want to compile it
   as a module, say M here and read Documentation/modules.txt.
 
 USB Human Interface Device (HID) support
@@ -8095,6 +8086,21 @@ CONFIG_INPUT_MOUSEDEV_MIX
   into one misc device. If you say N, you'll have a separate
   device for each your USB mouse.
 
+Support for digitizers
+CONFIG_INPUT_MOUSEDEV_DIGITIZER
+  Use this if you have a digitizer that doesn't emulate a mouse
+  itself, and want to use it as a mouse.
+
+Horizontal screen resolution
+CONFIG_INPUT_MOUSEDEV_SCREEN_X
+  For the mouse emulation to be correct, the mousedev driver needs
+  to know the screen resolution you are using (in X). 
+
+Vertical screen resolution
+CONFIG_INPUT_MOUSEDEV_SCREEN_Y
+  For the mouse emulation to be correct, the mousedev driver needs
+  to know the screen resolution you are using (in X). 
+
 Joystick support
 CONFIG_INPUT_JOYDEV
   Say Y here if you want your USB HID joystick or gamepad to be
@@ -8192,17 +8198,47 @@ CONFIG_USB_CPIA
   Say Y here if you want to connect this type of camera to your
   computer's USB port.
 
+  This driver uses the Video For Linux API.  You must enable
+  (Y or M in config) Video For Linux (under Character Devices)
+  to use this driver.  Information on this API and pointers to
+  "v4l" programs may be found on the WWW at
+  http://roadrunner.swansea.uk.linux.org/v4l.shtml .
+
   This code 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 cpia.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
 
+USB IBM (Xirlink) C-It Camera support
+CONFIG_USB_IBMCAM
+  Say Y here if you want to connect this type of camera to your
+  computer's USB port.
+
+  This driver uses the Video For Linux API.  You must enable
+  (Y or M in config) Video For Linux (under Character Devices)
+  to use this driver.  Information on this API and pointers to
+  "v4l" programs may be found on the WWW at
+  http://roadrunner.swansea.uk.linux.org/v4l.shtml .
+
+  This code 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 ibmcam.o. If you want to compile it as a
+  module, say M here and read Documentation/modules.txt. This camera
+  has several configuration options which can be specified when you
+  load the module. Read Documentation/usb/ibmcam.txt to learn more.
+
 USB OV511 Camera support
 CONFIG_USB_OV511
   Say Y here if you want to connect this type of camera to your
   computer's USB port. See Documentation/usb/ov511.txt for more
   information and for a list of supported cameras.
   
+  This driver uses the Video For Linux API.  You must enable
+  (Y or M in config) Video For Linux (under Character Devices)
+  to use this driver.  Information on this API and pointers to
+  "v4l" programs may be found on the WWW at
+  http://roadrunner.swansea.uk.linux.org/v4l.shtml .
+
   This code 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 ov511.o. If you want to compile it as a
@@ -8220,20 +8256,20 @@ CONFIG_USB_DC2XX
   The module will be called dc2xx.o. If you want to compile it as a
   module, say M here and read Documentation/modules.txt.
 
-USB SCSI (mass storage) support
-CONFIG_USB_SCSI
+USB Mass Storage support
+CONFIG_USB_STORAGE
   Say Y here if you want to connect USB mass storage devices to your
   computer's USB port.
 
   This code 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 usb-scsi.o. If you want to compile it as a
-  module, say M here and read Documentation/modules.txt.
+  The module will be called usb-storage.o. If you want to compile it
+  as a module, say M here and read Documentation/modules.txt.
 
-USB SCSI verbose debug
-CONFIG_USB_SCSI_DEBUG
-  Say Y here in order to have the USB SCSI code generate verbose
-  debugging messages.
+USB Mass Storage verbose debug
+CONFIG_USB_STORAGE_DEBUG
+  Say Y here in order to have the USB Mass Storage code generate
+  verbose debugging messages.
 
 USS720 parport driver
 CONFIG_USB_USS720
@@ -10607,9 +10643,10 @@ CONFIG_RTC
   major number 10 and minor number 135 using mknod ("man mknod"), you
   will get access to the real time clock built into your computer.
   Every PC has such a clock built in. It can be used to generate
-  signals from as low as 1Hz up to 8192Hz, and can also be used as a
-  24 hour alarm. It reports status information via the file /proc/rtc
-  and its behaviour is set by various ioctls on /dev/rtc.
+  signals from as low as 1Hz up to 8192Hz, and can also be used
+  as a 24 hour alarm. It reports status information via the file
+  /proc/driver/rtc and its behaviour is set by various ioctls on
+  /dev/rtc.
 
   If you run Linux on a multiprocessor machine and said Y to
   "Symmetric Multi Processing" above, you should say Y here to read
@@ -11915,6 +11952,11 @@ CONFIG_SUN_MOSTEK_RTC
 
   Say Y here unless you are building a special purpose kernel.
 
+JavaStation OS Flash SIMM (EXPERIMENTAL)
+CONFIG_SUN_JSFLASH
+  This option enables a driver for JavaStation OS Flash driver.
+  Say N unless you want to boot from your Flash SIMM.
+
 #Siemens SAB82532 serial support
 #CONFIG_SAB82532
 ###
@@ -12294,13 +12336,11 @@ CONFIG_ATARI_SCSI_TOSHIBA_DELAY
   use a Toshiba CD-ROM drive; otherwise, the option is not needed and
   would impact performance a bit, so say N.
 
-Hades SCSI DMA emulator (EXPERIMENTAL)
+Hades SCSI DMA emulator
 CONFIG_TT_DMA_EMUL
   This option enables code which emulates the TT SCSI DMA chip on the
   Hades. This increases the SCSI transfer rates at least ten times
-  compared to PIO transfers. Note that this code is experimental and
-  has only been tested on a Hades with a 68060 processor. Before you
-  use this, make backups of your entire hard disk.
+  compared to PIO transfers.
 
 Ariadne support
 CONFIG_ARIADNE
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
new file mode 100644
index 000000000..c48758677
--- /dev/null
+++ b/Documentation/DMA-mapping.txt
@@ -0,0 +1,143 @@
+			Dynamic DMA mapping
+			===================
+
+		 David S. Miller <davem@redhat.com>
+		 Richard Henderson <rth@cygnus.com>
+		  Jakub Jelinek <jakub@redhat.com>
+
+Most of the 64bit platforms have special hardware that translates bus
+addresses (DMA addresses) to physical addresses similarly to how page
+tables and/or TLB translate virtual addresses to physical addresses.
+This is needed so that e.g. PCI devices can access with a Single Address
+Cycle (32bit DMA address) any page in the 64bit physical address space.
+Previously in Linux those 64bit platforms had to set artificial limits on
+the maximum RAM size in the system, so that the virt_to_bus() static scheme
+works (the DMA address translation tables were simply filled on bootup
+to map each bus address to the physical page __pa(bus_to_virt())).
+
+So that Linux can use the dynamic DMA mapping, it needs some help from the
+drivers, namely it has to take into account that DMA addresses should be
+mapped only for the time they are actually used and unmapped after the DMA
+transfer.
+
+The following API will work of course even on platforms where no such
+hardware exists, see e.g. include/asm-i386/pci.h for how it is implemented on
+top of the virt_to_bus interface.
+
+First of all, you should make sure
+
+#include <linux/pci.h>
+
+is in your driver. This file defines a dma_addr_t type which should be
+used everywhere you hold a DMA (bus) address returned from the DMA mapping
+functions.
+
+There are two types of DMA mappings:
+- static DMA mappings which are usually mapped at driver initialization,
+  unmapped at the end and for which the hardware should not assume
+  sequential accesses (from both the DMA engine in the card and CPU).
+- streaming DMA mappings which are usually mapped for one DMA transfer,
+  unmapped right after it (unless you use pci_dma_sync below) and for which
+  hardware can optimize for sequential accesses.
+
+To allocate and map a static DMA region, you should do:
+
+	dma_addr_t dma_handle;
+
+	cpu_addr = pci_alloc_consistent(dev, size, &dma_handle);
+
+where dev is a struct pci_dev *. You should pass NULL for PCI like buses
+where devices don't have struct pci_dev (like ISA, EISA).
+This argument is needed because the DMA translations may be bus
+specific (and often is private to the bus which the device is attached to).
+Size is the length of the region you want to allocate.
+This routine will allocate RAM for that region, so it acts similarly to
+__get_free_pages (but takes size instead of page order).
+It returns two values: the virtual address which you can use to access it
+from the CPU and dma_handle which you pass to the card.
+The return address is guaranteed to be page aligned.
+
+To unmap and free such DMA region, you call:
+
+	pci_free_consistent(dev, size, cpu_addr, dma_handle);
+
+where dev, size are the same as in the above call and cpu_addr and
+dma_handle are the values pci_alloc_consistent returned.
+
+The streaming DMA mapping routines can be called from interrupt context.
+There are two versions of each map/unmap, one which map/unmap a single
+memory region, one which map/unmap a scatterlist.
+
+To map a single region, you do:
+
+	dma_addr_t dma_handle;
+
+	dma_handle = pci_map_single(dev, addr, size);
+
+and to unmap it:
+
+	pci_unmap_single(dev, dma_handle, size);
+
+You should call pci_unmap_single when the DMA activity is finished, e.g.
+from interrupt which told you the DMA transfer is done.
+
+Similarly with scatterlists, you map a region gathered from several regions by:
+
+	int i, count = pci_map_sg(dev, sglist, nents);
+	struct scatterlist *sg;
+
+	for (i = 0, sg = sglist; i < count; i++, sg++) {
+		hw_address[i] = sg_dma_address(sg);
+		hw_len[i] = sg_dma_len(sg);
+	}
+
+where nents is the number of entries in the sglist.
+The implementation is free to merge several consecutive sglist entries
+into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
+consecutive sglist entries can be merged into one provided the first one
+ends and the second one starts on a page boundary - in fact this is a huge
+advantage for cards which either cannot do scatter-gather or have very
+limited number of scatter-gather entries) and returns the actual number
+of sg entries it mapped them too.
+Then you should loop count times (note: this can be less than nents times)
+and use sg_dma_address() and sg_dma_length() macros where you previously
+accessed sg->address and sg->length as shown above.
+
+To unmap a scatterlist, just call:
+
+	pci_unmap_sg(dev, sglist, nents);
+
+Again, make sure DMA activity finished.
+Every pci_map_{single,sg} call should have its pci_unmap_{single,sg}
+counterpart, because the bus address space is a shared resource (although
+in some ports the mapping is per each BUS so less devices contend for the
+same bus address space) and you could render the machine unusable by eating
+all bus addresses.
+
+If you need to use the same streaming DMA region multiple times and touch
+the data in between the DMA transfers, just map it
+with pci_map_{single,sg}, after each DMA transfer call either:
+
+	pci_dma_sync_single(dev, dma_handle, size);
+
+or:
+
+	pci_dma_sync_sg(dev, sglist, nents);
+
+and after the last DMA transfer call one of the DMA unmap routines
+pci_unmap_{single,sg}. If you don't touch the data from the first pci_map_*
+call till pci_unmap_*, then you don't have to call pci_sync_* routines.
+
+Drivers converted fully to this interface should not use virt_to_bus any
+longer, nor should they use bus_to_virt. Some drivers have to be changed a
+little bit, because there is no longer an equivalent to bus_to_virt in the
+dynamic DMA mapping scheme - you have to always store the DMA addresses
+returned by the pci_alloc_consistent and pci_map_single calls (pci_map_sg
+stores them in the scatterlist itself if the platform supports dynamic DMA
+mapping in hardware) in your driver structures and/or in the card registers.
+
+For PCI cards which recognize fewer address lines than 32 in Single
+Address Cycle, you should set corresponding pci_dev's dma_mask field to a
+different mask. The dma mapping routines then should either honour your request
+and allocate the DMA only with the bus address with bits set in your
+dma_mask or should complain that the device is not supported on that platform.
diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt
index 5db0ed332..1bc75744c 100644
--- a/Documentation/filesystems/udf.txt
+++ b/Documentation/filesystems/udf.txt
@@ -1,7 +1,7 @@
 *
 * ./Documentation/filesystems/udf.txt
 *
-UDF Filesystem version 0.8.9
+UDF Filesystem version 0.9.0
 
 If you encounter problems with reading UDF discs using this driver,
 please report them to linux_udf@hootie.lvld.hp.com, which is the
@@ -19,8 +19,6 @@ The following mount options are supported:
 	unhide		Show otherwise hidden files.
 	undelete	Show deleted files in lists.
 	strict		Set strict conformance (unused)
-	utf8		(unused)
-	iocharset	(unused)
 
 The remaining are for debugging and disaster recovery:
 
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index e432afc64..482fbecb0 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -64,8 +64,14 @@ inet_peer_gc_maxtime - INTEGER
 TCP variables: 
 
 tcp_syn_retries - INTEGER
-	Number of times initial SYNs for an TCP connection attempt will
-	be retransmitted. Should not be higher than 255.
+	Number of times initial SYNs for an active TCP connection attempt
+	will be retransmitted. Should not be higher than 255. Default value
+	is 5, which corresponds to ~180seconds.
+
+tcp_synack_retries - INTEGER
+	Number of times SYNACKs for a passive TCP connection attempt will
+	be retransmitted. Should not be higher than 255. Default value
+	is 5, which corresponds to ~180seconds.
 
 tcp_keepalive_time - INTEGER
 	How often TCP sends out keepalive messages when keepalive is enabled.
@@ -73,15 +79,76 @@ tcp_keepalive_time - INTEGER
 
 tcp_keepalive_probes - INTEGER
 	How many keepalive probes TCP sends out, until it decides that the
-	connection is broken.
+	connection is broken. Default value: 9.
+
+tcp_keepalive_interval - INTEGER
+	How frequently the probes are send out. Multiplied by
+	tcp_keepalive_probes it is time to kill not responding connection,
+	after probes started. Default value: 75sec i.e. connection
+	will be aborted after ~11 minutes of retries.
 
 tcp_retries1 - INTEGER
+	How many times to retry before deciding that somethig is wrong
+	and it is necessary to report this suspection to network layer.
+	Minimal RFC value is 3, it is default, which corresponds
+	to ~3sec-8min depending on RTO.
+
 tcp_retries2 - INTEGER
-tcp_max_delay_acks - INTEGER
+	How may times to retry before killing alive TCP connection.
+	RFC1122 says that the limit should be longer than 100 sec.
+	It is too small number.	Default value 15 corresponds to ~13-30min
+	depending on RTO.
+
+tcp_orphan_retries - INTEGER
+	How may times to retry before killing TCP connection, closed
+	by our side. Default value 7 corresponds to ~50sec-16min
+	depending on RTO. If you machine is loaded WEB server,
+	you should think about lowering this value, such sockets
+	may consume significant resources. Cf. tcp_max_orphans.
+
 tcp_fin_timeout - INTEGER
-tcp_max_ka_probes - INTEGER
-tcp_hoe_retransmits - INTEGER
-	Undocumented for now.
+	Time to hold socket in state FIN-WAIT-2, if it was closed
+	by our side. Peer can be broken and never close its side,
+	or even died unexpectedly. Default value is 60sec.
+	Usual value used in 2.2 was 180 seconds, you may restore
+	it, but remember that if your machine is even underloaded WEB server,
+	you risk to overflow memory with kilotons of dead sockets,
+	FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
+	because they eat maximum 1.5K of memory, but they tend
+	to live longer.	Cf. tcp_max_orphans.
+
+tcp_max_tw_buckets - INTEGER
+	Maximal number of timewait sockets held by system simultaneously.
+	If this number is exceeded time-wait socket is immediately destroyed
+	and warning is printed. This limit exists only to prevent
+	simple DoS attacks, you _must_ not lower the limit artificially,
+	but rather increase it (probably, after increasing installed memory),
+	if network conditions require more than default value.
+
+tcp_tw_recycle - BOOLEAN
+	Enable fast recycling TIME-WAIT sockets. Default value is 1.
+	It should not be changed without advice/request of technical
+	experts.
+
+tcp_max_orphans - INTEGER
+	Maximal number of TCP sockets not attached to any user file handle,
+	held by system.	If this number is exceeded orphaned connections are
+	reset immediately and warning is printed. This limit exists
+	only to prevent simple DoS attacks, you _must_ not rely on this
+	or lower the limit artificially, but rather increase it
+	(probably, after increasing installed memory),
+	if network conditions require more than default value,
+	and tune network services to linger and kill such states
+	more aggressivley. Let me to remind again: each orphan eats
+	up to ~64K of unswappable memory.
+
+tcp_abort_on_overflow - BOOLEAN
+	If listening service is too slow to accept new connections,
+	reset them. Default state is FALSE. It means that if overflow
+	occured due to a burst, connection will recover. Enable this
+	option _only_ if you are really sure that listening daemon
+	cannot be tuned to accept connections faster. Enabling this
+	option can harm clients of your server.
 
 tcp_syncookies - BOOLEAN
 	Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
@@ -89,15 +156,36 @@ tcp_syncookies - BOOLEAN
 	overflows. This is to prevent against the common 'syn flood attack'
 	Default: FALSE
 
+	Note, that syncookies is fallback facility.
+	It MUST NOT be used to help highly loaded servers to stand
+	against legal connection rate. If you see synflood warnings
+	in your logs, but investigation	shows that they occur
+	because of overload with legal connections, you should tune
+	another parameters until this warning disappear.
+	See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
+
+	syncookies seriously violate TCP protocol, do not allow
+	to use TCP extensions, can result in serious degradation
+	of some services (f.e. SMTP relaying), visible not by you,
+	but your clients and relays, contacting you. While you see
+	synflood warnings in logs not being really flooded, your server
+	is seriously misconfigured.
+
 tcp_stdurg - BOOLEAN
 	Use the Host requirements interpretation of the TCP urg pointer field.
 	Most hosts use the older BSD interpretation, so if you turn this on
 	Linux might not communicate correctly with them.	
 	Default: FALSE 
 	
-tcp_syn_taildrop  - BOOLEAN
 tcp_max_syn_backlog - INTEGER
-	Undocumented (work in progress)
+	Maximal number of remembered connection requests, which are
+	still did not receive an acknowldgement from connecting client.
+	Default value is 1024 for systems with more than 128Mb of memory,
+	and 128 for low memory machines. If server suffers of overload,
+	try to increase this number. Warning! If you make it greater
+	than 1024, it would be better to change TCP_SYNQ_HSIZE in
+	include/net/tcp.h to keep TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog
+	and to recompile kernel.
 
 tcp_window_scaling - BOOLEAN
 	Enable window scaling as defined in RFC1323.
@@ -116,8 +204,15 @@ tcp_retrans_collapse - BOOLEAN
 ip_local_port_range - 2 INTEGERS
 	Defines the local port range that is used by TCP and UDP to
 	choose the local port. The first number is the first, the 
-	second the last local port number. For high-usage systems
-	change this to 32768-61000.
+	second the last local port number. Default value depends on
+	amount of memory available on the system:
+	> 128Mb 32768-61000
+	< 128Mb 1024-4999 or even less.
+	This number defines number of active connections, which this
+	system can issue simultaneously to systems not supporting
+	TCP extensions (timestamps). With tcp_tw_recycle enabled
+	(i.e. by default) range 1024-4999 is enough to issue up to
+	2000 connections per second to systems supporting timestamps.
 
 icmp_echo_ignore_all - BOOLEAN
 icmp_echo_ignore_broadcasts - BOOLEAN
@@ -201,7 +296,7 @@ rp_filter - BOOLEAN
 
 	0 - No source validation. 
 
-	Default value is 0. Note that some distribution enable it
+	Default value is 0. Note that some distributions enable it
 	in startip scripts.
 
 Alexey Kuznetsov.
@@ -210,4 +305,4 @@ kuznet@ms2.inr.ac.ru
 Updated by:
 Andi Kleen
 ak@muc.de
-$Id: ip-sysctl.txt,v 1.11 2000/01/08 20:32:41 davem Exp $
+$Id: ip-sysctl.txt,v 1.13 2000/01/18 08:24:09 davem Exp $
diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt
index f93c51470..57dbe7a65 100644
--- a/Documentation/networking/smctr.txt
+++ b/Documentation/networking/smctr.txt
@@ -2,9 +2,7 @@ Text File for the SMC TokenCard TokenRing Linux driver (smctr.c).
         By Jay Schulist <jschlst@turbolinux.com>
 
 The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) 
-ISA adapters. Preliminary support for the SMC TokenCard Elite/A (8115T/A) 
-MCA adapter has been started but is not complete. (Contact me for information
-if you have the proper setup to finish the MCA parts).
+ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters.
 
 Latest information on this driver can be obtained on the Linux-SNA WWW site.
 Please point your browser to: http://www.linux-sna.org
diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt
index 5fc1afffc..f82ceb548 100644
--- a/Documentation/networking/wan-router.txt
+++ b/Documentation/networking/wan-router.txt
@@ -1,19 +1,26 @@
 ------------------------------------------------------------------------------
 WAN Router for Linux Operating System
 ------------------------------------------------------------------------------
+Version 2.1.1 - Nov 08, 1999
+Version 2.0.8 - Nov 02, 1999
+Version 2.0.7 - Aug 26, 1999
+Version 2.0.6 - Aug 17, 1999
+Version 2.0.5 - Aug 12, 1999
+Version 2.0.4 - Nov 26, 1998
+Version 2.0.3 - Aug 25, 1998
+Version 2.0.2 - Dec 09, 1997
 Version 2.0.1 - Nov 28, 1997
 Version 2.0.0 - Nov 06, 1997
 Version 1.0.3 - June 3, 1997
 Version 1.0.1 - January 30, 1997
-Author: Jaspreet Singh <jaspreet@sangoma.com>
-	Gene Kozin <genek@compuserve.com>
-Copyright (c) 1995-1997 Sangoma Technologies Inc.
+Author: Nenad Corbic <ncorbic@sangoma.com>
+Copyright (c) 1995-1999 Sangoma Technologies Inc.
 ------------------------------------------------------------------------------
 
 
 WARNING:  This Version of WANPIPE supports only the S508 and S508/FT1 cards.  
 IF YOU OWN A S502E OR A S508 CARD THEN PLEASE CONTACT SANGOMA TECHNOLOGIES FOR 
-AN UPGRADE.
+AN UPGRADE.  ONLY THE BiSYNC STREAMING CODE IS SUPPORTED ON S502E/S503 cards. 
 
 INTRODUCTION
 
@@ -129,11 +136,55 @@ product.
 
 REVISION HISTORY
 
+2.1.1   Nov 09, 1999 		- New code for S514PCI card
+                                - Completely redesigned drivers
+                                  fully tested and optimized.
+
+2.0.8   Nov 02, 1999            - Fixed up the X25API code.
+                                - Clear call bug fixed.i
+                                - Eanbled driver for multi-card
+                                  operation.                                
+
+2.0.7   Aug 26, 1999		- Merged X25API code into WANPIPE.
+				- Fixed a memeory leak for X25API
+				- Updated the X25API code for 2.2.X kernels.
+				- Improved NEM handling.
+
+2.0.6   Aug 17, 1999            - Kernel patch works for both 2.2.10 and 2.2.11 kernels
+                                - Fixed up 2.0.5 installation bugs
+                                - No functional difference between 2.0.6 and 2.0.5         
+
+2.0.5   Aug 12, 1999            - NEW PPP, interrupt drive code
+				- NEW X25 Xpipmon debugger
+				- Comments added to setup scripts
+				- Numerous bug fixes
+
+2.0.4	Nov 26, 1998		- NEW Cisco Dual Port support. 
+				- NEW support for BiSync Streaming API.
+				- NEW support for HDLC (LAPB) API.
+				- WANPIPE provides an API for application 
+				  development using the BSD socket interface.
+
+2.0.3 	Aug 25, 1998		- NEW support for Cisco HDLC, with cpipemon 
+				  utility for monitoring
+				- CIR support for Frame-relay
+				- Support for PAP and CHAP for ppp has been 
+				  implemented
+				- Dynamic IP assignment for PPP
+				- Multiple channel IPX support for Frame-relay 
+				  and X25
+				- Inverse Arp support for Frame-relay
+				- FT1 Configuration utility for linux
+				- Man Pages for router.conf, router, sdladump,
+				  cfgft1, fpipemon, ppipemon and cpipemon
+
+2.0.2	Dev 09, 1997	      - Implemented PAP and CHAP for ppp.
+
 2.0.1	Nov 28, 1997	      -	Protection of "enable_irq()" while
                                 "disable_irq()" has been enabled from any other
                                 routine (for Frame Relay, PPP and X25).
-			      - Added additional Stats for Fpipemon and Ppipemon                              - Improved Load Sharing for multiple boards.
-
+			      - Added additional Stats for Fpipemon and Ppipemon
+                              - Improved Load Sharing for multiple boards.
 
 2.0.0   Nov 07, 1997          - Implemented protection of RACE conditions by
                                 critical flags for FRAME RELAY and PPP.
@@ -173,7 +224,7 @@ REVISION HISTORY
 1.0.1	January 30, 1997
 
 			      -	Implemented user-readable status and statistics
-				via /proc file system
+				via /proc filesystem
 
 1.0.0	December 31, 1996
 
diff --git a/Documentation/networking/wanpipe.txt b/Documentation/networking/wanpipe.txt
index 0be0c5dc1..7cb28178e 100644
--- a/Documentation/networking/wanpipe.txt
+++ b/Documentation/networking/wanpipe.txt
@@ -1,36 +1,23 @@
 ------------------------------------------------------------------------------
-WANPIPE(tm) Multiprotocol WAN Driver for Linux WAN Router
+Linux WAN Router Utilities Package
 ------------------------------------------------------------------------------
-Release 4.1
-November 17, 1997
-Author: Jaspreet Singh <jaspreet@sangoma.com>
-Copyright (c) 1995-1997 Sangoma Technologies Inc.
+Version 2.1.1
+Nov 08, 1999
+Author: Nenad Corbic <ncorbic@sangoma.com>
+Copyright (c) 1995-1999 Sangoma Technologies Inc.
 ------------------------------------------------------------------------------
 
 INTRODUCTION
 
-WANPIPE(tm) is a family of intelligent multiprotocol WAN communication adapters
-for personal computers (ISA bus) designed to provide PC connectivity to
-various communication links, such as leased lines and public data networks, at
-speeds up to T1/E1 using a variety of synchronous communications protocols,
-including frame relay, PPP, X.25, SDLC, etc.
+This is a set of utilities and shell scripts you need in order to be able to
+use Linux kernel-level WAN Router.  Please read WAN Router User's manual
+(router.txt) and WANPIPE driver documentation found in /usr/lib/router/doc
+directory for installation and configuration instructions.
 
-WANPIPE driver together with Linux WAN Router module allows you to build a
-relatively inexpensive, yet high-performance multiprotocol WAN router.  For
-more information about the Linux WAN Router please read the file
-Documentation/networking/wan-router.txt.  You must also obtain the WAN Tools
-package to be able to use the Linux WAN Router and WANPIPE driver.  The package
-is available via the Internet from Sangoma Technologies' anonymous FTP server:
+You can find the latest version of this software in /pub/linux directory on
+Sangoma Technologies' anonymous FTP server (ftp.sangoma.com). 
 
-	ftp.sangoma.com/pub/linux/wantools-X.Y.Z.tgz
-			or
-	ftp.sangoma.com/pub/linux/wanpipe-X.Y.Z.tgz
-
-The names of the packages differ only due to naming convention.  The 
-functionality of wantools and wanpipe packages are the same.  The latest 
-version of the WAN Drivers is wanpipe-2.0.0.
-
-For technical questions and/or comments please e-mail to jaspreet@sangoma.com.
+For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
 For general inquiries please contact Sangoma Technologies Inc. by
 
 	Hotline:	1-800-388-2475	(USA and Canada, toll free)
@@ -57,117 +44,214 @@ Ave, Cambridge, MA 02139, USA.
 
 
 
-NEW IN THIS RELEASE
-
- o This Version of WANPIPE supports only the S508 and S508/FT1 cards.  IF YOU
-   OWN A S502E OR A S508 CARD THEN PLEASE CONTACT SANGOMA TECHNOLOGIES FOR AN
-   UPGRADE.
- o Protection of "enable_irq()" while "disable_irq()" has been enabled from 
-   any other routine (for Frame Relay, PPP and X25).
- o Added additional Stats for Fpipemon and Ppipemon.
- o Improved Load Sharing for multiple boards
-
-
-FILE LIST
-
-drivers/net:
-	README.wanpipe	This file
-	sdladrv.c	SDLA support module source code
-	sdla_fr.c	SDLA Frame Relay source code
-	sdla_ppp.c	SDLA PPP source code
-	sdla_x25.c	SDLA X.25 source code
-	sdlamain.c	SDLA support source code
-
-include/linux:
-	sdla_x25.h	SDLA X.25 firmware API definitions
-	sdla_fr.h	SDLA frame relay firmware API definitions
-	sdla_ppp.h	SDLA PPP firmware API definitions
-	wanpipe.h	WANPIPE API definitions
-	sdladrv.h	SDLA support module API definitions
-	sdlasfm.h	SDLA firmware module definitions
-	router.h	
-
-
-REVISION HISTORY
-
-4.1	November 28, 1997
-        o Protection of "enable_irq()" while "disable_irq()" has been enabled 
-	  from any other routine (for Frame Relay, PPP and X25).
-        o Added additional Stats for Fpipemon and Ppipemon
-	o Improved Load Sharing for multiple boards
-
-
-4.0	November 06, 1997
- 	o Implemented better protection of RACE conditions by critical flags for
- 	  FRAME RELAY, PPP and X25.
- 	o DLCI List interrupt mode implemented for DLCI specific CIR.
- 	o IPX support for FRAME RELAY, PPP and X25.
- 	o IPX Server Support (MARS) for FRAME RELAY, PPP and X25.
- 	o More driver specific stats included. 
-	o MULTICAST for FRAME RELAY and PPP.
-
-3.1.0	January 30, 1997
-
-	o Implemented IOCTL for executing adapter commands.
-	o Fixed a bug in frame relay code causing driver configured as a FR
-	  switch to be stuck in WAN_DISCONNECTED mode.
-
-3.0.0	December 31, 1996
-
-	o Uses Linux WAN Router interface
-	o Added support for X.25 routing
-	o Miscellaneous bug fixes and performance improvements
-
-2.4.1	December 18, 1996
+ACKNOWLEDGEMENTS
 
-	o Added support for LMI and Q.933 frame relay link management
+This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
+by Sangoma Technologies Inc. for Linux 2.2.x.  Success of the WANPIPE
+together with the next major release of Linux kernel in summer 1996 commanded
+adequate changes to the WANPIPE code to take full advantage of new Linux
+features.
 
-2.3.0	October 17, 1996
+Instead of continuing developing proprietary interface tied to Sangoma WAN
+cards, we decided to separate all hardware-independent code into a separate
+module and defined two levels of interfaces - one for user-level applications
+and another for kernel-level WAN drivers.  WANPIPE is now implemented as a
+WAN driver compliant with the WAN Link Driver interface.  Also a general
+purpose WAN configuration utility and a set of shell scripts was developed to 
+support WAN router at the user level.
 
-	o All shell scripts use meta-configuration file
-	o Miscellaneous bug fixes
+Many useful ideas concerning hardware-independent interface implementation
+were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
+of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
 
-2.2.0	July 16, 1996
+With the new implementation of the APIs being incorporated into the WANPIPE,
+a special thank goes to Alan Cox in providing insight into BSD sockets.
 
-	o Compatible with Linux 2.0
-	o Added uninstall script
-	o User's Manual is available in HTML format
+Special thanks to all the WANPIPE users who performed field-testing, reported
+bugs and made valuable comments and suggestions that help us to improve this
+product.
 
-2.1.0	June 20, 1996
 
-	o Added support for synchronous PPP
-	o Added support for S503 adapter
-	o Added API for executing adapter commands
-	o Fixed a re-entrancy problem in frame relay driver
-	o Changed interface between SDLA driver and protocol support modules
-	o Updated frame relay firmware
 
-2.0.0	May 1, 1996
-
-	o Added interactive installation and configuration scripts
-	o Added System V-style start-up script
-	o Added dynamic memory window address selection in SDLA driver
-	o Miscellaneous bug fixes in SDLA driver
-	o Updated S508 frame relay firmware
-	o Changed SFM file format
+NEW IN THIS RELEASE
 
-1.0.0	February 12, 1996
+o Renamed startup script to wanrouter
+o Option to turn off/on each router 
+  separately
+o New source directory /usr/lib/wanrouter
+o New PPP driver 
+o X25 is not supported in this release 
+
+	
+PRODUCT COMPONENTS AND RELATED FILES
+
+/etc:
+	wanpipe1.conf	default router configuration file
+	wanrouter.rc	meta-configuration file (used by the Setup script)
+
+/lib/modules/X.Y.Z/misc:
+	wanrouter.o	router kernel loadable module
+
+/lib/modules/X.Y.Z/net:
+	sdladrv.o	Sangoma SDLA support module
+	wanpipe.o	Sangoma WANPIPE(tm) driver module
+
+/proc/net/wanrouter
+	Config		reads current router configuration
+	Status		reads current router status
+	{name}		reads WAN driver statistics
+
+/usr/sbin:
+	wanrouter	router start-up script
+	wanconfig	router configuration utility
+	sdladump	WANPIPE adapter memory dump utility
+        fpipemon        Monitor for Frame Relay
+        cpipemon        Monitor for Cisco HDLC
+
+/usr/lib/wanrouter:
+	README		this file
+	COPYING		GNU General Public License
+	Setup		installation script
+	Configure	configuration script
+	Filelist	distribution definition file
+
+/usr/lib/wanrouter/doc:
+	WANPIPE_USER_MANUAL.txt WAN Router User's Manual
+	WANPIPE_CONFIG.txt	WAN Configuration Manual
+
+/usr/lib/wanrouter/interfaces:
+	*		interface configuration files (TCP/IP configuration)
+
+/usr/lib/wanrouter/patches:
+	wanrouter-22.gz	patch for Linux kernel 2.2.10 and 2.2.11 
+			(compatible for all 2.2.X kernels)
+	wanrouter-20.gz patch for Linux kernel 2.0.36 
+
+	Fix_2.2.11.gz   patch to fix the 2.2.11 kernel so other patches
+                        can be applied properly.
+
+/usr/lib/wanrouter/samples:
+	interface	sample interface configuration file
+	wanpipe1.cpri 	CHDLC primary port
+     	wanpipe2.csec 	CHDLC secondary port
+     	wanpipe1.fr   	Frame Relay protocol
+     	wanpipe1.ppp  	PPP protocol ) 
+	wanrouter.rc	sample meta-configuration file
+
+/usr/lib/wanrouter/src:
+	*		wan-tools source code
+
+/usr/include/linux:
+	wanrouter.h	router API definitions
+	wanpipe.h	WANPIPE API definitions
+	sdladrv.h	SDLA support module API definitions
+	sdlasfm.h	SDLA firmware module definitions
 
-	o Final release
-	o Added support for Linux 1.3
-	o Updated S508 frame relay firmware
+/usr/src/linux/net/router:
+	*		router source code
 
-0.9.0	December 21, 1995
+/var/log:
+	wanrouter	router start-up log (created by the Setup script)
 
-	o Added SNAP encapsulation for routed frames
-	o Added support for the frame relay switch emulation mode
-	o Added support for S508 adapter
-	o Added capability to autodetect adapter type
-	o Miscellaneous bug fixes in SDLA and frame relay drivers
+/var/lock:
+	wanrouter	router lock file (created by the Setup script)
 
-0.1.0	October 12, 1995
+/usr/lib/wanrouter/wanpipe:
+	fr514.sfm	Frame relay firmware for Sangoma S508/S514 card
+	cdual514.sfm	Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
+	ppp514.sfm      PPP Firmware for Sangoma S508 and S514 cards
 
-	o Initial version
 
->>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
+REVISION HISTORY
 
+1.0.0	December 31, 1996	Initial version
+
+1.0.1	January 30, 1997	Status and statistics can be read via /proc
+				filesystem entries.
+
+1.0.2   April 30, 1997          Added UDP management via monitors.
+
+1.0.3	June 3, 1997		UDP management for multiple boards using Frame
+				Relay and PPP
+				Enabled continuous transmission of Configure 
+				Request Packet for PPP (for 508 only)
+				Connection Timeout for PPP changed from 900 to 0
+				Flow Control Problem fixed for Frame Relay
+
+1.0.4	July 10, 1997		S508/FT1 monitoring capability in fpipemon and
+				ppipemon utilities.
+				Configurable TTL for UDP packets.
+				Multicast and Broadcast IP source addresses are
+				silently discarded.
+
+1.0.5	July 28, 1997		Configurable T391,T392,N391,N392,N393 for Frame
+				Relay in router.conf.
+				Configurable Memory Address through router.conf 
+				for Frame Relay, PPP and X.25. (commenting this
+ 				out enables auto-detection).
+				Fixed freeing up received buffers using kfree()
+ 				for Frame Relay and X.25.
+				Protect sdla_peek() by calling save_flags(),
+				cli() and restore_flags().
+				Changed number of Trace elements from 32 to 20
+				Added DLCI specific data monitoring in FPIPEMON. 
+2.0.0	Nov 07, 1997		Implemented protection of RACE conditions by 
+				critical flags for FRAME RELAY and PPP.
+				DLCI List interrupt mode implemented.
+				IPX support in FRAME RELAY and PPP.
+				IPX Server Support (MARS)
+				More driver specific stats included in FPIPEMON
+				and PIPEMON.
+
+2.0.1	Nov 28, 1997		Bug Fixes for version 2.0.0.
+				Protection of "enable_irq()" while 
+				"disable_irq()" has been enabled from any other
+				routine (for Frame Relay, PPP and X25).
+				Added additional Stats for Fpipemon and Ppipemon
+				Improved Load Sharing for multiple boards
+
+2.0.2	Dec 09, 1997		Support for PAP and CHAP for ppp has been
+				implemented.
+
+2.0.3	Aug 15, 1998		New release supporting Cisco HDLC, CIR for Frame
+				relay, Dynamic IP assignment for PPP and Inverse
+				Arp support for Frame-relay.  Man Pages are 
+				included for better support and a new utility
+				for configuring FT1 cards.
+
+2.0.4	Dec 09, 1998	        Dual Port support for Cisco HDLC.
+				Support for HDLC (LAPB) API.
+				Supports BiSync Streaming code for S502E 
+				and S503 cards.
+				Support for Streaming HDLC API.
+				Provides a BSD socket interface for 
+				creating applications using BiSync
+   				streaming.        
+
+2.0.5   Aug 04, 1999 		CHDLC initializatin bug fix.
+				PPP interrupt driven driver: 
+  				Fix to the PPP line hangup problem.
+				New PPP firmware
+				Added comments to the startup SYSTEM ERROR messages
+				Xpipemon debugging application for the X25 protocol
+				New USER_MANUAL.txt
+				Fixed the odd boundary 4byte writes to the board.
+				BiSync Streaming code has been taken out.  
+				 Available as a patch.
+				Streaming HDLC API has been taken out.  
+				 Available as a patch.                 
+
+2.0.6   Aug 17, 1999		Increased debugging in statup scripts
+				Fixed insallation bugs from 2.0.5
+				Kernel patch works for both 2.2.10 and 2.2.11 kernels.
+				There is no functional difference between the two packages         
+
+2.0.7   Aug 26, 1999		o  Merged X25API code into WANPIPE.
+				o  Fixed a memeory leak for X25API
+				o  Updated the X25API code for 2.2.X kernels.
+				o  Improved NEM handling.   
+
+2.1.0	Oct 25, 1999		o New code for S514 PCI Card
+				o New CHDLC and Frame Relay drivers
+				o PPP and X25 are not supported in this release    
+>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 7718228ba..a7b22b4c2 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -22,8 +22,8 @@ character device) in the form of an unsigned long. The low byte contains
 the type of interrupt (update-done, alarm-rang, or periodic) that was
 raised, and the remaining bytes contain the number of interrupts since
 the last read.  Status information is reported through the pseudo-file
-/proc/rtc if the /proc filesystem was enabled. The driver has built in
-locking so that only one process is allowed to have the /dev/rtc
+/proc/driver/rtc if the /proc filesystem was enabled.  The driver has
+built in locking so that only one process is allowed to have the /dev/rtc
 interface open at a time.
 
 A user process can monitor these interrupts by doing a read(2) or a
diff --git a/Documentation/usb/CREDITS b/Documentation/usb/CREDITS
index 738b55efc..b1230f70a 100644
--- a/Documentation/usb/CREDITS
+++ b/Documentation/usb/CREDITS
@@ -12,6 +12,7 @@ difficult to maintain, add yourself with a patch if desired.
   ham <ham@unsuave.com>
   Bradley M Keryan <keryan@andrew.cmu.edu>
   Greg Kroah-Hartman <greg@kroah.com>
+  Pavel Machek <pavel@suse.cz>
   Paul Mackerras <paulus@cs.anu.edu.au>
   David E. Nelson <dnelson@jump.net>
   Vojtech Pavlik <vojtech@suse.cz>
diff --git a/Documentation/usb/ibmcam.txt b/Documentation/usb/ibmcam.txt
new file mode 100644
index 000000000..4d7ab56eb
--- /dev/null
+++ b/Documentation/usb/ibmcam.txt
@@ -0,0 +1,166 @@
+README for Linux device driver for the IBM "C-It" USB video camera
+
+INTRODUCTION:
+
+This driver does not use all features known to exist in
+the IBM camera. However most of needed features work well.
+
+This driver was developed using logs of observed USB traffic
+which was produced by standard Windows driver (c-it98.sys).
+I did not have any input from Xirlink. Some people asked about
+data sheets, but nothing came out of that. I didn't try.
+
+Video formats: 128x96, 176x144, 352x288
+Frame rate: 3 - 30 frames per second (FPS)
+External interface: USB
+Internal interface: Video For Linux (V4L)
+Supported controls:
+- by V4L: Contrast,  Brightness, Color, Hue
+- by driver options: frame rate, lighting conditions, video format,
+                     default picture settings, sharpness.
+
+SUPPORTED CAMERAS:
+
+IBM "C-It" camera, also known as "Xirlink PC Camera"
+The device uses proprietary ASIC (and compression method);
+it is manufactured by Xirlink. See http://www.xirlink.com
+
+WHAT YOU NEED:
+
+- An IBM C-it camera
+
+- A Linux box with USB support (2.3/2.4 or 2.2 w/backport)
+
+- A Video4Linux compatible frame grabber program such as xawtv.
+  
+HOW TO COMPILE THE DRIVER:
+
+You need to compile the driver only if you are a developer
+or if you want to make changes to the code. Most distributions
+precompile all modules, so you can go directly to the next
+section "HOW TO USE THE DRIVER".
+
+The driver consists of two files in usb/ directory:
+ibmcam.c and ibmcam.h These files are included into the
+Linux kernel build process if you configure the kernel
+for CONFIG_USB_IBMCAM. Run "make xconfig" and in USB section
+you will find the IBM camera driver. Select it, save the
+configuration and recompile.
+
+HOW TO USE THE DRIVER:
+
+I recommend to compile driver as a module. This gives you an
+easier access to its configuration. The camera has many more
+settings than V4L can operate, so some settings are done using
+module options.
+
+Typically module is installed with command 'modprobe', like this:
+
+# modprobe ibmcam framerate=1
+
+Alternatively you can use 'insmod' in similar fashion:
+
+# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1
+
+Module can be inserted with camera connected or disconnected.
+
+The driver can have options, though some defaults are provided.
+
+Driver options:
+
+Name            Type            Range [default] Example
+--------------  --------------  --------------  ------------------
+debug           Integer         0-9 [0]         debug=1
+flags           Integer         0-0xFF [0]      flags=0x0d
+framerate       Integer         0-6 [2]         framerate=1
+init_brightness Integer         0-255 [128]     init_brightness=100
+init_contrast   Integer         0-255 [192]     init_contrast=200
+init_color      Integer         0-255 [128]     init_color=130
+init_hue        Integer         0-255 [128]     init_hue=115
+lighting        Integer         0-2 [1]         lighting=2
+sharpness       Integer         0-6 [4]         sharpness=3
+videosize       Integer         0-2 [2]         videosize=1
+
+debug           You don't need this option unless you are a developer.
+                If you are a developer then you will see in the code
+                what values do what. 0=off.
+
+flags           This is a bit mask, and you can combine any number of
+                bits to produce what you want. Usually you don't want
+                any of extra features this option provides:
+
+                FLAGS_RETRY_VIDIOCSYNC  1  This bit allows to retry failed
+                                           VIDIOCSYNC ioctls without failing.
+                                           Will work with xawtv, will not
+                                           with xrealproducer. Default is
+                                           not set.
+                FLAGS_MONOCHROME        2  Activates monochrome (b/w) mode.
+                FLAGS_DISPLAY_HINTS     4  Shows colored pixels which have
+                                           magic meaning to developers.
+                FLAGS_OVERLAY_STATS     8  Shows tiny numbers on screen,
+                                           useful only for debugging.
+                FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers.
+
+framerate       This setting controls frame rate of the camera. This is
+                an approximate setting (in terms of "worst" ... "best")
+                because camera changes frame rate depending on amount
+                of light available. Setting 0 is slowest, 6 is fastest.
+                Beware - fast settings are very demanding and may not
+                work well with all video sizes. Be conservative.
+
+init_brightness These settings specify _initial_ values which will be
+init_contrast   used to set up the camera. If your V4L application has
+init_color      its own controls to adjust the picture then these
+init_hue        controls will be used too. These options allow you to
+                preconfigure the camera when it gets connected, before
+                any V4L application connects to it. Good for webcams.
+
+lighting        This option selects one of three hardware-defined
+                photosensitivity settings of the camera. 0=bright light,
+                1=Medium (default), 2=Low light. This setting affects
+                frame rate: the dimmer the lighting the lower the frame
+                rate (because longer exposition time is needed).
+
+sharpness       This option controls smoothing (noise reduction)
+                made by camera. Setting 0 is most smooth, setting 6
+                is most sharp. Be aware that CMOS sensor used in the
+                camera is pretty noisy, so if you choose 6 you will
+                be greeted with "snowy" image. Default is 4.
+
+videosize       This setting chooses one if three image sizes that are
+                supported by this driver. Camera supports more, but
+                it's difficult to reverse-engineer all formats.
+                Following video sizes are supported:
+
+                videosize=0     128x96
+                videosize=1     176x144
+                videosize=2     352x288
+
+                The last one (352x288) is the native size of the sensor
+                array, so it's the best resolution camera can yield.
+                Choose the image size you need. The smaller image can
+                support faster frame rate. Default is 352x288.
+
+WHAT NEEDS TO BE DONE:
+
+- The box freezes if working camera (with xawtv) is unplugged (OHCI).
+  Workaround: don't do that :) End the V4L application first.
+- Some USB frames are lost on high frame rates, though they shouldn't
+- ViCE compression (Xirlink proprietary) may improve frame rate
+- On occasion camera does not start properly; xawtv reports errors.
+  Workaround: reload the driver module. Reason: [1].
+- On occasion camera produces negative image (funny colors.)
+  Workaround: reload the driver module. Reason: [1].
+- The button on the camera is not used. I don't know how to get to it.
+
+[1]
+- Camera reports its status back to the driver; however I don't know
+  what returned data means. If camera fails at some initialization
+  stage then something should be done, and I don't do that because
+  I don't even know that some command failed.
+
+CREDITS:
+
+The code is based in no small part on the CPiA driver by Johannes Erdfelt,
+Randy Dunlap, and others. Big thanks to them for their pioneering work on that
+and the USB stack.
diff --git a/Documentation/usb/ohci-hcd.txt b/Documentation/usb/ohci.txt
index 37a637251..39a5ce482 100644
--- a/Documentation/usb/ohci-hcd.txt
+++ b/Documentation/usb/ohci.txt
@@ -21,7 +21,7 @@ The layer (functions) on top of it, is for interfacing to the alternate-usb devi
  * v0.1.0 1999/04/27 initial release
  
 to remove the module try:
-rmmod usb-ohci-hcd
+rmmod usb-ohci
 
 Features:
 - virtual root hub, all basic hub descriptors and commands (state: complete) 
diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt
index 3a73afc0d..fe84f11df 100644
--- a/Documentation/usb/ov511.txt
+++ b/Documentation/usb/ov511.txt
@@ -11,10 +11,6 @@ This is a preliminary version of my OV511 Linux device driver. Currently, it can
 grab a frame in color (YUV420) at 640x480 or 320x240 using either vidcat or
 xawtv. Other utilities may work but have not yet been tested.
 
-NOTE: 320x240 does not work reliably for me, and causes complete system crashes.
-      I recommend not using it until a later version, and if you do, run "sync"
-      first.
-
 SUPPORTED CAMERAS:
 ________________________________________________________
 Manufacturer     | Model          | Custom ID | Status
@@ -24,6 +20,7 @@ D-Link           | DSB-C300       | 3         | Working
 Creative Labs    | WebCam 3       | 21        | Working
 Lifeview         | RoboCam        | 100       | Untested
 AverMedia        | InterCam Elite | 102       | Working
+MediaForte       | MV300          | 112       | Untested
 --------------------------------------------------------
 
 Any camera using the OV511 and the OV7610 CCD should work with this driver. The
@@ -39,7 +36,8 @@ WHAT YOU NEED:
   http://www.ovt.com/omniusbp.html
 
 - A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv)
-  (see: http://www.exploits.org/v4l/ )
+    vidcat is part of the w3cam package:  http://www.hdk-berlin.de/~rasca/w3cam/
+    xawtv is available at:  http://www.in-berlin.de/User/kraxel/xawtv.html
 
 HOW TO USE IT:
 
@@ -83,7 +81,7 @@ directory:
 Now you should be able to run xawtv. Right click for the options dialog.
 
 WORKING FEATURES:
- o Color streaming/capture at 640x480 (reliably) and 320x240 (unreliably)
+ o Color streaming/capture at 640x480 and 320x240
  o YUV420 color
  o Setting/getting of saturation, contrast and brightness (no color yet)
 
diff --git a/Documentation/usb/scanner-hp-sane.txt b/Documentation/usb/scanner-hp-sane.txt
index 220bbb290..a1cbcd1b4 100644
--- a/Documentation/usb/scanner-hp-sane.txt
+++ b/Documentation/usb/scanner-hp-sane.txt
@@ -1,8 +1,10 @@
-Oct. 19, 1999
+Copyright (C) 1999, 2000 David E. Nelson
+
+Jan. 22, 2000
 
 CHANGES
 
-- Ammended for Linux-2.3.22+
+- Amended for Linux-2.3.40
 
 
 INTRODUCTION
@@ -11,23 +13,26 @@ This document will hopefully provide enough info on how to get SANE
 working with a Hewlett Packard USB capable scanner using the USB
 interface.  The majority of HP Scanners support the Scanner Control
 Language (SCL) which is both published by HP and supported by SANE.
-The only HP Scanner that I'm aware of that does not support SCL is the
-4200C.  All other HP scanners with USB interfaces should work (4100C,
-5200C, 6200C, and 6300C).  Of course as HP releases new scanners this
-information may change.
+The only HP Scanners that I'm aware of that do not support SCL are the
+4200C and the 3300C.  All other HP scanners with USB interfaces should
+work (4100C, 5200C, 6200C, and 6300C).  Of course as HP releases new
+scanners this information may change.
 
 
 REQUIREMENTS
 
 In order to get this running you'll need USB support in your kernel in
-addition to USB Scanner support.  Please refer to README.scanner
-for issues pertaining to Linux USB and USB Scanner support.
+addition to USB Scanner support.  Please refer to scanner.txt for
+issues pertaining to Linux USB and USB Scanner support.
 
 An installed version of SANE which is available from
 http://www.mostang.com/sane/.  Testing has been performed using
 version SANE-1.0.1.  For instructions on building and installing SANE,
 refer to the various README files within the SANE distribution.
 
+The latest SANE HP backend available from http://www.kirchgessner.net.
+At the time of this writing, version 0.83 was available.
+
 
 OK, I'VE INSTALLED SANE. SO WHAT DO I DO NOW?
 
diff --git a/Documentation/usb/scanner.txt b/Documentation/usb/scanner.txt
index 4b5de2be8..193035085 100644
--- a/Documentation/usb/scanner.txt
+++ b/Documentation/usb/scanner.txt
@@ -1,8 +1,10 @@
-Oct 19, 1999
+Copyright (C) 1999, 2000 David E. Nelson
+
+Jan. 22, 2000
 
 CHANGES
 
-- Ammended for linux-2.3.22+
+- Amended for linux-2.3.40
 - Appended hp_scan.c to end of this README
 - Removed most references to HP
 
@@ -12,49 +14,63 @@ OVERVIEW
 This README will address issues regarding how to configure the kernel
 to access a USB scanner.  Although the driver was originally conceived
 for USB HP scanners, it's general enough so that it can be used with
-other scanners.  Also, one can now pass the USB Vendor and
-Product ID's using module parameters for unknown scanners.  Refer to
-the document README.scanner_hp_sane for guidance on how to configure
-SANE to use a USB HP Scanner.
+other scanners.  Also, one can now pass the USB Vendor and Product
+ID's using module parameters for unknown scanners.  Refer to the
+document scanner_hp_sane.txt for guidance on how to configure SANE to
+use a USB HP Scanner.
 
 
 ADDITIONAL INFORMATION
 
 http://www.linux-usb.org/
-http://www.dynamine.net/linux-usb/HOWTO/
 
 
 REQUIREMENTS
 
 A host with a USB port.  Ideally, either a UHCI (Intel) or OHCI
 (Compaq and others) hardware port should work.  However, I've only
-been able to really use an OHCI controller.  I did have access to a
-system with a UHCI controller but some very limited testing did not
-produce satisfactory results.  Luke Ordelmans
-<postbus@ordelmans.demon.nl> has reported success using the UHCI host
-controller with kernel 2.3.18 and a ChainTech motherboard.  Here
-lately I've been having better success with the ohci-hcd driver.  But
-since Linux USB support is still in a state of constant development
-that may change at a later date.  I am confident that eventually all
-the host contollers will perform without incident.
+been able to really use an OHCI controller.  At the time of this
+writing, both uhci and ohci work with scanner.c *except* for the HP
+4100C which only works with ohci.  This problem is being investigated.
 
-A Linux kernel with USB support (preferably linux-2.3.18+)
+A Linux development kernel (2.3.x) with USB support enabled or a
+backported version to linux-2.2.x.  See http://www.linux-usb.org for
+more information on accomplishing this.
 
-A Linux kernel with USB Scanner support.
+A Linux kernel with USB Scanner support enabled.
 
+'lspci' which is only needed to determine the type of USB hardware
+available in your machine.
 
 CONFIGURATION
 
-Using `make menuconfig` or your prefered method for configuring the
-kernel, select 'Support for USB', 'OHCI/OHCI-HCD/UHCI' depending on
-your hardware, 'USB hub support', and 'USB Scanner support'.  Compile
-and install the modules (you may need to execute `depmod -a` to update
-the module dependencies).  Testing was performed only as modules,
-YMMV.
+Using `lspci -v`, determine the type of USB hardware available.
+
+  If you see something like:
+
+    USB Controller: ......
+    Flags: .....
+    I/O ports at ....
+
+  Then you have a UHCI based controller.
+
+  If you see something like:
+
+     USB Controller: .....
+     Flags: ....
+     Memory at .....
+
+  Then you have a OHCI based controller.
+
+Using `make menuconfig` or your preferred method for configuring the
+kernel, select 'Support for USB', 'OHCI/UHCI' depending on your
+hardware (determined from the steps above), 'USB Scanner support', and
+'Preliminary USB device filesystem'.  Compile and install the modules
+(you may need to execute `depmod -a` to update the module
+dependencies).  Testing was performed only as modules, YMMV.
 
 Add a device for the USB scanner:
-  linux-2.3.22 and above: `mknod /dev/usbscanner c 180 48`
-  linux-2.3.21 and below: `mknod /dev/usbscanner c 16 1`
+  `mknod /dev/usbscanner c 180 48`
 
 Set appropriate permissions for /dev/usbscanner (don't forget about
 group and world permissions).  Both read and write permissions are
@@ -66,36 +82,71 @@ Load the appropriate modules (if compiled as modules):
     modprobe usb-ohci
     modprobe scanner
 
-  OHCI-HCD:
-    modprobe usb-ohci-hcd
-    modprobe hub
-    modprobe scanner
-
   UHCI:
     modprobe usb-uhci
-    modprobe hub (don't know if this is required or not)
     modprobe scanner
 
 That's it.  SANE should now be able to access the device.  
 
 There is a small test program (hp_scan.c -- appended below) that can
 be used to test the scanner device if it's an HP scanner that supports
-SCL.  Its purpose is to test the driver without having to
-retrieve/configure SANE.  Hp_scan.c will scan the entire bed and put
-the output into a file called 'out.dat' in the current directory.  The
-data in the file is raw data so it's not very useful for imaging.
+SCL (Scanner Control Language).  Known HP scanner that support SCL are
+the 4100, 5200, 6200, the 6300 -- note that the 4200 is *not*
+supported since it does not understand SCL; it's also strongly
+suspected that the 3300 is not SCL compliant.  Hp_scan.c's purpose is
+to test the driver without having to retrieve/configure SANE.
+Hp_scan.c will scan the entire bed and put the output into a file
+called 'out.dat' in the current directory.  The data in the file is
+raw data so it's not very useful for imaging.
+
+
+SUPPORTED SCANNERS
+
+NOTE: Just because a product is listed here does not mean that
+applications exist that support the product.  It's in the hopes that
+this will allow developers a means to produce applications that will
+support the listed USB products.
+
+At the time of this writing, the following scanners were supported by
+scanner.c:
+
+  Hewlett Packard
+
+    3300, 4100, 4200, 5200, 6200, 6300, PhotoSmart S20
+
+  AGFA
+
+    SnapScan 1212U
+
+  Umax
+
+    Astra 2000U
+
+  Seiko/Epson
+
+    Perfection 636, Perfection 1200U
+
+  Mustek
+
+    1200 CU
+
+  User Specified.  See MODULE PARAMETERS for details.
 
 
 MODULE PARAMETERS
 
-If you have a device that wish to experiment with or try using this
-driver with, but the Vendor and Product ID's are not coded in, don't
-despair.  If the driver was compiled as a module, you can pass options
-to the driver.  Simply add 'options scanner vendor=0x####
+If you have a device that you wish to experiment with or try using
+this driver with, but the Vendor and Product ID's are not coded in,
+don't despair.  If the driver was compiled as a module, you can pass
+options to the driver.  Simply add 'options scanner vendor=0x####
 product=0x****' to the conf.modules/modules.conf file replacing the
 #'s and the *'s with the correct ID's.  The ID's can be retrieved from
 the messages file or using `cat /proc/bus/usb/devices` if USB /proc
-support was selected during kernel configuration.
+support was selected during kernel configuration.  In later kernels
+(2.3.38+), a new filesystem was introduced, usbdevfs.  To mount the
+filesystem, issue the command `mount -t usbdevfs /proc/bus/usb
+/proc/bus/usb`.  You can then issue ` cat /proc/bus/usb/devices` to
+extract USB device information.
 
 
 BUGS
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index e046ae2e5..e9e94510b 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -59,14 +59,12 @@ Current status:
   possible. The driver cleans up properly when the device is removed, or
   the connection is canceled on the Visor.
   
-  I write _should_ because communication does not seem to work properly at
-  this time. I am in contact with the developers at HandSpring and am
-  working at getting this to work properly.
-
-  There is a webpage for this portion of the driver at 
-  http://milosch.net/visor/ and a project set up with mailing lists for
-  it at :
-  http://sourceforge.net/project/?group_id=1404
+  When the device is connected, try talking to it on the second port
+  (this is usually /dev/ttyUSB1 if you do not have any other usb-serial
+  devices in the system.)
+
+  There is a webpage and mailing lists for this portion of the driver at: 
+  http://usbvisor.sourceforge.net/
 
 
 Belkin single port serial converter
diff --git a/Documentation/vm/balance b/Documentation/vm/balance
new file mode 100644
index 000000000..6202e4291
--- /dev/null
+++ b/Documentation/vm/balance
@@ -0,0 +1,81 @@
+Started Jan 2000 by Kanoj Sarcar <kanoj@sgi.com>
+
+Memory balancing is needed for non __GFP_WAIT as well as for non
+__GFP_IO allocations.
+
+There are two reasons to be requesting non __GFP_WAIT allocations:
+the caller can not sleep (typically intr context), or does not want
+to incur cost overheads of page stealing and possible swap io for
+whatever reasons.
+
+__GFP_IO allocation requests are made to prevent file system deadlocks.
+
+In the absence of non sleepable allocation requests, it seems detrimental
+to be doing balancing. Page reclamation can be kicked off lazily, that
+is, only when needed (aka zone free memory is 0), instead of making it
+a proactive process.
+
+That being said, the kernel should try to fulfill requests for direct
+mapped pages from the direct mapped pool, instead of falling back on
+the dma pool, so as to keep the dma pool filled for dma requests (atomic
+or not). A similar argument applies to highmem and direct mapped pages.
+OTOH, if there is a lot of free dma pages, it is preferable to satisfy
+regular memory requests by allocating one from the dma pool, instead
+of incurring the overhead of regular zone balancing.
+
+In 2.2, memory balancing/page reclamation would kick off only when the
+_total_ number of free pages fell below 1/64 th of total memory. With the
+right ratio of dma and regular memory, it is quite possible that balancing
+would not be done even when the dma zone was completely empty. 2.2 has
+been running production machines of varying memory sizes, and seems to be
+doing fine even with the presence of this problem. In 2.3, due to
+HIGHMEM, this problem is aggravated.
+
+In 2.3, zone balancing can be done in one of two ways: depending on the
+zone size (and possibly of the size of lower class zones), we can decide
+at init time how many free pages we should aim for while balancing any
+zone. The good part is, while balancing, we do not need to look at sizes
+of lower class zones, the bad part is, we might do too frequent balancing
+due to ignoring possibly lower usage in the lower class zones. Also,
+with a slight change in the allocation routine, it is possible to reduce
+the memclass() macro to be a simple equality.
+
+Another possible solution is that we balance only when the free memory
+of a zone _and_ all its lower class zones falls below 1/64th of the
+total memory in the zone and its lower class zones. This fixes the 2.2
+balancing problem, and stays as close to 2.2 behavior as possible. Also,
+the balancing algorithm works the same way on the various architectures,
+which have different numbers and types of zones. If we wanted to get
+fancy, we could assign different weights to free pages in different
+zones in the future.
+
+Note that if the size of the regular zone is huge compared to dma zone,
+it becomes less significant to consider the free dma pages while
+deciding whether to balance the regular zone. The first solution
+becomes more attractive then.
+
+The appended patch implements the second solution. It also "fixes" two
+problems: first, kswapd is woken up as in 2.2 on low memory conditions
+for non-sleepable allocations. Second, the HIGHMEM zone is also balanced,
+so as to give a fighting chance for replace_with_highmem() to get a
+HIGHMEM page, as well as to ensure that HIGHMEM allocations do not
+fall back into regular zone. This also makes sure that HIGHMEM pages
+are not leaked (for example, in situations where a HIGHMEM page is in 
+the swapcache but is not being used by anyone)
+
+kswapd also needs to know about the zones it should balance. kswapd is
+primarily needed in a situation where balancing can not be done, 
+probably because all allocation requests are coming from intr context
+and all process contexts are sleeping. For 2.3, kswapd does not really
+need to balance the highmem zone, since intr context does not request
+highmem pages. A zone aware kswapd still needs to be implemented.
+
+Page stealing from process memory and shm is done if stealing the page would
+alleviate memory pressure on any zone in the page's node that has fallen below
+its watermark.
+
+(Good) Ideas that I have heard:
+1. Dynamic experience should influence balancing: number of failed requests
+for a zone can be tracked and fed into the balancing scheme (jalvo@mbay.net)
+2. Implement a replace_with_highmem()-like replace_with_regular() to preserve
+dma pages. (lkd@tantalophile.demon.co.uk)