Manual merge

36 files changed, 1411 insertions, 814 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index fb5aa00506ecd7..a8c19aa347674e 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -82,8 +82,6 @@ device-mapper/
 	- directory with info on Device Mapper.
 devices.txt
 	- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
-digiboard.txt
-	- info on the Digiboard PC/X{i,e,eve} multiport boards.
 digiepca.txt
 	- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
 dnotify.txt
diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl
index cfce4e6de50d6e..0d1da8cbd7524d 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -195,7 +195,12 @@ qla1280_disable_intrs(struct scsi_qla_host *ha)
 	be strongly ordered coming from different CPUs.  Thus it's important
 	to properly protect parts of your driver that do memory-mapped writes
 	with locks and use the <function>mmiowb</function> to make sure they
-	arrive in the order intended.
+	arrive in the order intended.  Issuing a regular <function>readX
+	</function> will also ensure write ordering, but should only be used
+	when the driver has to be sure that the write has actually arrived
+	at the device (not that it's simply ordered with respect to other
+	writes), since a full <function>readX</function> is a relatively
+	expensive operation.
       </para>
 
       <para>
@@ -203,29 +208,50 @@ qla1280_disable_intrs(struct scsi_qla_host *ha)
 	releasing a spinlock that protects regions using <function>writeb
 	</function> or similar functions that aren't surrounded by <function>
 	readb</function> calls, which will ensure ordering and flushing.  The
-	following example (again from qla1280.c) illustrates its use.
+	following pseudocode illustrates what might occur if write ordering
+	isn't guaranteed via <function>mmiowb</function> or one of the
+	<function>readX</function> functions.
       </para>
 
 <programlisting>
-       sp->flags |= SRB_SENT;
-       ha->actthreads++;
-       WRT_REG_WORD(&amp;reg->mailbox4, ha->req_ring_index);
-
-       /*
-        * A Memory Mapped I/O Write Barrier is needed to ensure that this write
-        * of the request queue in register is ordered ahead of writes issued
-        * after this one by other CPUs.  Access to the register is protected
-        * by the host_lock.  Without the mmiowb, however, it is possible for
-        * this CPU to release the host lock, another CPU acquire the host lock,
-        * and write to the request queue in, and have the second write make it
-        * to the chip first.
-        */
-       mmiowb(); /* posted write ordering */
+CPU A:  spin_lock_irqsave(&amp;dev_lock, flags)
+CPU A:  ...
+CPU A:  writel(newval, ring_ptr);
+CPU A:  spin_unlock_irqrestore(&amp;dev_lock, flags)
+        ...
+CPU B:  spin_lock_irqsave(&amp;dev_lock, flags)
+CPU B:  writel(newval2, ring_ptr);
+CPU B:  ...
+CPU B:  spin_unlock_irqrestore(&amp;dev_lock, flags)
 </programlisting>
 
       <para>
+	In the case above, newval2 could be written to ring_ptr before
+	newval.  Fixing it is easy though:
+      </para>
+
+<programlisting>
+CPU A:  spin_lock_irqsave(&amp;dev_lock, flags)
+CPU A:  ...
+CPU A:  writel(newval, ring_ptr);
+CPU A:  mmiowb(); /* ensure no other writes beat us to the device */
+CPU A:  spin_unlock_irqrestore(&amp;dev_lock, flags)
+        ...
+CPU B:  spin_lock_irqsave(&amp;dev_lock, flags)
+CPU B:  writel(newval2, ring_ptr);
+CPU B:  ...
+CPU B:  mmiowb();
+CPU B:  spin_unlock_irqrestore(&amp;dev_lock, flags)
+</programlisting>
+
+      <para>
+	See tg3.c for a real world example of how to use <function>mmiowb
+	</function>
+      </para>
+
+      <para>
 	PCI ordering rules also guarantee that PIO read responses arrive
-	after any outstanding DMA writes on that bus, since for some devices
+	after any outstanding DMA writes from that bus, since for some devices
 	the result of a <function>readb</function> call may signal to the
 	driver that a DMA transaction is complete.  In many cases, however,
 	the driver may want to indicate that the next
@@ -234,7 +260,11 @@ qla1280_disable_intrs(struct scsi_qla_host *ha)
 	<function>readb_relaxed</function> for these cases, although only
 	some platforms will honor the relaxed semantics.  Using the relaxed
 	read functions will provide significant performance benefits on
-	platforms that support it.
+	platforms that support it.  The qla2xxx driver provides examples
+	of how to use <function>readX_relaxed</function>.  In many cases,
+	a majority of the driver's <function>readX</function> calls can
+	safely be converted to <function>readX_relaxed</function> calls, since
+	only a few will indicate or depend on DMA completion.
       </para>
     </sect1>
 
diff --git a/Documentation/DocBook/librs.tmpl b/Documentation/DocBook/librs.tmpl
index ea94ae848b218c..be482c0302034a 100644
--- a/Documentation/DocBook/librs.tmpl
+++ b/Documentation/DocBook/librs.tmpl
@@ -83,13 +83,13 @@
 		<title>Initializing</title>
 		<para>
 			The init function init_rs returns a pointer to a
-			rs decoder structure, which holds the neccecary
+			rs decoder structure, which holds the necessary
 			information for encoding, decoding and error correction
 			with the given polynomial. It either uses an existing
 			matching decoder or creates a new one. On creation all
 			the lookup tables for fast en/decoding are created.
 			The function may take a while, so make sure not to 
-			call it in critical code pathes.
+			call it in critical code paths.
 		</para>
 		<programlisting>
 /* the Reed Solomon control structure */
@@ -123,10 +123,10 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6);
 			results in ECC errors.
 		</para>
 		<para>
-			The databytes are expanded to the given symbolsize
-			on the fly. There is no support for encoding continuos
-			bitstreams with a symbolsize != 8 at the moment. If
-			it is neccecary it should be not a big deal to implement
+			The databytes are expanded to the given symbol size
+			on the fly. There is no support for encoding continuous
+			bitstreams with a symbol size != 8 at the moment. If
+			it is necessary it should be not a big deal to implement
 			such functionality.
 		</para>
 		<programlisting>
@@ -155,13 +155,13 @@ encode_rs8 (rs_decoder, data8, 512, par, 0);
 			location buffer to the decoder. The decoder stores the
 			calculated error location and the correction bitmask
 			in the given buffers. This is useful for hardware
-			decoders which use a weird bitordering scheme.
+			decoders which use a weird bit ordering scheme.
 		</para>
 		<para>
-			The databytes are expanded to the given symbolsize
-			on the fly. There is no support for decoding continuos
+			The databytes are expanded to the given symbol size
+			on the fly. There is no support for decoding continuous
 			bitstreams with a symbolsize != 8 at the moment. If
-			it is neccecary it should be not a big deal to implement
+			it is necessary it should be not a big deal to implement
 			such functionality.
 		</para>
 		
@@ -208,7 +208,7 @@ numerr = decode_rs8 (rs_decoder, data8, par, 512, syn, 0, NULL, 0, NULL);
 			Decoding with syndrome given by hardware decoder, no direct data correction.
 		</title>
 		<para>
-			Note: It's not neccecary to give data and recieved parity to the decoder.
+			Note: It's not necessary to give data and received parity to the decoder.
 		</para>
 		<programlisting>
 /* Parity buffer. Size = number of roots */
diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl
index 669b0466a7015e..34206230c7199c 100644
--- a/Documentation/DocBook/procfs-guide.tmpl
+++ b/Documentation/DocBook/procfs-guide.tmpl
@@ -100,8 +100,8 @@
     <para>
       I'd like to thank Jeff Garzik
       <email>jgarzik@pobox.com</email> and Alexander Viro
-      <email>viro@math.psu.edu</email> for their input, Tim Waugh
-      <email>twaugh@redhat.com</email> for his <ulink
+      <email>viro@parcelfarce.linux.theplanet.co.uk</email> for their input,
+      Tim Waugh <email>twaugh@redhat.com</email> for his <ulink
       url="http://people.redhat.com/twaugh/docbook/selfdocbook/">Selfdocbook</ulink>,
       and Marc Joosen <email>marcj@historia.et.tudelft.nl</email> for
       proofreading.
diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt
index 46950afda25f44..bda6ead69bd0d8 100644
--- a/Documentation/RCU/listRCU.txt
+++ b/Documentation/RCU/listRCU.txt
@@ -82,7 +82,7 @@ lock might be used as follows for deletion and insertion:
 		list_for_each_entry(e, list, list) {
 			if (!audit_compare_rule(rule, &e->rule)) {
 				list_del(&e->list);
-				call_rcu(&e->rcu, audit_free_rule, e);
+				write_unlock(&auditsc_lock);
 				return 0;
 			}
 		}
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
index 59d4bad5b43ecc..e12bc3284a272e 100644
--- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
@@ -6,7 +6,7 @@ Introduction
 ------------
 
   The S3C2410 supports a low-power suspend mode, where the SDRAM is kept
-  in Self-Refresh mode, and all but the esential peripheral blocks are
+  in Self-Refresh mode, and all but the essential peripheral blocks are
   powered down. For more information on how this works, please look
   at the S3C2410 datasheets from Samsung.
 
@@ -33,17 +33,18 @@ Resuming
   code to resume Linux operation.
 
   GSTATUS4 is currently left alone by the sleep code, and is free to
-  use for any other purposes.
+  use for any other purposes (for example, the EB2410ITX uses this to
+  save memory configuration in).
 
 
 Machine Support
 ---------------
 
   The machine specific functions must call the s3c2410_pm_init() function
-  to say that it's bootloader is capable of resuming. This can be as
-  simple as adding the following to the file:
+  to say that its bootloader is capable of resuming. This can be as
+  simple as adding the following to the machine's definition:
 
-  late_initcall(s3c2410_pm_init);
+  INITMACHINE(s3c2410_pm_init)
 
   A board can do its own setup before calling s3c2410_pm_init, if it
   needs to setup anything else for power management support.
@@ -52,6 +53,23 @@ Machine Support
   saving the resume address, if your board requires it, then contact
   the maintainer and discuss what is required.
 
+  Note, the original method of adding an late_initcall() is wrong,
+  and will end up initialising all compiled machines' pm init!
+
+
+Debugging
+---------
+
+  There are several important things to remember when using PM suspend:
+
+  1) The uart drivers will disable the clocks to the UART blocks when
+     suspending, which means that use of printascii() or similar direct
+     access to the UARTs will cause the debug to stop.
+
+  2) Whilst the pm code itself will attempt to re-enable the UART clocks,
+     care should be taken that any external clock sources that the UARTs
+     rely on are still enabled at that point.
+
 
 Configuration
 -------------
diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt
index fd763cc4892d4f..6f47332c883de7 100644
--- a/Documentation/block/as-iosched.txt
+++ b/Documentation/block/as-iosched.txt
@@ -132,7 +132,7 @@ a combination of IO behavior from all those devices.
 Tuning the anticipatory IO scheduler
 ------------------------------------
 When using 'as', the anticipatory IO scheduler there are 5 parameters under
-/sys/block/*/iosched/. All are units of milliseconds.
+/sys/block/*/queue/iosched/. All are units of milliseconds.
 
 The parameters are:
 * read_expire
diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt
index 2b131860055821..c918b3a6022dd0 100644
--- a/Documentation/block/deadline-iosched.txt
+++ b/Documentation/block/deadline-iosched.txt
@@ -9,7 +9,7 @@ Each io queue has a set of io scheduler tunables associated with it. These
 tunables control how the io scheduler works. You can find these entries
 in:
 
-/sys/block/<device>/iosched
+/sys/block/<device>/queue/iosched
 
 assuming that you have sysfs mounted on /sys. If you don't have sysfs mounted,
 you can do so by typing:
diff --git a/Documentation/computone.txt b/Documentation/computone.txt
index ea2b5d3e3df920..b1cf59b84d9727 100644
--- a/Documentation/computone.txt
+++ b/Documentation/computone.txt
@@ -1,3 +1,13 @@
+NOTE: This is an unmaintained driver.  It is not guaranteed to work due to
+changes made in the tty layer in 2.6.  If you wish to take over maintenance of
+this driver, contact Michael Warfield <mhw@wittsend.com>.
+
+Changelog:
+----------
+11-01-2001:	Original Document
+
+10-29-2004:	Minor misspelling & format fix, update status of driver.
+		James Nelson <james4765@gmail.com>
 
 Computone Intelliport II/Plus Multiport Serial Driver
 -----------------------------------------------------
@@ -146,7 +156,7 @@ selects polled mode). If no base addresses are specified the defaults in
 ip2.c are used. If you are autoloading the driver module with kerneld or
 kmod the base addresses and interrupt number must also be set in ip2.c
 and recompile or just insert and options line in /etc/modprobe.conf or both.
-The options line is equivalent to the command line and takes precidence over 
+The options line is equivalent to the command line and takes precedence over
 what is in ip2.c. 
 
 /etc/modprobe.conf sample:
@@ -166,7 +176,8 @@ The equivalent for the kernel command line (in lilo.conf):
 
 
 Note:	Both io and irq should be updated to reflect YOUR system.  An "io"
-	address of 1 or 2 indicates a PCI or EISA card in the board table.		The PCI or EISA irq will be assigned automatically.
+	address of 1 or 2 indicates a PCI or EISA card in the board table.
+	The PCI or EISA irq will be assigned automatically.
 
 Specifying an invalid or in-use irq will default the driver into
 running in polled mode for that card.  If all irq entries are 0 then
diff --git a/Documentation/cpu-freq/cpufreq-nforce2.txt b/Documentation/cpu-freq/cpufreq-nforce2.txt
new file mode 100644
index 00000000000000..9188337d8f6b8f
--- /dev/null
+++ b/Documentation/cpu-freq/cpufreq-nforce2.txt
@@ -0,0 +1,19 @@
+
+The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms.
+
+This works better than on other plattforms, because the FSB of the CPU
+can be controlled independently from the PCI/AGP clock.
+
+The module has two options:
+
+	fid: 	 multiplier * 10 (for example 8.5 = 85)
+	min_fsb: minimum FSB
+
+If not set, fid is calculated from the current CPU speed and the FSB.
+min_fsb defaults to FSB at boot time - 50 MHz.
+
+IMPORTANT: The available range is limited downwards!
+           Also the minimum available FSB can differ, for systems 
+           booting with 200 MHz, 150 should always work.
+
+
diff --git a/Documentation/crypto/api-intro.txt b/Documentation/crypto/api-intro.txt
index 62778c57f97750..fa0c8b97495056 100644
--- a/Documentation/crypto/api-intro.txt
+++ b/Documentation/crypto/api-intro.txt
@@ -231,6 +231,9 @@ Whirlpool algorithm contributors:
   Aaron Grothe
   Jean-Luc Cooke
 
+Anubis algorithm contributors:
+  Aaron Grothe
+
 Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
 
 Please send any credits updates or corrections to:
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 7576788f1a643e..f115145e58a2ae 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -2758,6 +2758,10 @@ Your cooperation is appreciated.
 		 43 = /dev/ttySMX2		Motorola i.MX - port 2
 		 44 = /dev/ttyMM0		Marvell MPSC - port 0
 		 45 = /dev/ttyMM1		Marvell MPSC - port 1
+		 46 = /dev/ttyCPM0		PPC CPM (SCC or SMC) - port 0
+		    ...
+		 49 = /dev/ttyCPM5		PPC CPM (SCC or SMC) - port 5
+
 
 205 char	Low-density serial ports (alternate device)
 		  0 = /dev/culu0		Callout device for ttyLU0
@@ -2786,6 +2790,9 @@ Your cooperation is appreciated.
 		 41 = /dev/ttySMX0		Callout device for ttySMX0
 		 42 = /dev/ttySMX1		Callout device for ttySMX1
 		 43 = /dev/ttySMX2		Callout device for ttySMX2
+		 46 = /dev/cucpm0		Callout device for ttyCPM0
+		    ...
+		 49 = /dev/cucpm5		Callout device for ttyCPM5
 
 206 char	OnStream SC-x0 tape devices
 		  0 = /dev/osst0		First OnStream SCSI tape, mode 0
diff --git a/Documentation/digiboard.txt b/Documentation/digiboard.txt
deleted file mode 100644
index 9ccd612b0175f0..00000000000000
--- a/Documentation/digiboard.txt
+++ /dev/null
@@ -1,272 +0,0 @@
-The Linux Digiboard Driver
---------------------------
-
-The Digiboard Driver for Linux supports the following boards:
-
- DigiBoard PC/Xi, PC/Xe, PC/Xeve(which is the newer, smaller Xe with
- a 8K window which is also known as PC/Xe(8K) and has no memory/irq
- switches) You can use up to 4 cards with this driver and it should work
- on other architectures than intel also.
-
-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
-linux-2.1.x and may not be usable on other architectures than intel now.
-It is available from ftp.digi.com/ftp.digiboard.com. You can write me if
-you need an patch for this driver.
-
-Bernhard Kaindl (bkaindl@netway.at)  6. April 1997.
-
-Configuring the Driver
-----------------------
-
-The driver can be built direct into the kernel or as a module.
-The pcxx driver can be configured using the command line feature while
-loading the kernel with LILO or LOADLIN or, if built as a module,
-with arguments to insmod and modprobe or with parameters in
-/etc/modprobe.conf for modprobe and kerneld.
-
-After configuring the driver you need to create the device special files
-as described in "Device file creation:" below and set the appropriate
-permissions for your application.
-
-As Module
----------
-
-modprobe pcxx io=<io> \
-  membase=<membase> \
-  memsize=<memsize> \
-  numports=<numports>  \
-  altpin=<altpin> \
-  verbose=<verbose>
-
-or, if several cards are installed
-
-modprobe pcxx io=<io-1>,<io-2>,... \
-  membase=<membase-1>,<membase-2>,... \
-  memsize=<memsize-1>,<memsize-2>,... \
-  numports=<numports-1>,<numports-2>,... \
-  altpin=<altpin-1>,<altpin-2>,... \
-  verbose=<verbose>
-
-where <io-N> is the io address of the Nth card and <membase-N> is the
-memory base address of the Nth card, etc.
-
-The parameters can be specified in any order. For example, the numports
-parameter can precede the membase parameter, or vice versa. If several
-cards are installed the ordering within the comma separated parameter
-lists must be consistent, of course.
-
-io       - I/O port address of that card.
-membase  - Memory start address of that card.
-memsize  - Memory size of that card, in kilobytes. If given, this value
-           is compared against the card to verify configuration and
-           hinder the driver from using a misconfigured card. If the parameter
-           does not match the board it is disabled with a memory size error.
-numports - Number of ports on this card. This is the number of devices to
-           assign to this card or reserve if disabled.
-altpin   - 1: swap DCD and DSR for 8-pin RJ-45 with modems.
-	   0: don't swap DCD and DSR.
-           other values count as 1.
-verbose  - 1: give nice verbose output during initialisation of the driver,
-              possibly helpful during board configuration.
-           0: normal terse output.
-
-Only the parameters which differ from the defaults need to be specified.
-If the io= parameter is not given, the default config is used. This is
-
-  io=0x200 membase=0xD0000 numports=16 altpin=0
-
-Only applicable parameters need be specified. For example to configure
-2 boards, first one at 0x200 with 8 ports, rest defaults, second one at
-0x120, memory at 0xD80000, altpin enabled, rest defaults, you can do this
-by using these parameters:
-
-  modprobe pcxx io=0x200,0x120 numports=8,8 membase=,0xD80000 altpin=,1
-
-To disable a temporary unusable board without changing the mapping of the
-devices following that board, you can empty the io-value for that board:
-
-  modprobe pcxx io=,0x120 numports=8,8 membase=,0xD80000 altpin=,1
-
-The remaining board still uses ttyD8-ttyD15 and cud8-cud15.
-
-Example line for /etc/modprobe.conf for use with kerneld and as default
-parameters for modprobe:
-
-options pcxx           io=0x200 numports=8
-
-For kmod to work you will likely need to add these two lines to your
-/etc/modprobe.conf:
-
-alias char-major-22    pcxx
-alias char-major-23    pcxx
-
-
-Boot-time configuration when linked into the kernel
----------------------------------------------------
-
-Per board to be configured, pass a digi= command-line parameter to the
-kernel using lilo or loadlin. It consists of a string of comma separated
-identifiers or integers.  The 6 values in order are:
-
-Card status:      Enable      - use that board
-		  Disable     - don't actually use that board.
-
-Card type:        PC/Xi       - the old ones with 64/128/256/512K RAM.
-		  PC/Xe       - PC/Xe(old ones with 64k mem range).
-		  PC/Xeve     - PC/Xe(new ones with 8k mem range).
-
-Note: This is for documentation only, the type is detected from the board.
-
-Altpin setting:   Enable      - swap DCD and DSR for 8-pin RJ-45 with modems.
-		  Disable     - don't swap DCD and DSR.
-
-Number of ports:  1 ... 16    - Number of ports on this card. This is the
-				number of devices to assign to this card.
-
-I/O port address: eg. 200     - I/O Port address where the card is configured.
-
-Memory base addr: eg. 80000   - Memory address where the board's memory starts.
-
-This is an example for a line which you can insert into you lilo.conf:
-
-   append="digi=Enable,PC/Xi,Disable,4,120,D0000"
-
-there is an alternate form, in which you must use decimal values only:
-
-   append="digi=1,0,0,16,512,851968"
-
-If you don't give a digi= command line, the compiled-in defaults of
-board 1: io=0x200, membase=0xd0000, altpin=off and numports=16 are used.
-
-If you have the resources (io&mem) free for use, configure your board to
-these settings and you should be set up fine even if yours has not got 16 
-ports.
-
-
-Sources of Information
-----------------------
-
-Please contact digi directly digilnux@dgii.com. Forward any information of
-general interest to me so that I can include it on the webpage.
-
-Web page: http://lameter.com/digi
-
-Christoph Lameter (christoph@lameter.com) Aug 14, 2000.
-
-Device file creation
---------------------
-
-Currently the Linux MAKEDEV command does not support generating the Digiboard
-Devices. 
-
-The /dev/cud devices behave like the /dev/cua devices
-and the ttyD devices are like the /dev/ttyS devices.
-
-Use the following script to generate the devices:
-
------------------- mkdigidev begin
-#!/bin/sh
-#
-# Script to create Digiboard Devices
-# Christoph Lameter, April 16, 1996
-#
-# Usage:
-# mkdigidev [<number of devices>]
-# 
-
-DIGI_MAJOR=23
-DIGICU_MAJOR=22
-
-BOARDS=$1
-
-if [ "$BOARDS" = "" ]; then
-BOARDS=1
-fi
-
-boardnum=0
-while [ $boardnum -lt $BOARDS ];
-do
-  for c in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;
-  do
-	name=`expr $boardnum \* 16 + $c`
-	mknod /dev/cud$name c $DIGICU_MAJOR $name
-	mknod /dev/ttyD$name c $DIGI_MAJOR $name
-  done
-  boardnum=`expr $boardnum + 1`
-done
------------------- mkdigidev end
-
-or apply the following patch to /dev/MAKEDEV and do a 
-sh /dev/MAKEDEV digi
-
------ MAKEDEV Patch
---- /dev/MAKEDEV	Sun Aug 13 15:48:23 1995
-+++ MAKEDEV	Tue Apr 16 17:53:27 1996
-@@ -120,7 +120,7 @@
- 	while [ $# -ne 0 ]
- 	do
- 		case "$1" in
--			mem|tty|ttyp|cua|cub)	;;
-+			mem|tty|ttyp|cua|cub|cud)	;;
- 			hd)	echo hda hdb hdc hdd ;;
- 			xd)	echo xda xdb ;;
- 			fd)	echo fd0 fd1 ;;
-@@ -140,6 +140,7 @@
- 			dcf)		echo dcf ;;
- 			pcmcia)	;; # taken care of by its own driver
- 			ttyC)	echo cyclades ;;
-+			ttyD)	echo digi ;;
- 			*)	echo "$0: don't know what \"$1\" is" >&2 ;;
- 		esac
- 		shift
-@@ -208,6 +209,15 @@
- 		do
- 			makedev ttyC$i c $major1 `expr 32 + $i` $tty
- 			makedev cub$i c $major2 `expr 32 + $i` $dialout
-+		done
-+		;;
-+	digi)
-+		major1=`Major ttyD` || continue
-+		major2=`Major cud` || continue
-+		for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
-+		do
-+			makedev ttyD$i c $major1 `expr 32 + $i` $tty
-+			makedev cud$i c $major2 `expr 32 + $i` $dialout
- 		done
- 		;;
- 	par[0-2])
------ End Makedev patch
-
------------------------------------------------------------------------------
-
-Changes v1.5.5:
-
-The ability to use the kernel's command line to pass in the configuration for 
-boards.  Using LILO's APPEND command, a string of comma separated identifiers 
-or integers can be used.  The 6 values in order are:
-
-   Enable/Disable this card,
-   Type of card: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
-   Enable/Disable alternate pin arrangement,
-   Number of ports on this card,
-   I/O Port where card is configured (in HEX if using string identifiers),
-   Base of memory window (in HEX if using string identifiers), 
-
-Samples:
-   append="digi=E,PC/Xi,D,16,200,D0000"
-   append="digi=1,0,0,16,512,(whatever D0000 is in base 10 :)
-
-Drivers' minor device numbers are conserved. This means that instead of
-each board getting a block of 16 minors pre-assigned, it gets however
-many it should, with the next card following directly behind it.  A
-system with 4 2-port PC/Xi boards will use minor numbers 0-7.
-This conserves some memory, and removes a few hard coded constants.
-
-NOTE!! NOTE!! NOTE!!
-The definition of PC/Xem as a valid board type is the BEGINNING of support
-for this device.  The driver does not currently recognise the board, nor
-does it want to initialize it.  At least not the EISA version.
-
-Mike McLagan <mike.mclagan@linux.org> 5, April 1996.
diff --git a/Documentation/digiepca.txt b/Documentation/digiepca.txt
index 01c4adc59fc011..88820fe38dadc1 100644
--- a/Documentation/digiepca.txt
+++ b/Documentation/digiepca.txt
@@ -1,3 +1,11 @@
+NOTE:  This driver is obsolete.  Digi provides a 2.6 driver (dgdm) at
+http://www.digi.com for PCI cards.  They no longer maintain this driver,
+and have no 2.6 driver for ISA cards.
+
+This driver requires a number of user-space tools.  They can be aquired from
+http://www.digi.com, but only works with 2.4 kernels.
+
+
 The Digi Intl. epca driver. 
 ----------------------------
 The Digi Intl. epca driver for Linux supports the following boards:
@@ -64,9 +72,6 @@ drivers/char/README.epca for more details.  Note,
 this driver REQUIRES that digiDload be executed prior to it being used. 
 Failure to do this will result in an ENODEV error.
 
-The latest version of the tool package is available at:
-ftp://ftp.dgii.com/drivers/linux/released/async/
-
 Documentation:
 --------------
 Complete documentation for this product may be found in the tool package. 
@@ -74,14 +79,8 @@ Complete documentation for this product may be found in the tool package.
 Sources of information and support:
 -----------------------------------
 Digi Intl. support site for this product:
--> digilnux@dgii.com 
 
-Related information and information concerning other drivers supporting 
-Digi Intl. products:
-
--> FTP: ftp://dgii.com
--> Webpage: http://www.dgii.com
--> Webpage: http://lameter.com/digi
+->  http://www.digi.com
 
 Acknowledgments:
 ----------------
@@ -90,3 +89,10 @@ supporting the original public domain DigiBoard driver Copyright (C)
 1994,1995 Troy De Jongh.  Many thanks to Christoph Lameter 
 (christoph@lameter.com) and Mike McLagan (mike.mclagan@linux.org) who authored 
 and contributed to the original document. 
+
+Changelog:
+----------
+10-29-04:	Update status of driver, remove dead links in document
+		James Nelson <james4765@gmail.com>
+
+2000 (?)	Original Document
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 1fd07e10c27ea8..570ef5db0a0706 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -317,8 +317,8 @@ prototypes:
 locking rules:
 	called from interrupts. In other words, extreme care is needed here.
 bh is locked, but that's all warranties we have here. Currently only RAID1,
-highmem and fs/buffer.c are providing these. Block devices call this method
-upon the IO completion.
+highmem, fs/buffer.c, and fs/ntfs/aops.c are providing these. Block devices
+call this method upon the IO completion.
 
 --------------------------- block_device_operations -----------------------
 prototypes:
diff --git a/Documentation/filesystems/devfs/ChangeLog b/Documentation/filesystems/devfs/ChangeLog
index 12583144e06d21..e5aba5246d7c93 100644
--- a/Documentation/filesystems/devfs/ChangeLog
+++ b/Documentation/filesystems/devfs/ChangeLog
@@ -1632,7 +1632,7 @@ Changes for patch v177
 - Fixed bugs in handling symlinks: could leak or cause Oops
 
 - Cleaned up directory handling by separating fops
-  Thanks to Alexander Viro <viro@math.psu.edu>
+  Thanks to Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
 ===============================================================================
 Changes for patch v178
 
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
index 23a4d98f99b870..b5cb9110cc6b9d 100644
--- a/Documentation/filesystems/ext2.txt
+++ b/Documentation/filesystems/ext2.txt
@@ -11,57 +11,53 @@ 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 (*).
+Most defaults are determined by the filesystem superblock, and can be
+set using tune2fs(8). Kernel-determined defaults are indicated by (*).
 
 bsddf			(*)	Makes `df' act like BSD.
 minixdf				Makes `df' act like Minix.
 
-barrier=1			This enables/disables barriers. barrier=0 disables it,
-				barrier=1 enables it.
-
-orlov			(*)	This enables the new Orlov block allocator. It's
-				enabled by default.
-
-oldalloc			This disables the Orlov block allocator and
-				enables the old block allocator. Orlov should
-				have better performance, we'd like to get some
-				feedback  if it's the contrary for you.
-
-user_xattr		(*)	Enables POSIX Extended Attributes. It's enabled by
-				default, however you need to confifure its support
-				(CONFIG_EXT2_FS_XATTR). This is neccesary if you want
-				to use POSIX Acces Control Lists support. You can visit
-				http://acl.bestbits.at to know more about POSIX Extended
-				attributes.
-
-nouser_xattr			Disables POSIX Extended Attributes.
-
-acl			(*)	Enables POSIX Access Control Lists support. This is
-				enabled by default, however you need to configure
-				its support (CONFIG_EXT2_FS_POSIX_ACL). If you want
-				to know more about ACLs visit http://acl.bestbits.at
-
-noacl				This option disables POSIX Access Control List support.
-
+check				Check block and inode bitmaps at mount time
+				(requires CONFIG_EXT2_CHECK).
 check=none, nocheck	(*)	Don't do extra checking of bitmaps on mount
 				(check=normal and check=strict options removed)
 
 debug				Extra debugging information is sent to the
 				kernel syslog.  Useful for developers.
 
-errors=continue		(*)	Keep going on a filesystem error.
+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.
+nogrpid, sysvgroups		New objects have the group ID of their creator.
+
+nouid32				Use 16-bit UIDs and GIDs.
+
+oldalloc			Enable the old block allocator. Orlov should
+				have better performance, we'd like to get some
+				feedback if it's the contrary for you.
+orlov			(*)	Use the Orlov block allocator.
+				(See http://lwn.net/Articles/14633/ and
+				http://lwn.net/Articles/14446/.)
 
 resuid=n			The user ID which may use the reserved blocks.
-resgid=n			The group ID which may use the reserved blocks. 
+resgid=n			The group ID which may use the reserved blocks.
 
 sb=n				Use alternate superblock at this location.
 
+user_xattr			Enable "user." POSIX Extended Attributes
+				(requires CONFIG_EXT2_FS_XATTR).
+				See also http://acl.bestbits.at
+nouser_xattr			Don't support "user." extended attributes.
+
+acl				Enable POSIX Access Control Lists support
+				(requires CONFIG_EXT2_FS_POSIX_ACL).
+				See also http://acl.bestbits.at
+noacl				Don't support POSIX ACLs.
+
+nobh				Do not attach buffer_heads to file pagecache.
+
 grpquota,noquota,quota,usrquota	Quota options are silently ignored by ext2.
 
 
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index ad2e3222747665..f89b440fad1dac 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -258,10 +258,10 @@ Then you would use ldminfo in dump mode to obtain the necessary information:
 $ ./ldminfo --dump /dev/hda
 
 This would dump the LDM database found on /dev/hda which describes all of your
-dinamic disks and all the volumes on them.  At the bottom you will see the
+dynamic disks and all the volumes on them.  At the bottom you will see the
 VOLUME DEFINITIONS section which is all you really need.  You may need to look
 further above to determine which of the disks in the volume definitions is
-which device in Linux.  Hint: Run ldminfo on each of your dinamic disks and
+which device in Linux.  Hint: Run ldminfo on each of your dynamic disks and
 look at the Disk Id close to the top of the output for each (the PRIVATE HEADER
 section).  You can then find these Disk Ids in the VBLK DATABASE section in the
 <Disk> components where you will get the LDM Name for the disk that is found in
@@ -432,6 +432,9 @@ ChangeLog
 
 Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
 
+2.1.22:
+	- Improve handling of ntfs volumes with errors.
+	- Fix various bugs and race conditions.
 2.1.21:
 	- Fix several race conditions and various other bugs.
 	- Many internal cleanups, code reorganization, optimizations, and mft
diff --git a/Documentation/filesystems/ufs.txt b/Documentation/filesystems/ufs.txt
index bdedb9fff4daf2..2b5a56a6a5588c 100644
--- a/Documentation/filesystems/ufs.txt
+++ b/Documentation/filesystems/ufs.txt
@@ -15,13 +15,15 @@ ufstype=type_of_ufs
 	ufs manually by mount option ufstype. Possible values are:
 
 	old	old format of ufs
-		default value, supported os read-only
+		default value, supported as read-only
 
 	44bsd	used in FreeBSD, NetBSD, OpenBSD
-		supported os read-write
+		supported as read-write
+
+	ufs2    used in FreeBSD 5.x
+		supported as read-only
 
-       ufs2    used in FreeBSD 5.x
-               supported os read-only
+	5xbsd	synonym for ufs2
 
 	sun	used in SunOS (Solaris)
 		supported as read-write
@@ -29,6 +31,9 @@ ufstype=type_of_ufs
 	sunx86	used in SunOS for Intel (Solarisx86)
 		supported as read-write
 
+	hp	used in HP-UX
+		supported as read-only
+
 	nextstep
 		used in NextStep
 		supported as read-only
@@ -46,7 +51,7 @@ POSSIBLE PROBLEMS
 =================
 
 There is still bug in reallocation of fragment, in file fs/ufs/balloc.c, 
-line 364. But it seem working on current buffer cache configuration.
+line 364. But it seems working on current buffer cache configuration.
 
 
 BUG REPORTS
diff --git a/Documentation/floppy.txt b/Documentation/floppy.txt
index 99d3ad3b3aa1a6..6fb10fcd82fb12 100644
--- a/Documentation/floppy.txt
+++ b/Documentation/floppy.txt
@@ -13,15 +13,20 @@ LILO configuration options (Thinkpad users, read this)
  The floppy driver is configured using the 'floppy=' option in
 lilo. This option can be typed at the boot prompt, or entered in the
 lilo configuration file.
- Example: If your kernel is called linux-2.2.13, type the following line
+
+ Example: If your kernel is called linux-2.6.9, type the following line
 at the lilo boot prompt (if you have a thinkpad):
- linux-2.2.13 floppy=thinkpad
+
+ linux-2.6.9 floppy=thinkpad
+
 You may also enter the following line in /etc/lilo.conf, in the description
-of linux-2.2.13:
+of linux-2.6.9:
+
  append = "floppy=thinkpad"
 
  Several floppy related options may be given, example:
- linux-2.2.13 floppy=daring floppy=two_fdc
+
+ linux-2.6.9 floppy=daring floppy=two_fdc
  append = "floppy=daring floppy=two_fdc"
 
  If you give options both in the lilo config file and on the boot
@@ -29,17 +34,25 @@ prompt, the option strings of both places are concatenated, the boot
 prompt options coming last. That's why there are also options to
 restore the default behavior.
 
+
+Module configuration options
+============================
+
  If you use the floppy driver as a module, use the following syntax:
- insmod floppy <options>
+modprobe floppy <options>
 
 Example:
- insmod floppy daring two_fdc
+ modprobe floppy omnibook messages
+
+ If you need certain options enabled every time you load the floppy driver,
+you can put:
+
+ options floppy omnibook messages
+
+in /etc/modprobe.conf.
 
- Some versions of insmod are buggy in one way or another. If you have
-any problems (options not being passed correctly, segfaults during
-insmod), first check whether there is a more recent version.
 
- The floppy related options include:
+ The floppy driver related options are:
 
  floppy=asus_pci
 	Sets the bit mask to allow only units 0 and 1. (default)
@@ -99,7 +112,7 @@ insmod), first check whether there is a more recent version.
 	master arbitration error" messages from your Ethernet card (or
 	from other devices) while accessing the floppy.
 
- floppy=fifo
+ floppy=usefifo
 	Enables the FIFO. (default)
 
  floppy=<threshold>,fifo_depth
@@ -110,6 +123,7 @@ insmod), first check whether there is a more recent version.
 	lower, the interrupt latency should be lower too (faster
 	processor). The benefit of a lower threshold is less
 	interrupts.
+
 	To tune the fifo threshold, switch on over/underrun messages
 	using 'floppycontrol --messages'. Then access a floppy
 	disk. If you get a huge amount of "Over/Underrun - retrying"
@@ -120,6 +134,7 @@ insmod), first check whether there is a more recent version.
 	fifo values without rebooting the machine for each test. Note
 	that you need to do 'floppycontrol --messages' every time you
 	re-insert the module.
+
 	Usually, tuning the fifo threshold should not be needed, as
 	the default (0xa) is reasonable.
 
@@ -128,6 +143,7 @@ insmod), first check whether there is a more recent version.
 	you have more than two floppy drives (only two can be
 	described in the physical CMOS), or if your BIOS uses
 	non-standard CMOS types. The CMOS types are:
+
 		0 - Use the value of the physical CMOS
 		1 - 5 1/4 DD
 		2 - 5 1/4 HD
@@ -136,6 +152,7 @@ insmod), first check whether there is a more recent version.
 		5 - 3 1/2 ED
 		6 - 3 1/2 ED
 	       16 - unknown or not installed
+
 	(Note: there are two valid types for ED drives. This is because 5 was
 	initially chosen to represent floppy *tapes*, and 6 for ED drives.
 	AMI ignored this, and used 5 for ED drives. That's why the floppy
@@ -188,7 +205,6 @@ insmod), first check whether there is a more recent version.
 	   in some more extreme cases."
 
 
-
 Supporting utilities and additional documentation:
 ==================================================
 
@@ -219,3 +235,11 @@ sure to mention also the type of the filesystem in the subject line.
  Be sure to read the FAQ before mailing/posting any bug reports!
 
  Alain
+
+Changelog
+=========
+
+10-30-2004 :	Cleanup, updating, add reference to module configuration.
+		James Nelson <james4765@gmail.com>
+
+6-3-2000 :	Original Document
diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index 20be482b6ec565..bb58c36b5845c9 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -67,72 +67,3 @@ Driver details:
 
 	Special thanks to Matt Sottek.  I did the "guts", he
 	did the "brains" and all the testing.
-
-Change history:
-
-	Version 1.0.0:
-	* Merge Intel, AMD, VIA RNG drivers into one.
-	  Further changelog in BitKeeper.
-
-	Version 0.9.8:
-	* Support other i8xx chipsets by adding 82801E detection
-	* 82801DB detection is the same as for 82801CA.
-
-	Version 0.9.7:
-	* Support other i8xx chipsets too (by adding 82801BA(M) and
-	  82801CA(M) detection)
-
-	Version 0.9.6:
-	* Internal driver cleanups, prep for 1.0.0 release.
-
-	Version 0.9.5:
-	* Rip out entropy injection via timer.  It never ever worked,
-	  and a better solution (rngd) is now available.
-
-	Version 0.9.4:
-	* Fix: Remove request_mem_region
-	* Fix: Horrible bugs in FIPS calculation and test execution
-
-	Version 0.9.3:
-	* Clean up rng_read a bit.
-	* Update i810_rng driver Web site URL.
-	* Increase default timer interval to 4 samples per second.
-	* Abort if mem region is not available.
-	* BSS zero-initialization cleanup.
-	* Call misc_register() from rng_init_one.
-	* Fix O_NONBLOCK to occur before we schedule.
-
-	Version 0.9.2:
-	* Simplify open blocking logic
-
-	Version 0.9.1:
-	* Support i815 chipsets too (Matt Sottek)
-	* Fix reference counting when statically compiled (prumpf)
-	* Rewrite rng_dev_read (prumpf)
-	* Make module races less likely (prumpf)
-	* Small miscellaneous bug fixes (prumpf)
-	* Use pci table for PCI id list
-
-	Version 0.9.0:
-	* Don't register a pci_driver, because we are really
-	  using PCI bridge vendor/device ids, and someone
-	  may want to register a driver for the bridge. (bug fix)
-	* Don't let the usage count go negative (bug fix)
-	* Clean up spinlocks (bug fix)
-	* Enable PCI device, if necessary (bug fix)
-	* iounmap on module unload (bug fix)
-	* If RNG chrdev is already in use when open(2) is called,
-	  sleep until it is available.
-	* Remove redundant globals rng_allocated, rng_use_count
-	* Convert numeric globals to unsigned
-	* Module unload cleanup
-
-	Version 0.6.2:
-	* Clean up spinlocks.  Since we don't have any interrupts
-	  to worry about, but we do have a timer to worry about,
-	  we use spin_lock_bh everywhere except the timer function
-	  itself.
-	* Fix module load/unload.
-	* Fix timer function and h/w enable/disable logic
-	* New timer interval sysctl
-	* Clean up sysctl names
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 4fe882cb401eeb..09d6cda2a1fb6e 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -3,7 +3,7 @@ possible to access all devices on an adapter from userspace, through
 the /dev interface. You need to load module i2c-dev for this.
 
 Each registered i2c adapter gets a number, counting from 0. You can
-examine /proc/bus/i2c to see what number corresponds to which adapter.
+examine /sys/class/i2c-dev/ to see what number corresponds to which adapter.
 I2C device files are character device files with major device number 89
 and a minor device number corresponding to the number assigned as 
 explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
@@ -19,7 +19,7 @@ Yes, I know, you should never include kernel header files, but until glibc
 knows about i2c, there is not much choice.
 
 Now, you have to decide which adapter you want to access. You should
-inspect /proc/bus/i2c to decide this. Adapter numbers are assigned
+inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
 somewhat dynamically, so you can not even assume /dev/i2c-0 is the
 first adapter.
 
diff --git a/Documentation/ibm-acpi.txt b/Documentation/ibm-acpi.txt
new file mode 100644
index 00000000000000..c437b1aeff5505
--- /dev/null
+++ b/Documentation/ibm-acpi.txt
@@ -0,0 +1,474 @@
+		    IBM ThinkPad ACPI Extras Driver
+
+                            Version 0.8
+                          8 November 2004
+
+               Borislav Deianov <borislav@users.sf.net>
+		      http://ibm-acpi.sf.net/
+
+
+This is a Linux ACPI driver for the IBM ThinkPad laptops. It aims to
+support various features of these laptops which are accessible through
+the ACPI framework but not otherwise supported by the generic Linux
+ACPI drivers.
+
+
+Status
+------
+
+The features currently supported are the following (see below for
+detailed description):
+
+	- Fn key combinations
+	- Bluetooth enable and disable
+	- video output switching, expansion control	
+	- ThinkLight on and off
+	- limited docking and undocking
+	- UltraBay eject
+	- Experimental: CMOS control
+	- Experimental: LED control
+	- Experimental: ACPI sounds
+
+A compatibility table by model and feature is maintained on the web
+site, http://ibm-acpi.sf.net/. I appreciate any success or failure
+reports, especially if they add to or correct the compatibility table.
+Please include the following information in your report:
+
+	- ThinkPad model name
+	- a copy of your DSDT, from /proc/acpi/dsdt
+	- which driver features work and which don't
+	- the observed behavior of non-working features
+
+Any other comments or patches are also more than welcome.
+
+
+Installation
+------------
+
+If you are compiling this driver as included in the Linux kernel
+sources, simply enable the CONFIG_ACPI_IBM option (Power Management /
+ACPI / IBM ThinkPad Laptop Extras). The rest of this section describes
+how to install this driver when downloaded from the web site.
+
+First, you need to get a kernel with ACPI support up and running.
+Please refer to http://acpi.sourceforge.net/ for help with this
+step. How successful you will be depends a lot on you ThinkPad model,
+the kernel you are using and any additional patches applied. The
+kernel provided with your distribution may not be good enough. I
+needed to compile a 2.6.7 kernel with the 20040715 ACPI patch to get
+ACPI working reliably on my ThinkPad X40. Old ThinkPad models may not
+be supported at all.
+
+Assuming you have the basic ACPI support working (e.g. you can see the
+/proc/acpi directory), follow the following steps to install this
+driver:
+
+	- unpack the archive:
+
+		tar xzvf ibm-acpi-x.y.tar.gz; cd ibm-acpi-x.y
+
+	- compile the driver:
+
+		make
+
+	- install the module in your kernel modules directory:
+
+		make install
+
+	- load the module:
+
+		modprobe ibm_acpi
+
+After loading the module, check the "dmesg" output for any error messages.
+
+
+Features
+--------
+
+The driver creates the /proc/acpi/ibm directory. There is a file under
+that directory for each feature described below. Note that while the
+driver is still in the alpha stage, the exact proc file format and
+commands supported by the various features is guaranteed to change
+frequently.
+
+Driver Version -- /proc/acpi/ibm/driver
+--------------------------------------
+
+The driver name and version. No commands can be written to this file.
+
+Hot Keys -- /proc/acpi/ibm/hotkey
+---------------------------------
+
+Without this driver, only the Fn-F4 key (sleep button) generates an
+ACPI event. With the driver loaded, the hotkey feature enabled and the
+mask set (see below), the various hot keys generate ACPI events in the
+following format:
+
+	ibm/hotkey HKEY 00000080 0000xxxx
+
+The last four digits vary depending on the key combination pressed.
+All labeled Fn-Fx key combinations generate distinct events. In
+addition, the lid microswitch and some docking station buttons may
+also generate such events.
+
+The following commands can be written to this file:
+
+	echo enable > /proc/acpi/ibm/hotkey -- enable the hot keys feature
+	echo disable > /proc/acpi/ibm/hotkey -- disable the hot keys feature
+	echo 0xffff > /proc/acpi/ibm/hotkey -- enable all possible hot keys
+	echo 0x0000 > /proc/acpi/ibm/hotkey -- disable all possible hot keys
+	... any other 4-hex-digit mask ...
+	echo reset > /proc/acpi/ibm/hotkey -- restore the original mask
+
+The bit mask allows some control over which hot keys generate ACPI
+events. Not all bits in the mask can be modified. Not all bits that
+can be modified do anything. Not all hot keys can be individually
+controlled by the mask. Most recent ThinkPad models honor the
+following bits (assuming the hot keys feature has been enabled):
+
+	key	bit	behavior when set	behavior when unset
+
+	Fn-F3			always generates ACPI event
+	Fn-F4			always generates ACPI event
+	Fn-F5	0010	generate ACPI event	enable/disable Bluetooth
+	Fn-F7	0040	generate ACPI event	switch LCD and external display
+	Fn-F8	0080	generate ACPI event	expand screen or none
+	Fn-F9	0100	generate ACPI event	none
+	Fn-F12			always generates ACPI event
+
+Some models do not support all of the above. For example, the T30 does
+not support Fn-F5 and Fn-F9. Other models do not support the mask at
+all. On those models, hot keys cannot be controlled individually.
+
+Note that enabling ACPI events for some keys prevents their default
+behavior. For example, if events for Fn-F5 are enabled, that key will
+no longer enable/disable Bluetooth by itself. This can still be done
+from an acpid handler for the ibm/hotkey event.
+
+Note also that not all Fn key combinations are supported through
+ACPI. For example, on the X40, the brightness, volume and "Access IBM"
+buttons do not generate ACPI events even with this driver. They *can*
+be used through the "ThinkPad Buttons" utility, see
+http://www.nongnu.org/tpb/
+
+Bluetooth -- /proc/acpi/ibm/bluetooth
+-------------------------------------
+
+This feature shows the presence and current state of a Bluetooth
+device. If Bluetooth is installed, the following commands can be used:
+
+	echo enable > /proc/acpi/ibm/bluetooth
+	echo disable > /proc/acpi/ibm/bluetooth
+
+Video output control -- /proc/acpi/ibm/video
+--------------------------------------------
+
+This feature allows control over the devices used for video output -
+LCD, CRT or DVI (if available). The following commands are available:
+
+	echo lcd_enable > /proc/acpi/ibm/video
+	echo lcd_disable > /proc/acpi/ibm/video
+	echo crt_enable > /proc/acpi/ibm/video
+	echo crt_disable > /proc/acpi/ibm/video
+	echo dvi_enable > /proc/acpi/ibm/video
+	echo dvi_disable > /proc/acpi/ibm/video
+	echo auto_enable > /proc/acpi/ibm/video
+	echo auto_disable > /proc/acpi/ibm/video
+	echo expand_toggle > /proc/acpi/ibm/video
+	echo video_switch > /proc/acpi/ibm/video
+
+Each video output device can be enabled or disabled individually.
+Reading /proc/acpi/ibm/video shows the status of each device.
+
+Automatic video switching can be enabled or disabled.  When automatic
+video switching is enabled, certain events (e.g. opening the lid,
+docking or undocking) cause the video output device to change
+automatically. While this can be useful, it also causes flickering
+and, on the X40, video corruption. By disabling automatic switching,
+the flickering or video corruption can be avoided.
+
+The video_switch command cycles through the available video outputs
+(it sumulates the behavior of Fn-F7).
+
+Video expansion can be toggled through this feature. This controls
+whether the display is expanded to fill the entire LCD screen when a
+mode with less than full resolution is used. Note that the current
+video expansion status cannot be determined through this feature.
+
+Note that on many models (particularly those using Radeon graphics
+chips) the X driver configures the video card in a way which prevents
+Fn-F7 from working. This also disables the video output switching
+features of this driver, as it uses the same ACPI methods as
+Fn-F7. Video switching on the console should still work.
+
+ThinkLight control -- /proc/acpi/ibm/light
+------------------------------------------
+
+The current status of the ThinkLight can be found in this file. A few
+models which do not make the status available will show it as
+"unknown". The available commands are:
+
+	echo on  > /proc/acpi/ibm/light
+	echo off > /proc/acpi/ibm/light
+
+Docking / Undocking -- /proc/acpi/ibm/dock
+------------------------------------------
+
+Docking and undocking (e.g. with the X4 UltraBase) requires some
+actions to be taken by the operating system to safely make or break
+the electrical connections with the dock.
+
+The docking feature of this driver generates the following ACPI events:
+
+	ibm/dock GDCK 00000003 00000001 -- eject request
+	ibm/dock GDCK 00000003 00000002 -- undocked
+	ibm/dock GDCK 00000000 00000003 -- docked
+
+NOTE: These events will only be generated if the laptop was docked
+when originally booted. This is due to the current lack of support for
+hot plugging of devices in the Linux ACPI framework. If the laptop was
+booted while not in the dock, the following message is shown in the
+logs: "ibm_acpi: dock device not present". No dock-related events are
+generated but the dock and undock commands described below still
+work. They can be executed manually or triggered by Fn key
+combinations (see the example acpid configuration files included in
+the driver tarball package available on the web site).
+
+When the eject request button on the dock is pressed, the first event
+above is generated. The handler for this event should issue the
+following command:
+
+	echo undock > /proc/acpi/ibm/dock
+
+After the LED on the dock goes off, it is safe to eject the laptop.
+Note: if you pressed this key by mistake, go ahead and eject the
+laptop, then dock it back in. Otherwise, the dock may not function as
+expected.
+
+When the laptop is docked, the third event above is generated. The
+handler for this event should issue the following command to fully
+enable the dock:
+
+	echo dock > /proc/acpi/ibm/dock
+
+The contents of the /proc/acpi/ibm/dock file shows the current status
+of the dock, as provided by the ACPI framework.
+
+The docking support in this driver does not take care of enabling or
+disabling any other devices you may have attached to the dock. For
+example, a CD drive plugged into the UltraBase needs to be disabled or
+enabled separately. See the provided example acpid configuration files
+for how this can be accomplished.
+
+There is no support yet for PCI devices that may be attached to a
+docking station, e.g. in the ThinkPad Dock II. The driver currently
+does not recognize, enable or disable such devices. This means that
+the only docking stations currently supported are the X-series
+UltraBase docks and "dumb" port replicators like the Mini Dock (the
+latter don't need any ACPI support, actually).
+
+UltraBay Eject -- /proc/acpi/ibm/bay
+------------------------------------
+
+Inserting or ejecting an UltraBay device requires some actions to be
+taken by the operating system to safely make or break the electrical
+connections with the device.
+
+This feature generates the following ACPI events:
+
+	ibm/bay MSTR 00000003 00000000 -- eject request
+	ibm/bay MSTR 00000001 00000000 -- eject lever inserted
+
+NOTE: These events will only be generated if the UltraBay was present
+when the laptop was originally booted (on the X series, the UltraBay
+is in the dock, so it may not be present if the laptop was undocked).
+This is due to the current lack of support for hot plugging of devices
+in the Linux ACPI framework. If the laptop was booted without the
+UltraBay, the following message is shown in the logs: "ibm_acpi: bay
+device not present". No bay-related events are generated but the eject
+command described below still works. It can be executed manually or
+triggered by a hot key combination.
+
+Sliding the eject lever generates the first event shown above. The
+handler for this event should take whatever actions are necessary to
+shut down the device in the UltraBay (e.g. call idectl), then issue
+the following command:
+
+	echo eject > /proc/acpi/ibm/bay
+
+After the LED on the UltraBay goes off, it is safe to pull out the
+device.
+
+When the eject lever is inserted, the second event above is
+generated. The handler for this event should take whatever actions are
+necessary to enable the UltraBay device (e.g. call idectl).
+
+The contents of the /proc/acpi/ibm/bay file shows the current status
+of the UltraBay, as provided by the ACPI framework.
+
+Experimental Features
+---------------------
+
+The following features are marked experimental because using them
+involves guessing the correct values of some parameters. Guessing
+incorrectly may have undesirable effects like crashing your
+ThinkPad. USE THESE WITH CAUTION! To activate them, you'll need to
+supply the experimental=1 parameter when loading the module.
+
+Experimental: CMOS control - /proc/acpi/ibm/cmos
+------------------------------------------------
+
+This feature is used internally by the ACPI firmware to control the
+ThinkLight on most newer ThinkPad models. It appears that it can also
+control LCD brightness, sounds volume and more, but only on some
+models.
+
+The commands are non-negative integer numbers:
+
+	echo 0 >/proc/acpi/ibm/cmos
+	echo 1 >/proc/acpi/ibm/cmos
+	echo 2 >/proc/acpi/ibm/cmos
+	...
+
+The range of numbers which are used internally by various models is 0
+to 21, but it's possible that numbers outside this range have
+interesting behavior. Here is the behavior on the X40 (tpb is the
+ThinkPad Buttons utility):
+
+	0 - no effect but tpb reports "Volume down"
+	1 - no effect but tpb reports "Volume up"
+	2 - no effect but tpb reports "Mute on"
+	3 - simulate pressing the "Access IBM" button
+	4 - LCD brightness up
+	5 - LCD brightness down
+	11 - toggle screen expansion
+	12 - ThinkLight on
+	13 - ThinkLight off
+	14 - no effect but tpb reports ThinkLight status change
+
+If you try this feature, please send me a report similar to the
+above. On models which allow control of LCD brightness or sound
+volume, I'd like to provide this functionality in an user-friendly
+way, but first I need a way to identify the models which this is
+possible.
+
+Experimental: LED control - /proc/acpi/ibm/LED
+----------------------------------------------
+
+Some of the LED indicators can be controlled through this feature. The
+available commands are:
+
+	echo <led number> on >/proc/acpi/ibm/led
+	echo <led number> off >/proc/acpi/ibm/led
+	echo <led number> blink >/proc/acpi/ibm/led
+
+The <led number> parameter is a non-negative integer. The range of LED
+numbers used internally by various models is 0 to 7 but it's possible
+that numbers outside this range are also valid. Here is the mapping on
+the X40:
+
+	0 - power
+	1 - battery (orange)
+	2 - battery (green)
+	3 - UltraBase
+	4 - UltraBay
+	7 - standby
+
+All of the above can be turned on and off and can be made to blink.
+
+If you try this feature, please send me a report similar to the
+above. I'd like to provide this functionality in an user-friendly way,
+but first I need to identify the which numbers correspond to which
+LEDs on various models.
+
+Experimental: ACPI sounds - /proc/acpi/ibm/beep
+-----------------------------------------------
+
+The BEEP method is used internally by the ACPI firmware to provide
+audible alerts in various situtation. This feature allows the same
+sounds to be triggered manually.
+
+The commands are non-negative integer numbers:
+
+	echo 0 >/proc/acpi/ibm/beep
+	echo 1 >/proc/acpi/ibm/beep
+	echo 2 >/proc/acpi/ibm/beep
+	...
+
+The range of numbers which are used internally by various models is 0
+to 17, but it's possible that numbers outside this range are also
+valid. Here is the behavior on the X40:
+
+	2 - two beeps, pause, third beep
+	3 - single beep
+	4 - "unable"	
+	5 - single beep
+	6 - "AC/DC"
+	7 - high-pitched beep
+	9 - three short beeps
+	10 - very long beep
+	12 - low-pitched beep
+
+(I've only been able to identify a couple of them).
+
+If you try this feature, please send me a report similar to the
+above. I'd like to provide this functionality in an user-friendly way,
+but first I need to identify the which numbers correspond to which
+sounds on various models.
+
+
+Multiple Command, Module Parameters
+-----------------------------------
+
+Multiple commands can be written to the proc files in one shot by
+separating them with commas, for example:
+
+	echo enable,0xffff > /proc/acpi/ibm/hotkey
+	echo lcd_disable,crt_enable > /proc/acpi/ibm/video
+
+Commands can also be specified when loading the ibm_acpi module, for
+example:
+
+	modprobe ibm_acpi hotkey=enable,0xffff video=auto_disable
+
+
+Example Configuration
+---------------------
+
+The ACPI support in the kernel is intended to be used in conjunction
+with a user-space daemon, acpid. The configuration files for this
+daemon control what actions are taken in response to various ACPI
+events. An example set of configuration files are included in the
+config/ directory of the tarball package available on the web
+site. Note that these are provided for illustration purposes only and
+may need to be adapted to your particular setup.
+
+The following utility scripts are used by the example action
+scripts (included with ibm-acpi for completeness):
+
+	/usr/local/sbin/idectl -- from the hdparm source distribution,
+		see http://www.ibiblio.org/pub/Linux/system/hardware
+	/usr/local/sbin/laptop_mode -- from the Linux kernel source
+		distribution, see Documentation/laptop-mode.txt
+	/sbin/service -- comes with Redhat/Fedora distributions
+
+Toan T Nguyen <ntt@control.uchicago.edu> has written a SuSE powersave
+script for the X20, included in config/usr/sbin/ibm_hotkeys_X20
+
+Henrik Brix Andersen <brix@gentoo.org> has written a Gentoo ACPI event
+handler script for the X31. You can get the latest version from
+http://dev.gentoo.org/~brix/files/x31.sh
+
+David Schweikert <dws@ee.eth.ch> has written an alternative blank.sh
+script which works on Debian systems, included in
+configs/etc/acpi/actions/blank-debian.sh
+
+
+TODO
+----
+
+I'd like to implement the following features but haven't yet found the
+time and/or I don't yet know how to implement them:
+
+- UltraBay floppy drive support
+
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index c565581d296767..2616a58a5a4b82 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -6,7 +6,7 @@ This document describes the Linux kernel Makefiles.
 
 	=== 1 Overview
 	=== 2 Who does what
-	=== 3 The kbuild Makefiles
+	=== 3 The kbuild files
 	   --- 3.1 Goal definitions
 	   --- 3.2 Built-in object goals - obj-y
 	   --- 3.3 Loadable module goals - obj-m
@@ -101,11 +101,14 @@ These people need to know about all aspects of the kernel Makefiles.
 This document is aimed towards normal developers and arch developers.
 
 
-=== 3 The kbuild Makefiles
+=== 3 The kbuild files
 
 Most Makefiles within the kernel are kbuild Makefiles that use the
 kbuild infrastructure. This chapter introduce the syntax used in the
 kbuild makefiles.
+The preferred name for the kbuild files is 'Kbuild' but 'Makefile' will
+continue to be supported. All new developmen is expected to use the
+Kbuild filename.
 
 Section 3.1 "Goal definitions" is a quick intro, further chapters provide
 more details, with real examples.
@@ -707,15 +710,17 @@ When kbuild executes the following steps are followed (roughly):
 	probe supported options:
 
 		#arch/i386/Makefile
-		check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc \
-		            /dev/null\ > /dev/null 2>&1; then echo "$(1)"; \
-		            else echo "$(2)"; fi)
-		cflags-$(CONFIG_MCYRIXIII) += $(call check_gcc,\
-		                                     -march=c3,-march=i486)
 
-		CFLAGS += $(cflags-y)
+		...
+		cflags-$(CONFIG_MPENTIUMII)     += $(call cc-option,\
+						-march=pentium2,-march=i686)
+		...
+		# Disable unit-at-a-time mode ...
+		CFLAGS += $(call cc-option,-fno-unit-at-a-time)
+		...
+
 
-	The above examples both utilise the trick that a config option expands
+	The first examples utilises the trick that a config option expands
 	to 'y' when selected.
 
     CFLAGS_KERNEL	$(CC) options specific for built-in
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2866c97708b2f3..b1d175e3a8e196 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -404,7 +404,8 @@ running once the system is up.
 
 	elevator=	[IOSCHED]
 			Format: {"as"|"cfq"|"deadline"|"noop"}
-			See Documentation/as-iosched.txt for details
+			See Documentation/block/as-iosched.txt
+			and Documentation/block/deadline-iosched.txt for details.
 
 	es1370=		[HW,OSS]
 			Format: <lineout>[,<micbias>]
@@ -505,10 +506,12 @@ running once the system is up.
 	icn=		[HW,ISDN]
 			Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
+	ide=		[HW] (E)IDE subsystem
+			Format: ide=nodma or ide=doubler or ide=reverse
+			See Documentation/ide.txt.
+
 	ide?=		[HW] (E)IDE subsystem
-			Config (iomem/irq), tuning or debugging
-			(serialize,reset,no{dma,tune,probe}) or chipset
-			specific parameters.
+			Format: ide?=noprobe or chipset specific parameters.
 			See Documentation/ide.txt.
 	
 	idebus=		[HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -703,7 +706,7 @@ running once the system is up.
 			[KNL,ACPI] Mark specific memory as reserved.
 			Region of memory to be used, from ss to ss+nn.
 
-	meye=		[HW] Set MotionEye Camera parameters
+	meye.*=		[HW] Set MotionEye Camera parameters
 			See Documentation/video4linux/meye.txt.
 
 	mga=		[HW,DRM]
@@ -875,6 +878,16 @@ running once the system is up.
 					order they are specified on the command
 					line, starting with parport0.
 
+	parport_init_mode=
+			[HW,PPT]	Configure VIA parallel port to
+					operate in specific mode. This is
+					necessary on Pegasos computer where
+					firmware has no options for setting up
+					parallel port mode and sets it to
+					spp. Currently this function knows
+					686a and 8231 chips.
+			Format: [spp|ps2|epp|ecp|ecpepp]
+
 	pas2=		[HW,OSS]
 			Format: <io>,<irq>,<dma>,<dma16>,<sb_io>,<sb_irq>,<sb_dma>,<sb_dma16>
  
@@ -930,6 +943,10 @@ running once the system is up.
 					enabled.
 		noacpi			[IA-32] Do not use ACPI for IRQ routing
 					or for PCI scanning.
+		routeirq		Do IRQ routing for all PCI devices.
+					This is normally done in pci_enable_device(),
+					so this option is a temporary workaround
+					for broken drivers that don't call it.
 
 		firmware		[ARM] Do not re-enumerate the bus but
 					instead just use the configuration
@@ -983,6 +1000,11 @@ running once the system is up.
 			(param: profile step/bucket size as a power of 2 for
 				statistical time based profiling)
 
+	processor.c2=	[HW, ACPI]
+	processor.c3=	[HW, ACPI]
+			0 - disable C2 or C3 idle power saving state.
+			1 - enable C2 or C3 (default unless DMI blacklist entry)
+
 	prompt_ramdisk=	[RAM] List of RAM disks to prompt for floppy disk
 			before loading.
 			See Documentation/ramdisk.txt.
@@ -1024,10 +1046,6 @@ running once the system is up.
 			New name for the ramdisk parameter.
 			See Documentation/ramdisk.txt.
 
-	ramdisk_start=	[RAM] Starting block of RAM disk image (so you can
-			place it after the kernel image on a boot floppy).
-			See Documentation/ramdisk.txt.
-
 	reboot=		[BUGS=IA-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
 			Format: <reboot_mode>[,<reboot_mode2>[,...]]
 			See arch/*/kernel/reboot.c.
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 3fb3b1ef18fb9c..e2b536992a2798 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -45,7 +45,8 @@ Boot time autodetection of RAID arrays
 When md is compiled into the kernel (not as module), partitions of
 type 0xfd are scanned and automatically assembled into RAID arrays.
 This autodetection may be suppressed with the kernel parameter
-"raid=noautodetect".
+"raid=noautodetect".  As of kernel 2.6.9, only drives with a type 0
+superblock can be autodetected and run at boot time.
 
 The kernel parameter "raid=partitionable" (or "raid=part") means
 that all auto-detected arrays are assembled as partitionable.
@@ -55,13 +56,13 @@ Superblock formats
 ------------------
 
 The md driver can support a variety of different superblock formats.
-(It doesn't yet, but it can)
+Currently, it supports superblock formats "0.90.0" and the "md-1" format
+introduced in the 2.5 development series.
 
-The kernel does *NOT* autodetect which format superblock is being
-used. It must be told.
+The kernel will autodetect which format superblock is being used.
 
 Superblock format '0' is treated differently to others for legacy
-reasons.
+reasons - it is the original superblock format.
 
 
 General Rules - apply for all superblock formats
@@ -69,6 +70,7 @@ General Rules - apply for all superblock formats
 
 An array is 'created' by writing appropriate superblocks to all
 devices.
+
 It is 'assembled' by associating each of these devices with an
 particular md virtual device.  Once it is completely assembled, it can
 be accessed.
@@ -76,10 +78,10 @@ be accessed.
 An array should be created by a user-space tool.  This will write
 superblocks to all devices.  It will usually mark the array as
 'unclean', or with some devices missing so that the kernel md driver
-can create approrpriate redundancy (copying in raid1, parity
+can create appropriate redundancy (copying in raid1, parity
 calculation in raid4/5).
 
-When an array is assembled, it is first initialised with the
+When an array is assembled, it is first initialized with the
 SET_ARRAY_INFO ioctl.  This contains, in particular, a major and minor
 version number.  The major version number selects which superblock
 format is to be used.  The minor number might be used to tune handling
@@ -101,15 +103,16 @@ array using HOT_REMOVE_DISK.
 
 
 Specific Rules that apply to format-0 super block arrays, and
-       arrays with no superblock (non-persistant).
+       arrays with no superblock (non-persistent).
 -------------------------------------------------------------
 
 An array can be 'created' by describing the array (level, chunksize
 etc) in a SET_ARRAY_INFO ioctl.  This must has major_version==0 and
 raid_disks != 0.
-Then uninitialised devices can be added with ADD_NEW_DISK.  The
+
+Then uninitialized devices can be added with ADD_NEW_DISK.  The
 structure passed to ADD_NEW_DISK must specify the state of the device
 and it's role in the array.
 
-One started with RUN_ARRAY, uninitialised spares can be added with
+Once started with RUN_ARRAY, uninitialized spares can be added with
 HOT_ADD_DISK.
diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt
new file mode 100644
index 00000000000000..8e33d7c82c49c0
--- /dev/null
+++ b/Documentation/power/video_extension.txt
@@ -0,0 +1,34 @@
+This driver implement the ACPI Extensions For Display Adapters
+for integrated graphics devices on motherboard, as specified in
+ACPI 2.0 Specification, Appendix B, allowing to perform some basic
+control like defining the video POST device, retrieving EDID information
+or to setup a video output, etc.  Note that this is an ref. implementation only.
+It may or may not work for your integrated video device.
+
+Interfaces exposed to userland through /proc/acpi/video:
+
+VGA/info : display the supported video bus device capability like ,Video ROM, CRT/LCD/TV.
+VGA/ROM :  Used to get a copy of the display devices' ROM data (up to 4k).
+VGA/POST_info : Used to determine what options are implemented.
+VGA/POST : Used to get/set POST device.
+VGA/DOS : Used to get/set ownership of output switching:
+	Please refer ACPI spec B.4.1 _DOS
+VGA/CRT : CRT output
+VGA/LCD : LCD output
+VGA/TV : TV output 
+VGA/*/brightness : Used to get/set brightness of output device
+
+Notify event through /proc/acpi/event:
+
+#define ACPI_VIDEO_NOTIFY_SWITCH        0x80
+#define ACPI_VIDEO_NOTIFY_PROBE         0x81
+#define ACPI_VIDEO_NOTIFY_CYCLE         0x82
+#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT   0x83
+#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT   0x84
+
+#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS      0x82
+#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS        0x83
+#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS        0x84
+#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS       0x85
+#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF           0x86
+
diff --git a/Documentation/prio_tree.txt b/Documentation/prio_tree.txt
new file mode 100644
index 00000000000000..2fbb0c49bc5b6d
--- /dev/null
+++ b/Documentation/prio_tree.txt
@@ -0,0 +1,107 @@
+The prio_tree.c code indexes vmas using 3 different indexes:
+	* heap_index  = vm_pgoff + vm_size_in_pages : end_vm_pgoff
+	* radix_index = vm_pgoff : start_vm_pgoff
+	* size_index = vm_size_in_pages
+
+A regular radix-priority-search-tree indexes vmas using only heap_index and
+radix_index. The conditions for indexing are:
+	* ->heap_index >= ->left->heap_index &&
+		->heap_index >= ->right->heap_index
+	* if (->heap_index == ->left->heap_index)
+		then ->radix_index < ->left->radix_index;
+	* if (->heap_index == ->right->heap_index)
+		then ->radix_index < ->right->radix_index;
+	* nodes are hashed to left or right subtree using radix_index
+	  similar to a pure binary radix tree.
+
+A regular radix-priority-search-tree helps to store and query
+intervals (vmas). However, a regular radix-priority-search-tree is only
+suitable for storing vmas with different radix indices (vm_pgoff).
+
+Therefore, the prio_tree.c extends the regular radix-priority-search-tree
+to handle many vmas with the same vm_pgoff. Such vmas are handled in
+2 different ways: 1) All vmas with the same radix _and_ heap indices are
+linked using vm_set.list, 2) if there are many vmas with the same radix
+index, but different heap indices and if the regular radix-priority-search
+tree cannot index them all, we build an overflow-sub-tree that indexes such
+vmas using heap and size indices instead of heap and radix indices. For
+example, in the figure below some vmas with vm_pgoff = 0 (zero) are
+indexed by regular radix-priority-search-tree whereas others are pushed
+into an overflow-subtree. Note that all vmas in an overflow-sub-tree have
+the same vm_pgoff (radix_index) and if necessary we build different
+overflow-sub-trees to handle each possible radix_index. For example,
+in figure we have 3 overflow-sub-trees corresponding to radix indices
+0, 2, and 4.
+
+In the final tree the first few (prio_tree_root->index_bits) levels
+are indexed using heap and radix indices whereas the overflow-sub-trees below
+those levels (i.e. levels prio_tree_root->index_bits + 1 and higher) are
+indexed using heap and size indices. In overflow-sub-trees the size_index
+is used for hashing the nodes to appropriate places.
+
+Now, an example prio_tree:
+
+  vmas are represented [radix_index, size_index, heap_index]
+                 i.e., [start_vm_pgoff, vm_size_in_pages, end_vm_pgoff]
+
+level  prio_tree_root->index_bits = 3
+-----
+												_
+  0			 				[0,7,7]					 |
+  							/     \					 |
+				      ------------------       ------------			 |     Regular
+  				     /					   \			 |  radix priority
+  1		 		[1,6,7]					  [4,3,7]		 |   search tree
+  				/     \					  /     \		 |
+			 -------       -----			    ------       -----		 |  heap-and-radix
+			/		    \			   /		      \		 |      indexed
+  2		    [0,6,6]	 	   [2,5,7]		[5,2,7]		    [6,1,7]	 |
+		    /     \		   /     \		/     \		    /     \	 |
+  3		[0,5,5]	[1,5,6]		[2,4,6]	[3,4,7]	    [4,2,6] [5,1,6]	[6,0,6]	[7,0,7]	 |
+		   /			   /		       /		   		_
+                  /		          /		      /					_
+  4	      [0,4,4]		      [2,3,5]		   [4,1,5]				 |
+  		 /			 /		      /					 |
+  5	     [0,3,3]		     [2,2,4]		  [4,0,4]				 |  Overflow-sub-trees
+  		/			/							 |
+  6	    [0,2,2]		    [2,1,3]							 |    heap-and-size
+  	       /		       /							 |       indexed
+  7	   [0,1,1]		   [2,0,2]							 |
+  	      /											 |
+  8	  [0,0,0]										 |
+  												_
+
+Note that we use prio_tree_root->index_bits to optimize the height
+of the heap-and-radix indexed tree. Since prio_tree_root->index_bits is
+set according to the maximum end_vm_pgoff mapped, we are sure that all
+bits (in vm_pgoff) above prio_tree_root->index_bits are 0 (zero). Therefore,
+we only use the first prio_tree_root->index_bits as radix_index.
+Whenever index_bits is increased in prio_tree_expand, we shuffle the tree
+to make sure that the first prio_tree_root->index_bits levels of the tree
+is indexed properly using heap and radix indices.
+
+We do not optimize the height of overflow-sub-trees using index_bits.
+The reason is: there can be many such overflow-sub-trees and all of
+them have to be suffled whenever the index_bits increases. This may involve
+walking the whole prio_tree in prio_tree_insert->prio_tree_expand code
+path which is not desirable. Hence, we do not optimize the height of the
+heap-and-size indexed overflow-sub-trees using prio_tree->index_bits.
+Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits
+of size_index. This may lead to skewed sub-trees because most of the
+higher significant bits of the size_index are likely to be be 0 (zero). In
+the example above, all 3 overflow-sub-trees are skewed. This may marginally
+affect the performance. However, processes rarely map many vmas with the
+same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally
+do not require overflow-sub-trees to index all vmas.
+
+From the above discussion it is clear that the maximum height of
+a prio_tree can be prio_tree_root->index_bits + BITS_PER_LONG.
+However, in most of the common cases we do not need overflow-sub-trees,
+so the tree height in the common cases will be prio_tree_root->index_bits.
+
+It is fair to mention here that the prio_tree_root->index_bits
+is increased on demand, however, the index_bits is not decreased when
+vmas are removed from the prio_tree. That's tricky to do. Hence, it's
+left as a home work problem.
+
+
diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt
new file mode 100644
index 00000000000000..2150e5fc39738e
--- /dev/null
+++ b/Documentation/s390/monreader.txt
@@ -0,0 +1,175 @@
+
+Date  : 2004-Nov-04
+Author: Gerald Schaefer (geraldsc@de.ibm.com)
+
+
+             Linux API for read access to z/VM Monitor Records
+             =================================================
+
+
+Description
+===========
+This item delivers a new Linux API in the form of a misc char device that is
+useable from user space and allows read access to the z/VM Monitor Records
+collected by the *MONITOR System Service of z/VM.
+
+
+User Requirements
+=================
+The z/VM guest on which you want to access this API needs to be configured in
+order to allow IUCV connections to the *MONITOR service, i.e. it needs the
+IUCV *MONITOR statement in its user entry. If the monitor DCSS to be used is
+restricted (likely), you also need the NAMESAVE <DCSS NAME> statement.
+This item will use the IUCV device driver to access the z/VM services, so you
+need a kernel with IUCV support. You also need z/VM version 4.4 or 5.1.
+
+There are two options for being able to load the monitor DCSS (examples assume
+that the monitor DCSS begins at 144 MB and ends at 152 MB). You can query the
+location of the monitor DCSS with the Class E privileged CP command Q NSS MAP
+(the values BEGPAG and ENDPAG are given in units of 4K pages).
+
+See also "CP Command and Utility Reference" (SC24-6081-00) for more information
+on the DEF STOR and Q NSS MAP commands, as well as "Saved Segments Planning
+and Administration" (SC24-6116-00) for more information on DCSSes.
+
+1st option:
+-----------
+You can use the CP command DEF STOR CONFIG to define a "memory hole" in your
+guest virtual storage around the address range of the DCSS.
+
+Example: DEF STOR CONFIG 0.140M 200M.200M
+
+This defines two blocks of storage, the first is 140MB in size an begins at
+address 0MB, the second is 200MB in size and begins at address 200MB,
+resulting in a total storage of 340MB. Note that the first block should
+always start at 0 and be at least 64MB in size.
+
+2nd option:
+-----------
+Your guest virtual storage has to end below the starting address of the DCSS
+and you have to specify the "mem=" kernel parameter in your parmfile with a
+value greater than the ending address of the DCSS.
+
+Example: DEF STOR 140M
+
+This defines 140MB storage size for your guest, the parameter "mem=160M" is
+added to the parmfile.
+
+
+User Interface
+==============
+The char device is implemented as a kernel module named "monreader",
+which can be loaded via the modprobe command, or it can be compiled into the
+kernel instead. There is one optional module (or kernel) parameter, "mondcss",
+to specify the name of the monitor DCSS. If the module is compiled into the
+kernel, the kernel parameter "monreader.mondcss=<DCSS NAME>" can be specified
+in the parmfile.
+
+The default name for the DCSS is "MONDCSS" if none is specified. In case that
+there are other users already connected to the *MONITOR service (e.g.
+Performance Toolkit), the monitor DCSS is already defined and you have to use
+the same DCSS. The CP command Q MONITOR (Class E privileged) shows the name
+of the monitor DCSS, if already defined, and the users connected to the
+*MONITOR service.
+Refer to the "z/VM Performance" book (SC24-6109-00) on how to create a monitor
+DCSS, you need Class E privileges to define and save a DCSS.
+
+Example:
+--------
+modprobe monreader mondcss=MYDCSS
+
+This loads the module and sets the DCSS name to "MYDCSS".
+
+NOTE:
+-----
+This API provides no interface to control the *MONITOR service, e.g. specifiy
+which data should be collected. This can be done by the CP command MONITOR
+(Class E privileged), see "CP Command and Utility Reference".
+
+Device nodes with udev:
+-----------------------
+After loading the module, a char device will be created along with the device
+node /<udev directory>/monreader.
+
+Device nodes without udev:
+--------------------------
+If your distribution does not support udev, a device node will not be created
+automatically and you have to create it manually after loading the module.
+Therefore you need to know the major and minor numbers of the device. These
+numbers can be found in /sys/class/misc/monreader/dev.
+Typing cat /sys/class/misc/monreader/dev will give an output of the form
+<major>:<minor>. The device node can be created via the mknod command, enter
+mknod <name> c <major> <minor>, where <name> is the name of the device node
+to be created.
+
+Example:
+--------
+# modprobe monreader
+# cat /sys/class/misc/monreader/dev
+10:63
+# mknod /dev/monreader c 10 63
+
+This loads the module with the default monitor DCSS (MONDCSS) and creates a
+device node.
+
+File operations:
+----------------
+The following file operations are supported: open, release, read, poll.
+There are two alternative methods for reading: either non-blocking read in
+conjunction with polling, or blocking read without polling. IOCTLs are not
+supported.
+
+Read:
+-----
+Reading from the device provides a set of one or more contiguous monitor
+records, there is no control data (unlike the CMS MONWRITE utility output).
+The monitor record layout can be found here (z/VM 5.1):
+http://www.vm.ibm.com/pubs/mon510/index.html
+
+Each set of records is exclusively composed of either event records or sample
+records. The end of such a set of records is indicated by a successful read
+with a return value of 0 (0-Byte read).
+Any received data must be considered invalid until a complete record set was
+read successfully, including the closing 0-Byte read. Therefore you should
+always read the complete set into a buffer before processing the data.
+
+The maximum size of a set of records can be as large as the size of the
+monitor DCSS, so design the buffer adequately or use dynamic memory allocation
+The size of the monitor DCSS will be printed into syslog after loading the
+module. You can also use the (Class E privileged) CP command Q NSS MAP to
+list all available segments and information about them.
+
+As with most char devices, error conditions are indicated by returning a
+negative value for the number of bytes read. In this case, the errno variable
+indicates the error condition:
+
+EIO: reply failed, read data is invalid and the application
+     should discard the data read since the last successful read with 0 size.
+EFAULT: copy_to_user failed, read data is invalid and the application should
+        discard the data read since the last successful read with 0 size.
+EAGAIN: occurs on a non-blocking read if there is no data available at the
+        moment. There is no data missing or corrupted, just try again or rather
+        use polling for non-blocking reads.
+EOVERFLOW: message limit reached, the data read since the last successful
+           read with 0 size is valid but subsequent records may be missing.
+
+In the last case (EOVERFLOW) there may be missing data, in the first two cases
+(EIO, EFAULT) there will be missing data. It's up to the application if it will
+continue reading subsequent records or rather exit.
+
+Open:
+-----
+Only one user is allowed to open the char device. If it is already in use, the
+open function will fail (return a negative value) and set errno to EBUSY.
+The open function may also fail if an IUCV connection to the *MONITOR service
+cannot be established. In this case errno will be set to EIO and an error
+message with an IPUSER SEVER code will be printed into syslog.
+The IPUSER SEVER codes are described in the "z/VM Performance" book.
+
+NOTE:
+-----
+As soon as the device is opened, incoming messages will be accepted and they
+will account for the message limit, i.e. opening the device without reading
+from it will provoke the "message limit reached" error (EOVERFLOW error code)
+eventually.
+
diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt
index f13415a3ac3599..af9abe2913c340 100644
--- a/Documentation/scsi/sym53c8xx_2.txt
+++ b/Documentation/scsi/sym53c8xx_2.txt
@@ -4,7 +4,9 @@ Written by Gerard Roudier <groudier@free.fr>
 21 Rue Carnot
 95170 DEUIL LA BARRE - FRANCE
 
-Decembre 28 2000
+Updated by Matthew Wilcox <matthew@wil.cx>
+
+2004-10-09
 ===============================================================================
 
 1.  Introduction
@@ -29,26 +31,20 @@ Decembre 28 2000
 10. Boot setup commands
       10.1 Syntax
       10.2 Available arguments
-             10.2.1  Master parity checking
-             10.2.2  Scsi parity checking
-             10.2.3  Default number of tagged commands
-             10.2.4  Default synchronous period factor
-             10.2.5  Verbosity level
-             10.2.6  Debug mode
-             10.2.7  Burst max
-             10.2.8  LED support
-             10.2.9  Max wide
-             10.2.10 Differential mode
-             10.2.11 IRQ mode
-             10.2.12 Reverse probe
-             10.2.13 Fix up PCI configuration space
-             10.2.14 Serial NVRAM
-             10.2.15 Check SCSI BUS 
-             10.2.16 Exclude a host from being attached
-             10.2.17 Suggest a default SCSI id for hosts
-      10.3 PCI configuration fix-up boot option
-      10.4 Serial NVRAM support boot option
-      10.5 SCSI BUS checking boot option
+             10.2.1  Default number of tagged commands
+             10.2.2  Burst max
+             10.2.3  LED support
+             10.2.4  Differential mode
+             10.2.5  IRQ mode
+             10.2.6  Check SCSI BUS 
+             10.2.7  Suggest a default SCSI id for hosts
+             10.2.8  Verbosity level
+             10.2.9  Debug mode
+             10.2.10 Settle delay
+             10.2.11 Serial NVRAM
+             10.2.12 Exclude a host from being attached
+      10.3 Converting from old options
+      10.4 SCSI BUS checking boot option
 11. SCSI problem troubleshooting
       15.1 Problem tracking
       15.2 Understanding hardware error reports
@@ -94,6 +90,9 @@ The history of this driver can be summerized as follows:
       Write a glue code for Linux.
           Gerard Roudier
 
+2004: Remove FreeBSD compatibility code.  Remove support for versions of
+      Linux before 2.6.  Start using Linux facilities.
+
 This README file addresses the Linux version of the driver. Under FreeBSD, 
 the driver documentation is the sym.8 man page.
 
@@ -279,11 +278,10 @@ setting verbose level to zero, as follow:
 6. Parity checking
 
 The driver supports SCSI parity checking and PCI bus master parity
-checking. These features must be enabled in order to ensure safe data
-transfers. However, some flawed devices or mother boards will have
-problems with parity. You can disable either PCI parity or SCSI parity 
-checking by entering appropriate options from the boot command line.
-(See 10: Boot setup commands).
+checking.  These features must be enabled in order to ensure safe
+data transfers.  Some flawed devices or mother boards may have problems
+with parity.  The options to defeat parity checking have been removed
+from the driver.
 
 7. Profiling information
 
@@ -428,77 +426,90 @@ Synchronous transfers frequency       (default answer: 80)
 
 10.1 Syntax
 
-Setup commands can be passed to the driver either at boot time or as a 
-string variable using 'insmod'.
-
-A boot setup command for this driver begins with the driver name "sym53c8xx=".
-The kernel syntax parser then expects an optionnal list of integers separated 
-with comma followed by an optional list of  comma-separated strings.
+Setup commands can be passed to the driver either at boot time or as
+parameters to modprobe, as described in Documentation/kernel-parameters.txt
 
 Example of boot setup command under lilo prompt:
 
-lilo: linux root=/dev/sda2 sym53c8xx=tags:4,sync:10,debug:0x200
+lilo: linux root=/dev/sda2 sym53c8xx.cmd_per_lun=4 sym53c8xx.sync=10 sym53c8xx.debug=0x200
 
 - enable tagged commands, up to 4 tagged commands queued.
 - set synchronous negotiation speed to 10 Mega-transfers / second.
 - set DEBUG_NEGO flag.
 
-Since comma seems not to be allowed when defining a string variable using  
-'insmod', the driver also accepts <space> as option separator. 
-The following command will install driver module with the same options as 
-above.
-
-    insmod sym53c8xx.o sym53c8xx="tags:4 sync:10 debug:0x200"
+The following command will install the driver module with the same
+options as above.
 
-The integer list of arguments is discarded by the driver. 
-
-Each string argument must be specified as "keyword:value". Only lower-case 
-characters and digits are allowed.
+    modprobe sym53c8xx cmd_per_lun=4 sync=10 debug=0x200"
 
 10.2 Available arguments
 
-10.2.1  Master parity checking
-        mpar:y     enabled
-        mpar:n     disabled
-
-10.2.2  Scsi parity checking
-        spar:y     enabled
-        spar:n     disabled
-
-10.2.3  Default number of tagged commands
-        tags:0     (or tags:1 ) tagged command queuing disabled
-        tags:#tags (#tags  > 1) tagged command queuing enabled
+10.2.1  Default number of tagged commands
+        cmd_per_lun=0 (or cmd_per_lun=1) tagged command queuing disabled
+        cmd_per_lun=#tags (#tags > 1) tagged command queuing enabled
   #tags will be truncated to the max queued commands configuration parameter.
-  This option also allows to specify a command queue depth for each device 
-  that support tagged command queueing.
+
+10.2.2  Detailed control of tagged commands
+  This option allows you to specify a command queue depth for each device 
+  that supports tagged command queueing.
   Example:
-      sym53c8xx=tags:10/t2t3q16-t5q24/t1u2q32
-               will set devices queue depth as follow:
+      tag_ctrl=10/t2t3q16-t5q24/t1u2q32
+  will set devices queue depth as follow:
       - controller #0 target #2 and target #3                  -> 16 commands,
       - controller #0 target #5                                -> 24 commands,
       - controller #1 target #1 logical unit #2                -> 32 commands,
       - all other logical units (all targets, all controllers) -> 10 commands.
 
-10.2.4  Default synchronous period factor
-        sync:255     disabled (asynchronous transfer mode)
-        sync:#factor
-  #factor =  9     Ultra-3 SCSI 80 Mega-transfers / second (Wide only)
-  #factor = 10     Ultra-2 SCSI 40 Mega-transfers / second
-  #factor = 11     Ultra-2 SCSI 33 Mega-transfers / second
-  #factor < 25     Ultra   SCSI 20 Mega-transfers / second
-  #factor < 50     Fast    SCSI-2
-
-  In all cases, the driver will use the minimum transfer period supported by 
-  controllers according to SYM53C8XX chip type.
-
-10.2.5  Verbosity level
-        verb:0     minimal
-        verb:1     normal
-        verb:2     too much
-
-10.2.6 Debug mode
-        debug:0	 clear debug flags
-        debug:#x   set debug flags
+10.2.3 Burst max
+        burst=0    burst disabled
+        burst=255  get burst length from initial IO register settings.
+        burst=#x   burst enabled (1<<#x burst transfers max)
+  #x is an integer value which is log base 2 of the burst transfers max.
+  By default the driver uses the maximum value supported by the chip.
+
+10.2.4 LED support
+        led=1      enable  LED support
+        led=0      disable LED support
+  Do not enable LED support if your scsi board does not use SDMS BIOS.
+  (See 'Configuration parameters')
+
+10.2.4 Differential mode
+        diff=0	never set up diff mode
+        diff=1	set up diff mode if BIOS set it
+        diff=2	always set up diff mode
+        diff=3	set diff mode if GPIO3 is not set
+
+10.2.5 IRQ mode
+        irqm=0     always open drain
+        irqm=1     same as initial settings (assumed BIOS settings)
+        irqm=2     always totem pole
+
+10.2.6 Check SCSI BUS 
+        buschk=<option bits>
+
+    Available option bits:
+        0x0:   No check.
+        0x1:   Check and do not attach the controller on error.  
+        0x2:   Check and just warn on error.
+
+10.2.7 Suggest a default SCSI id for hosts
+        hostid=255	no id suggested.
+        hostid=#x   (0 < x < 7) x suggested for hosts SCSI id.
+
+    If a host SCSI id is available from the NVRAM, the driver will ignore 
+    any value suggested as boot option. Otherwise, if a suggested value 
+    different from 255 has been supplied, it will use it. Otherwise, it will 
+    try to deduce the value previously set in the hardware and use value 
+    7 if the hardware value is zero.
+
+10.2.8  Verbosity level
+        verb=0     minimal
+        verb=1     normal
+        verb=2     too much
+
+10.2.9 Debug mode
+        debug=0	 clear debug flags
+        debug=#x   set debug flags
   #x is an integer value combining the following power-of-2 values:
   DEBUG_ALLOC       0x1
   DEBUG_PHASE       0x2
@@ -517,55 +528,17 @@ characters and digits are allowed.
   You can play safely with DEBUG_NEGO. However, some of these flags may 
   generate bunches of syslog messages. 
 
-10.2.7 Burst max
-        burst:0    burst disabled
-        burst:255  get burst length from initial IO register settings.
-        burst:#x   burst enabled (1<<#x burst transfers max)
-  #x is an integer value which is log base 2 of the burst transfers max.
-  By default the driver uses the maximum value supported by the chip.
+10.2.10 Settle delay
+        settle=n	delay for n seconds
 
-10.2.8 LED support
-        led:1      enable  LED support
-        led:0      disable LED support
-  Donnot enable LED support if your scsi board does not use SDMS BIOS.
-  (See 'Configuration parameters')
+  After a bus reset, the driver will delay for n seconds before talking
+  to any device on the bus.  The default is 3 seconds and safe mode will
+  default it to 10.
 
-10.2.9 Max wide
-        wide:1      wide scsi enabled
-        wide:0      wide scsi disabled
-  Some scsi boards use a 875 (ultra wide) and only supply narrow connectors.
-  If you have connected a wide device with a 50 pins to 68 pins cable 
-  converter, any accepted wide negotiation will break further data transfers.
-  In such a case, using "wide:0" in the bootup command will be helpfull. 
-
-10.2.10 Differential mode
-        diff:0	never set up diff mode
-        diff:1	set up diff mode if BIOS set it
-        diff:2	always set up diff mode
-        diff:3	set diff mode if GPIO3 is not set
-
-10.2.11 IRQ mode
-        irqm:0     always open drain
-        irqm:1     same as initial settings (assumed BIOS settings)
-        irqm:2     always totem pole
-
-10.2.12 Reverse probe
-        revprob:n   probe chip ids from the PCI configuration in this order:
-                    810, 815, 825, 860, 875, 885, 875A, 895, 896, 895A,
-                    1510D, 1010-33, 1010-66.
-        revprob:y   probe chip ids in the reverse order.
-
-10.2.13 Fix up PCI configuration space
-        pcifix:<option bits>
-
-    Available option bits:
-        0x0:   No attempt to fix PCI configuration space registers values.
-        0x1:   Set PCI cache-line size register if not set.
-        0x2:   Set write and invalidate bit in PCI command register.
-
-10.2.14 Serial NVRAM
-        nvram:n     do not look for serial NVRAM
-        nvram:y     test controllers for onboard serial NVRAM
+10.2.11 Serial NVRAM
+	NB: option not currently implemented.
+        nvram=n     do not look for serial NVRAM
+        nvram=y     test controllers for onboard serial NVRAM
         (alternate binary form)
         nvram=<bits options>
         0x01   look for NVRAM  (equivalent to nvram=y)
@@ -574,105 +547,28 @@ characters and digits are allowed.
         0x08   ignore NVRAM "Scan at boot time" parameter for all devices
         0x80   also attach controllers set to OFF in the NVRAM (sym53c8xx only)
 
-10.2.15 Check SCSI BUS 
-        buschk:<option bits>
-
-    Available option bits:
-        0x0:   No check.
-        0x1:   Check and do not attach the controller on error.  
-        0x2:   Check and just warn on error.
-
-10.2.16 Exclude a host from being attached
-        excl=<io_address>
+10.2.12 Exclude a host from being attached
+        excl=<io_address>,...
 
     Prevent host at a given io address from being attached.
-    For example 'sym53c8xx=excl:0xb400,excl:0xc000' indicate to the 
+    For example 'excl=0xb400,0xc000' indicate to the 
     driver not to attach hosts at address 0xb400 and 0xc000.
 
-10.2.17 Suggest a default SCSI id for hosts
-        hostid:255	no id suggested.
-        hostid:#x   (0 < x < 7) x suggested for hosts SCSI id.
-
-    If a host SCSI id is available from the NVRAM, the driver will ignore 
-    any value suggested as boot option. Otherwise, if a suggested value 
-    different from 255 has been supplied, it will use it. Otherwise, it will 
-    try to deduce the value previously set in the hardware and use value 
-    7 if the hardware value is zero.
-
-10.3 PCI configuration fix-up boot option
-
-pcifix:<option bits>
-
-Available option bits:
-    0x1:     Set PCI cache-line size register if not set.
-    0x2:     Set write and invalidate bit in PCI command register.
+10.3 Converting from old style options
 
-Use 'pcifix:3' in order to allow the driver to fix both PCI features.
+Previously, the sym2 driver accepted arguments of the form
+	sym53c8xx=tags:4,sync:10,debug:0x200
 
-Recent SYMBIOS 53C8XX scsi processors are able to use PCI read multiple 
-and PCI write and invalidate commands. These features require the 
-cache line size register to be properly set in the PCI configuration 
-space of the chips. On the other hand, chips will use PCI write and 
-invalidate commands only if the corresponding bit is set to 1 in the 
-PCI command register.
+As a result of the new module parameters, this is no longer available.
+Most of the options have remained the same, but tags has split into
+cmd_per_lun and tag_ctrl for its two different purposes.  The sample above
+would be specified as:
+	modprobe sym53c8xx cmd_per_lun=4 sync=10 debug=0x200
 
-Not all PCI bioses set the PCI cache line register and the PCI write and 
-invalidate bit in the PCI configuration space of 53C8XX chips.
-Optimized PCI accesses may be broken for some PCI/memory controllers or 
-make problems with some PCI boards.
+or on the kernel boot line as:
+	sym53c8xx.cmd_per_lun=4 sym53c8xx.sync=10 sym53c8xx.debug=0x200
 
-10.4 Serial NVRAM support boot option
-
-nvram:n     do not look for serial NVRAM
-nvram:y     test controllers for onboard serial NVRAM
-
-This option can also been entered as an hexadecimal value that allows 
-to control what information the driver will get from the NVRAM and what 
-information it will ignore.
-For details see '17. Serial NVRAM support'.
-
-When this option is enabled, the driver tries to detect all boards using 
-a Serial NVRAM. This memory is used to hold user set up parameters.
-
-The parameters the driver is able to get from the NVRAM depend on the 
-data format used, as follow:
-
-                                 Tekram format      Symbios format
-General and host parameters
-    Boot order                         N                   Y
-    Host SCSI ID                       Y                   Y
-    SCSI parity checking               Y                   Y
-    Verbose boot messages              N                   Y
-SCSI devices parameters
-    Synchronous transfer speed         Y                   Y
-    Wide 16 / Narrow                   Y                   Y
-    Tagged Command Queuing enabled     Y                   Y
-    Disconnections enabled             Y                   Y
-    Scan at boot time                  N                   Y
-
-In order to speed up the system boot, for each device configured without 
-the "scan at boot time" option, the driver forces an error on the 
-first TEST UNIT READY command received for this device.
-
-Some SDMS BIOS revisions seem to be unable to boot cleanly with very fast 
-hard disks. In such a situation you cannot configure the NVRAM with 
-optimized parameters value.
-
-The 'nvram' boot option can be entered in hexadecimal form in order 
-to ignore some options configured in the NVRAM, as follow:
-
-nvram=<bits options>
-      0x01   look for NVRAM  (equivalent to nvram=y)
-      0x02   ignore NVRAM "Synchronous negotiation" parameters for all devices
-      0x04   ignore NVRAM "Wide negotiation"  parameter for all devices
-      0x08   ignore NVRAM "Scan at boot time" parameter for all devices
-      0x80   also attach controllers set to OFF in the NVRAM (sym53c8xx only)
-
-Option 0x80 is disabled by default.
-Result is that, by default (option not set), the sym53c8xx driver will not 
-attach controllers set to OFF in the NVRAM.
-
-10.5 SCSI BUS checking boot option.
+10.4 SCSI BUS checking boot option.
 
 When this option is set to a non-zero value, the driver checks SCSI lines 
 logic state, 100 micro-seconds after having asserted the SCSI RESET line.
@@ -805,14 +701,8 @@ serial NVRAM is used by Symbios and Tekram to hold set up parameters for the
 host adaptor and it's attached drives.
 
 The Symbios NVRAM also holds data on the boot order of host adaptors in a
-system with more than one host adaptor. This enables the order of scanning
-the cards for drives to be changed from the default used during host adaptor
-detection.
-
-This can be done to a limited extent at the moment using "reverse probe" but
-this only changes the order of detection of different types of cards. The
-NVRAM boot order settings can do this as well as change the order the same
-types of cards are scanned in, something "reverse probe" cannot do.
+system with more than one host adaptor.  This information is no longer used
+as it's fundamentally incompatible with the hotplug PCI model.
 
 Tekram boards using Symbios chips, DC390W/F/U, which have NVRAM are detected
 and this is used to distinguish between Symbios compatible and Tekram host 
@@ -824,6 +714,26 @@ used together with the Symbios cards using all their features, including
 enabled when using Tekram cards. It does nothing useful for Tekram host
 adaptors but does not cause problems either.)
 
+The parameters the driver is able to get from the NVRAM depend on the 
+data format used, as follow:
+
+                                 Tekram format      Symbios format
+General and host parameters
+    Boot order                         N                   Y
+    Host SCSI ID                       Y                   Y
+    SCSI parity checking               Y                   Y
+    Verbose boot messages              N                   Y
+SCSI devices parameters
+    Synchronous transfer speed         Y                   Y
+    Wide 16 / Narrow                   Y                   Y
+    Tagged Command Queuing enabled     Y                   Y
+    Disconnections enabled             Y                   Y
+    Scan at boot time                  N                   Y
+
+In order to speed up the system boot, for each device configured without 
+the "scan at boot time" option, the driver forces an error on the 
+first TEST UNIT READY command received for this device.
+
 
 17.2 Symbios NVRAM layout
 
diff --git a/Documentation/sonypi.txt b/Documentation/sonypi.txt
index a50949371b1bad..0f3b2405d09edf 100644
--- a/Documentation/sonypi.txt
+++ b/Documentation/sonypi.txt
@@ -1,6 +1,6 @@
 Sony Programmable I/O Control Device Driver Readme
 --------------------------------------------------
-	Copyright (C) 2001-2003 Stelian Pop <stelian@popies.net>
+	Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
 	Copyright (C) 2001-2002 Alcôve <www.alcove.com>
 	Copyright (C) 2001 Michael Ashley <m.ashley@unsw.edu.au>
 	Copyright (C) 2001 Junichi Morita <jun1m@mars.dti.ne.jp>
@@ -23,16 +23,18 @@ generate, like:
 
 Those events (see linux/sonypi.h) can be polled using the character device node
 /dev/sonypi (major 10, minor auto allocated or specified as a option).
-
 A simple daemon which translates the jogdial movements into mouse wheel events
 can be downloaded at: <http://popies.net/sonypi/>
 
+Another option to intercept the events is to get them directly through the
+input layer.
+
 This driver supports also some ioctl commands for setting the LCD screen
-brightness and querying the batteries charge information (some more 
+brightness and querying the batteries charge information (some more
 commands may be added in the future).
 
 This driver can also be used to set the camera controls on Picturebook series
-(brightness, contrast etc), and is used by the video4linux driver for the 
+(brightness, contrast etc), and is used by the video4linux driver for the
 Motion Eye camera.
 
 Please note that this driver was created by reverse engineering the Windows
@@ -47,7 +49,7 @@ module argument syntax (<param>=<value> when passing the option to the
 module or sonypi.<param>=<value> on the kernel boot line when sonypi is
 statically linked into the kernel). Those options are:
 
-	minor: 		minor number of the misc device /dev/sonypi, 
+	minor: 		minor number of the misc device /dev/sonypi,
 			default is -1 (automatic allocation, see /proc/misc
 			or kernel logs)
 
@@ -59,14 +61,14 @@ statically linked into the kernel). Those options are:
 			get enabled unless you set this parameter to 1.
 			Do not use this option unless it's actually necessary,
 			some Vaio models don't deal well with this option.
-			This option is available only if the kernel is 
+			This option is available only if the kernel is
 			compiled without ACPI support (since it conflicts
-			with it and it shouldn't be required anyway if 
+			with it and it shouldn't be required anyway if
 			ACPI is already enabled).
 
-	verbose:	set to 1 to print unknown events received from the 
+	verbose:	set to 1 to print unknown events received from the
 			sonypi device.
-			set to 2 to print all events received from the 
+			set to 2 to print all events received from the
 			sonypi device.
 
 	compat:		uses some compatibility code for enabling the sonypi
@@ -75,14 +77,15 @@ statically linked into the kernel). Those options are:
 			add this option and report to the author.
 
 	mask:		event mask telling the driver what events will be
-			reported to the user. This parameter is required for some 
-			Vaio models where the hardware reuses values used in 
-			other Vaio models (like the FX series who does not
-			have a jogdial but reuses the jogdial events for
+			reported to the user. This parameter is required for
+			some Vaio models where the hardware reuses values
+			used in other Vaio models (like the FX series who does
+			not have a jogdial but reuses the jogdial events for
 			programmable keys events). The default event mask is
-			set to 0xffffffff, meaning that all possible events will be
-			tried. You can use the following bits to construct
-			your own event mask (from drivers/char/sonypi.h):
+			set to 0xffffffff, meaning that all possible events
+			will be tried. You can use the following bits to
+			construct your own event mask (from
+			drivers/char/sonypi.h):
 				SONYPI_JOGGER_MASK 		0x0001
 				SONYPI_CAPTURE_MASK 		0x0002
 				SONYPI_FNKEY_MASK 		0x0004
@@ -97,10 +100,10 @@ statically linked into the kernel). Those options are:
 				SONYPI_MEMORYSTICK_MASK		0x0800
 				SONYPI_BATTERY_MASK		0x1000
 
-	useinput:	if set (which is the default) jogdial events are
-			forwarded to the input subsystem as mouse wheel
-			events.
-			
+	useinput:	if set (which is the default) two input devices are
+			created, one which interprets the jogdial events as
+			mouse events, the other one which acts like a
+			keyboard reporting the pressing of the special keys.
 
 Module use:
 -----------
@@ -123,17 +126,17 @@ Bugs:
 	  external monitor on/off. There is no workaround yet, since this
 	  driver disables all APM management for those keys, by enabling the
 	  ACPI management (and the ACPI core stuff is not complete yet). If
-	  you have one of those laptops with working Fn keys and want to 
+	  you have one of those laptops with working Fn keys and want to
 	  continue to use them, don't use this driver.
 
 	- some users reported that the laptop speed is lower (dhrystone
 	  tested) when using the driver with the fnkeyinit parameter. I cannot
 	  reproduce it on my laptop and not all users have this problem.
-	  This happens because the fnkeyinit parameter enables the ACPI 
-	  mode (but without additional ACPI control, like processor 
+	  This happens because the fnkeyinit parameter enables the ACPI
+	  mode (but without additional ACPI control, like processor
 	  speed handling etc). Use ACPI instead of APM if it works on your
 	  laptop.
-	
+
 	- since all development was done by reverse engineering, there is
 	  _absolutely no guarantee_ that this driver will not crash your
 	  laptop. Permanently.
diff --git a/Documentation/time_interpolators.txt b/Documentation/time_interpolators.txt
index d9fefd5f4bd067..e3b60854fbc289 100644
--- a/Documentation/time_interpolators.txt
+++ b/Documentation/time_interpolators.txt
@@ -9,32 +9,33 @@ The architecture specific code typically provides gettimeofday and
 settimeofday under Linux. The time interpolator provides both if an arch
 defines CONFIG_TIME_INTERPOLATION. The arch still must set up timer tick
 operations and call the necessary functions to advance the clock.
+
 With the time interpolator a standardized interface exists for time
-interpolation between ticks which also allows the determination
-of time in a hardware independent way. The provided logic is highly scalable
+interpolation between ticks. The provided logic is highly scalable
 and has been tested in SMP situations of up to 512 CPUs.
 
 If CONFIG_TIME_INTERPOLATION is defined then the architecture specific code
-(or the device drivers - like HPET) must register time interpolators.
+(or the device drivers - like HPET) may register time interpolators.
 These are typically defined in the following way:
 
-static struct time_interpolator my_interpolator;
+static struct time_interpolator my_interpolator {
+	.frequency = MY_FREQUENCY,
+	.source = TIME_SOURCE_MMIO32,
+	.shift = 8,		/* scaling for higher accuracy */
+	.drift = -1,		/* Unknown drift */
+	.jitter = 0		/* time source is stable */
+};
 
 void time_init(void)
 {
 	....
 	/* Initialization of the timer *.
-	my_interpolator.frequency = MY_FREQUENCY;
-	my_interpolator.source = TIME_SOURCE_MMIO32;
 	my_interpolator.address = &my_timer;
-	my_interpolator.shift = 32;		/* increase accuracy of scaling */
-	my_interpolator.drift = -1;		/* Unknown */
-	my_interpolator.jitter = 0;		/* A stable time source */
 	register_time_interpolator(&my_interpolator);
 	....
 }
 
-For more details see include/linux/timex.h.
+For more details see include/linux/timex.h and kernel/timer.c.
 
-Christoph Lameter <christoph@lameter.com>, September 8, 2004
+Christoph Lameter <christoph@lameter.com>, October 31, 2004
 
diff --git a/Documentation/tipar.txt b/Documentation/tipar.txt
index 773b9a2483eba7..67133baef6ef21 100644
--- a/Documentation/tipar.txt
+++ b/Documentation/tipar.txt
@@ -4,7 +4,7 @@
 
 
 Author: Romain Lievin
-Homepage: http://lpg.ticalc.org/prj_dev
+Homepage: http://lpg.ticalc.org/prj_tidev/index.html
 
 
 INTRODUCTION:
@@ -12,31 +12,30 @@ INTRODUCTION:
 This is a driver for the very common home-made parallel link cable, a cable 
 designed for connecting TI8x/9x graphing calculators (handhelds) to a computer
 or workstation (Alpha, Sparc). Given that driver is built on parport, the 
-parallel port abstraction layer, this driver is independent of the platform.
+parallel port abstraction layer, this driver is architecture-independent.
 
 It can also be used with another device plugged on the same port (such as a
-ZIP drive). I have a 100MB ZIP and both of them work fine !
+ZIP drive). I have a 100MB ZIP and both of them work fine!
 
 If you need more information, please visit the 'TI drivers' homepage at the URL
 above.
 
 WHAT YOU NEED:
 
-A TI calculator of course and a program capable to communicate with your 
-calculator.
-TiLP will work for sure (since I am his developer !). yal92 may be able to use
+A TI calculator and a program capable of communicating with your calculator.
+
+TiLP will work for sure (since I am its developer!). yal92 may be able to use
 it by changing tidev for tipar (may require some hacking...).
 
 HOW TO USE IT:
 
 You must have first compiled parport support (CONFIG_PARPORT_DEV): either 
 compiled in your kernel, either as a module. 
-This driver supports the new device hierarchy (devfs).
 
-Next, (as root) from your appropriate modules directory (lib/modules/2.5.XX):
+Next, (as root):
 
        modprobe parport
-       insmod tipar.o
+       modprobe tipar
 
 If it is not already there (it usually is), create the device:
 
@@ -47,14 +46,14 @@ If it is not already there (it usually is), create the device:
 You will have to set permissions on this device to allow you to read/write
 from it:
 
-       chmod 666 /dev/tipar?
+       chmod 666 /dev/tipar[0..2]
        
 Now you are ready to run a linking program such as TiLP. Be sure to configure 
 it properly (RTFM).
        
 MODULE PARAMETERS:
 
-  You can set these with:  insmod tipar NAME=VALUE
+  You can set these with:  modprobe tipar NAME=VALUE
   There is currently no way to set these on a per-cable basis.
 
   NAME: timeout
@@ -66,11 +65,12 @@ MODULE PARAMETERS:
   NAME: delay
   TYPE: integer
   DEFAULT: 10
-  DESC: Inter-bit delay in micro-seconds. An lower value gives an higher data 
+  DESC: Inter-bit delay in micro-seconds. A lower value gives an higher data
 	rate but makes transmission less reliable.
 
 These parameters can be changed at run time by any program via ioctl(2) calls 
-as listed in ./include/linux/ticable.h
+as listed in ./include/linux/ticable.h.
+
 Rather than write 50 pages describing the ioctl() and so on, it is
 perhaps more useful you look at ticables library (dev_link.c) that demonstrates
 how to use them, and demonstrates the features of the driver. This is
diff --git a/Documentation/usb/sn9c102.txt b/Documentation/usb/sn9c102.txt
index 40c2f73a707fd6..18ceabdb36e41a 100644
--- a/Documentation/usb/sn9c102.txt
+++ b/Documentation/usb/sn9c102.txt
@@ -9,28 +9,32 @@
 Index
 =====
 1.  Copyright
-2.  License
-3.  Overview
-4.  Module dependencies
-5.  Module loading
-6.  Module parameters
-7.  Optional device control through "sysfs"
-8.  Supported devices
-9.  How to add support for new image sensors
-10. Notes for V4L2 application developers
-11. Contact information
-12. Credits
+2.  Disclaimer
+3.  License
+4.  Overview
+5.  Driver installation
+6.  Module loading
+7.  Module parameters
+8.  Optional device control through "sysfs"
+9.  Supported devices
+10. How to add support for new image sensors
+11. Notes for V4L2 application developers
+12. Contact information
+13. Credits
 
 
 1. Copyright
 ============
 Copyright (C) 2004 by Luca Risolia <luca.risolia@studio.unibo.it>
 
+
+2. Disclaimer
+=============
 SONiX is a trademark of SONiX Technology Company Limited, inc.
-This driver is not sponsored or developed by SONiX.
+This software is not sponsored or developed by SONiX.
 
 
-2. License
+3. License
 ==========
 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
@@ -47,29 +51,52 @@ along with this program; if not, write to the Free Software
 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 
 
-3. Overview
+4. Overview
 ===========
 This driver attempts to support the video and audio streaming capabilities of
 the devices mounting the SONiX SN9C101, SN9C102 and SN9C103 (or SUI-102) PC
 Camera Controllers.
 
-- It's worth to note that SONiX has never collaborated with me during the
+It's worth to note that SONiX has never collaborated with the author during the
 development of this project, despite several requests for enough detailed
 specifications of the register tables, compression engine and video data format
-of the above chips -
-
-Up to 64 cameras can be handled at the same time. They can be connected and
-disconnected from the host many times without turning off the computer, if
-your system supports hotplugging.
+of the above chips.
 
 The driver relies on the Video4Linux2 and USB core modules. It has been
 designed to run properly on SMP systems as well.
 
 The latest version of the SN9C10x driver can be found at the following URL:
-http://go.lamarinapunto.com/
-
-
-4. Module dependencies
+http://www.linux-projects.org/
+
+Some of the features of the driver are:
+
+- full compliance with the Video4Linux2 API (see also "Notes for V4L2
+  application developers" paragraph);
+- available mmap or read/poll methods for video streaming through isochronous
+  data transfers;
+- automatic detection of image sensor;
+- support for any window resolutions and optional panning within the maximum
+  pixel area of image sensor;
+- image downscaling with arbitrary scaling factors from 1, 2 and 4 in both
+  directions (see "Notes for V4L2 application developers" paragraph);
+- two different video formats for uncompressed or compressed data (see also
+  "Notes for V4L2 application developers" paragraph);
+- full support for the capabilities of many of the possible image sensors that
+  can be connected to the SN9C10x bridges, including, for istance, red, green,
+  blue and global gain adjustments and exposure (see "Supported devices"
+  paragraph for details);
+- use of default color settings for sunlight conditions;
+- dynamic I/O interface for both SN9C10x and image sensor control (see
+  "Optional device control through 'sysfs'" paragraph);
+- dynamic driver control thanks to various module parameters (see "Module
+  parameters" paragraph);
+- up to 64 cameras can be handled at the same time; they can be connected and
+  disconnected from the host many times without turning off the computer, if
+  your system supports hotplugging;
+- no known bugs.
+
+
+5. Module dependencies
 ======================
 For it to work properly, the driver needs kernel support for Video4Linux and
 USB.
@@ -101,7 +128,7 @@ And finally:
 	CONFIG_USB_SN9C102=m
 
 
-5. Module loading
+6. Module loading
 =================
 To use the driver, it is necessary to load the "sn9c102" module into memory
 after every other module required: "videodev", "usbcore" and, depending on
@@ -109,7 +136,6 @@ the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd".
 
 Loading can be done as shown below:
 
-	[root@localhost home]# modprobe usbcore
 	[root@localhost home]# modprobe sn9c102
 
 At this point the devices should be recognized. You can invoke "dmesg" to
@@ -118,7 +144,7 @@ analyze kernel messages and verify that the loading process has gone well:
 	[user@localhost home]$ dmesg
 
 
-6. Module parameters
+7. Module parameters
 ====================
 Module parameters are listed below:
 -------------------------------------------------------------------------------
@@ -144,12 +170,14 @@ Description:    Debugging information level, from 0 to 3:
                 2 = significant informations
                 3 = more verbose messages
                 Level 3 is useful for testing only, when only one device
-                is used.
+                is used. It also shows some more informations about the
+                hardware being detected. This parameter can be changed at
+                runtime thanks to the /sys filesystem.
 Default:        2
 -------------------------------------------------------------------------------
 
 
-7. Optional device control through "sysfs"
+8. Optional device control through "sysfs"
 ==========================================
 It is possible to read and write both the SN9C10x and the image sensor
 registers by using the "sysfs" filesystem interface.
@@ -191,10 +219,10 @@ Note that the SN9C10x always returns 0 when some of its registers are read.
 To avoid race conditions, all the I/O accesses to the files are serialized.
 
 
-8. Supported devices
+9. Supported devices
 ====================
-- I won't mention any of the names of the companies as well as their products
-here. They have never collaborated with me, so no advertising -
+None of the names of the companies as well as their products will be mentioned
+here. They have never collaborated with the author, so no advertising.
 
 From the point of view of a driver, what unambiguously identify a device are
 its vendor and product USB identifiers. Below is a list of known identifiers of
@@ -241,7 +269,7 @@ Vendor ID  Product ID
 0x0c45     0x60bc
 0x0c45     0x60be
 
-The list above does NOT imply that all those devices work with this driver: up
+The list above does not imply that all those devices work with this driver: up
 until now only the ones that mount the following image sensors are supported;
 kernel messages will always tell you whether this is the case:
 
@@ -259,16 +287,16 @@ If you think your camera is based on the above hardware and is not actually
 listed in the above table, you may try to add the specific USB VendorID and
 ProductID identifiers to the sn9c102_id_table[] in the file "sn9c102_sensor.h";
 then compile, load the module again and look at the kernel output.
-If this works, please send an email to me reporting the kernel messages, so
-that I can add a new entry in the list of supported devices.
+If this works, please send an email to the author reporting the kernel
+messages, so that a new entry in the list of supported devices can be added.
 
 Donations of new models for further testing and support would be much
-appreciated. I won't add official support for hardware that I don't actually
-have.
+appreciated. Non-available hardware won't be supported by the author of this
+driver.
 
 
-9. How to add support for new image sensors
-===========================================
+10. How to add support for new image sensors
+============================================
 It should be easy to write code for new sensors by using the small API that I
 have created for this purpose, which is present in "sn9c102_sensor.h"
 (documentation is included there). As an example, have a look at the code in
@@ -278,7 +306,7 @@ At the moment, possible unsupported image sensors are: HV7131x series (VGA),
 MI03x series (VGA), OV7620 (VGA), OV7630 (VGA), CIS-VF10 (VGA).
 
 
-10. Notes for V4L2 application developers
+11. Notes for V4L2 application developers
 =========================================
 This driver follows the V4L2 API specifications. In particular, it enforces two
 rules:
@@ -301,8 +329,18 @@ factor can be chosen arbitrarily by the "negotiation" of the "source" and
 that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the
 scaling factor is restored to 1.
 
+This driver supports two different video formats: the first one is the "8-bit
+Sequential Bayer" format and can be used to obtain uncompressed video data
+from the device through the current I/O method, while the second one provides
+"raw" compressed video data (without the initial and final frame headers). The
+compression quality may vary from 0 to 1 and can be selected or queried thanks
+to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum
+flexibility, the default active video format depends on how the image sensor
+being used is initialized (as described in the documentation of the API for the
+image sensors supplied by this driver).
+
 
-11. Contact information
+12. Contact information
 =======================
 I may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
 
@@ -311,7 +349,7 @@ My public 1024-bit key should be available at any keyserver; the fingerprint
 is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
 
 
-12. Credits
+13. Credits
 ===========
 I would thank the following persons:
 
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index d431f19f76829a..f001cd93b79b68 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -211,6 +211,62 @@ ZyXEL omni.net lcd plus ISDN TA
   azummo@towertech.it
 
 
+Cypress M8 CY4601 Family Serial Driver
+
+  This driver was in most part developed by Neil "koyama" Whelchel.  It
+  has been improved since that previous form to support dynamic serial
+  line settings and improved line handling.  The driver is for the most
+  part stable and has been tested on an smp machine. (dual p2)
+
+    Chipsets supported under CY4601 family:
+	
+		CY7C63723, CY7C63742, CY7C63743, CY7C64013
+
+    Devices supported:
+
+		-DeLorme's USB Earthmate (SiRF Star II lp arch)
+		-Cypress HID->COM RS232 adapter
+	
+		Note: Cypress Semiconductor claims no affiliation with the
+			the hid->com device.
+
+	Most devices using chipsets under the CY4601 family should
+     work with the driver.  As long as they stay true to the CY4601
+     usbserial specification.
+
+    Technical notes:
+
+        The Earthmate starts out at 4800 8N1 by default... the driver will
+	upon start init to this setting.  usbserial core provides the rest
+	of the termios settings, along with some custom termios so that the
+	output is in proper format and parsable.
+	
+	The device can be put into sirf mode by issuing NMEA command:
+		$PSRF100,<protocol>,<baud>,<databits>,<stopbits>,<parity>*CHECKSUM
+		$PSRF100,0,9600,8,1,0*0C
+
+		It should then be sufficient to change the port termios to match this
+		to begin communicating.
+
+	As far as I can tell it supports pretty much every sirf command as
+	documented online available with firmware 2.31, with some unknown
+	message ids.
+
+	The hid->com adapter can run at a maximum baud of 115200bps.  Please note
+	that the device has trouble or is incapable of raising line voltage properly.
+	It will be fine with null modem links, as long as you do not try to link two
+	together without hacking the adapter to set the line high.
+
+	The driver is smp safe.  Performance with the driver is rather low when using
+	it for transfering files.  This is being worked on, but I would be willing to
+	accept patches.  An urb queue or packet buffer would likely fit the bill here.
+
+	If you have any questions, problems, patches, feature requests, etc. you can
+	contact me here via email:
+					dignome@gmail.com
+		(your problems/patches can alternately be submitted to usb-devel)
+
+
 Digi AccelePort Driver
 
   This driver supports the Digi AccelePort USB 2 and 4 devices, 2 port
diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt
index 5adcd25024bb43..2137da97552fb6 100644
--- a/Documentation/video4linux/meye.txt
+++ b/Documentation/video4linux/meye.txt
@@ -1,12 +1,12 @@
 Vaio Picturebook Motion Eye Camera Driver Readme
 ------------------------------------------------
-	Copyright (C) 2001-2003 Stelian Pop <stelian@popies.net>
+	Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
 	Copyright (C) 2001-2002 Alcôve <www.alcove.com>
 	Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
 
 This driver enable the use of video4linux compatible applications with the
-Motion Eye camera. This driver requires the "Sony Vaio Programmable I/O 
-Control Device" driver (which can be found in the "Character drivers" 
+Motion Eye camera. This driver requires the "Sony Vaio Programmable I/O
+Control Device" driver (which can be found in the "Character drivers"
 section of the kernel configuration utility) to be compiled and installed
 (using its "camera=1" parameter).
 
@@ -24,7 +24,7 @@ This driver supports the 'second' version of the MotionEye camera :)
 The first version was connected directly on the video bus of the Neomagic
 video card and is unsupported.
 
-The second one, made by Kawasaki Steel is fully supported by this 
+The second one, made by Kawasaki Steel is fully supported by this
 driver (PCI vendor/device is 0x136b/0xff01)
 
 The third one, present in recent (more or less last year) Picturebooks
@@ -41,13 +41,12 @@ little information if any is available for this camera
 Driver options:
 ---------------
 
-Several options can be passed to the meye driver, either by adding them
-to /etc/modprobe.conf file, when the driver is compiled as a module, or
-by adding the following to the kernel command line (in your bootloader):
+Several options can be passed to the meye driver using the standard
+module argument syntax (<param>=<value> when passing the option to the
+module or meye.<param>=<value> on the kernel boot line when meye is
+statically linked into the kernel). Those options are:
 
-	meye=gbuffers[,gbufsize[,video_nr]]
-
-where:
+	forcev4l1:	force use of V4L1 API instead of V4L2
 
 	gbuffers:	number of capture buffers, default is 2 (32 max)
 
@@ -81,8 +80,9 @@ Usage:
 Private API:
 ------------
 
-	The driver supports frame grabbing with the video4linux API, so
-	all video4linux tools (like xawtv) should work with this driver.
+	The driver supports frame grabbing with the video4linux API
+	(either v4l1 or v4l2), so all video4linux tools (like xawtv)
+	should work with this driver.
 
 	Besides the video4linux interface, the driver has a private interface
 	for accessing the Motion Eye extended parameters (camera sharpness,
@@ -116,7 +116,7 @@ Private API:
 	MEYEIOC_STILLJCAPT
 		Takes a snapshot in an uncompressed or compressed jpeg format.
 		This ioctl blocks until the snapshot is done and returns (for
-		jpeg snapshot) the size of the image. The image data is 
+		jpeg snapshot) the size of the image. The image data is
 		available from the first mmap'ed buffer.
 
 	Look at the 'motioneye' application code for an actual example.
@@ -124,13 +124,7 @@ Private API:
 Bugs / Todo:
 ------------
 
-	- overlay output is not supported (although the camera is capable of).
-	  	(it should not be too hard to to it, provided we found how...)
-		
-	- mjpeg hardware playback doesn't work (depends on overlay...)
+	- the driver could be much cleaned up by removing the v4l1 support.
+	  However, this means all v4l1-only applications will stop working.
 
-	- rewrite the driver to use some common video4linux API for snapshot
-	  and mjpeg capture. Unfortunately, video4linux1 does not permit it,
-	  the BUZ API seems to be targeted to TV cards only. The video4linux 2
-	  API may be an option, if it goes into the kernel (maybe 2.5 
-	  material ?).
+	- 'motioneye' still uses the meye private v4l1 API extensions.