140 files changed, 3454 insertions, 1845 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 02457ec9c94f..f08ca9535733 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -104,8 +104,6 @@ firmware_class/
         - request_firmware() hotplug interface info.
 floppy.txt
         - notes and driver options for the floppy disk driver.
-ftape.txt
-        - notes about the floppy tape device driver.
 hayes-esp.txt
         - info on using the Hayes ESP serial driver.
 highuid.txt
diff --git a/Documentation/ABI/testing/debugfs-pktcdvd b/Documentation/ABI/testing/debugfs-pktcdvd
new file mode 100644
index 000000000000..03dbd883cc41
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-pktcdvd
@@ -0,0 +1,20 @@
+What:           /debug/pktcdvd/pktcdvd[0-7]
+Date:           Oct. 2006
+KernelVersion:  2.6.19
+Contact:        Thomas Maier <balagi@justmail.de>
+Description:
+
+debugfs interface
+-----------------
+
+The pktcdvd module (packet writing driver) creates
+these files in debugfs:
+
+/debug/pktcdvd/pktcdvd[0-7]/
+    info            (0444) Lots of human readable driver
+                           statistics and infos. Multiple lines!
+
+Example:
+-------
+
+cat /debug/pktcdvd/pktcdvd0/info
diff --git a/Documentation/ABI/testing/sysfs-class-pktcdvd b/Documentation/ABI/testing/sysfs-class-pktcdvd
new file mode 100644
index 000000000000..c4c55edc9a5c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-pktcdvd
@@ -0,0 +1,72 @@
+What:           /sys/class/pktcdvd/
+Date:           Oct. 2006
+KernelVersion:  2.6.19
+Contact:        Thomas Maier <balagi@justmail.de>
+Description:
+
+sysfs interface
+---------------
+
+The pktcdvd module (packet writing driver) creates
+these files in the sysfs:
+(<devid> is in format  major:minor )
+
+/sys/class/pktcdvd/
+    add            (0200)  Write a block device id (major:minor)
+                           to create a new pktcdvd device and map
+                           it to the block device.
+
+    remove         (0200)  Write the pktcdvd device id (major:minor)
+                           to it to remove the pktcdvd device.
+
+    device_map     (0444)  Shows the device mapping in format:
+                             pktcdvd[0-7] <pktdevid> <blkdevid>
+
+/sys/class/pktcdvd/pktcdvd[0-7]/
+    dev                   (0444) Device id
+    uevent                (0200) To send an uevent.
+
+/sys/class/pktcdvd/pktcdvd[0-7]/stat/
+    packets_started       (0444) Number of started packets.
+    packets_finished      (0444) Number of finished packets.
+
+    kb_written            (0444) kBytes written.
+    kb_read               (0444) kBytes read.
+    kb_read_gather        (0444) kBytes read to fill write packets.
+
+    reset                 (0200) Write any value to it to reset
+                                 pktcdvd device statistic values, like
+                                 bytes read/written.
+
+/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/
+    size                  (0444) Contains the size of the bio write
+                                 queue.
+
+    congestion_off        (0644) If bio write queue size is below
+                                 this mark, accept new bio requests
+                                 from the block layer.
+
+    congestion_on         (0644) If bio write queue size is higher
+                                 as this mark, do no longer accept
+                                 bio write requests from the block
+                                 layer and wait till the pktcdvd
+                                 device has processed enough bio's
+                                 so that bio write queue size is
+                                 below congestion off mark.
+                                 A value of <= 0 disables congestion
+                                 control.
+
+
+Example:
+--------
+To use the pktcdvd sysfs interface directly, you can do:
+
+# create a new pktcdvd device mapped to /dev/hdc
+echo "22:0" >/sys/class/pktcdvd/add
+cat /sys/class/pktcdvd/device_map
+# assuming device pktcdvd0 was created, look at stat's
+cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written
+# print the device id of the mapped block device
+fgrep pktcdvd0 /sys/class/pktcdvd/device_map
+# remove device, using pktcdvd0 device id   253:0
+echo "253:0" >/sys/class/pktcdvd/remove
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index d882f8093871..dcff4d0623ad 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -21,7 +21,7 @@ Description:
                 these states.
 
 What:           /sys/power/disk
-Date:           August 2006
+Date:           September 2006
 Contact:        Rafael J. Wysocki <rjw@sisk.pl>
 Description:
                 The /sys/power/disk file controls the operating mode of the
@@ -39,6 +39,19 @@ Description:
                 'reboot' - the memory image will be saved by the kernel and
                 the system will be rebooted.
 
+                Additionally, /sys/power/disk can be used to turn on one of the
+                two testing modes of the suspend-to-disk mechanism: 'testproc'
+                or 'test'.  If the suspend-to-disk mechanism is in the
+                'testproc' mode, writing 'disk' to /sys/power/state will cause
+                the kernel to disable nonboot CPUs and freeze tasks, wait for 5
+                seconds, unfreeze tasks and enable nonboot CPUs.  If it is in
+                the 'test' mode, writing 'disk' to /sys/power/state will cause
+                the kernel to disable nonboot CPUs and freeze tasks, shrink
+                memory, suspend devices, wait for 5 seconds, resume devices,
+                unfreeze tasks and enable nonboot CPUs.  Then, we are able to
+                look in the log messages and work out, for example, which code
+                is being slow and which device drivers are misbehaving.
+
                 The suspend-to-disk method may be chosen by writing to this
                 file one of the accepted strings:
 
@@ -46,6 +59,8 @@ Description:
                 'platform'
                 'shutdown'
                 'reboot'
+                'testproc'
+                'test'
 
                 It will only change to 'firmware' or 'platform' if the system
                 supports that.
diff --git a/Documentation/Changes b/Documentation/Changes
index abee7f58c1ed..73a8617f1861 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -201,7 +201,7 @@ udev
 ----
 udev is a userspace application for populating /dev dynamically with
 only entries for devices actually present.  udev replaces the basic
-functionality of devfs, while allowing persistant device naming for
+functionality of devfs, while allowing persistent device naming for
 devices.
 
 FUSE
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 29c18966b050..0ad6dcb5d45f 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -35,12 +35,37 @@ In short, 8-char indents make things easier to read, and have the added
 benefit of warning you when you're nesting your functions too deep.
 Heed that warning.
 
+The preferred way to ease multiple indentation levels in a switch statement is
+to align the "switch" and its subordinate "case" labels in the same column
+instead of "double-indenting" the "case" labels.  E.g.:
+
+        switch (suffix) {
+        case 'G':
+        case 'g':
+                mem <<= 30;
+                break;
+        case 'M':
+        case 'm':
+                mem <<= 20;
+                break;
+        case 'K':
+        case 'k':
+                mem <<= 10;
+                /* fall through */
+        default:
+                break;
+        }
+
+
 Don't put multiple statements on a single line unless you have
 something to hide:
 
         if (condition) do_this;
           do_something_everytime;
 
+Don't put multiple assignments on a single line either.  Kernel coding style
+is super simple.  Avoid tricky expressions.
+
 Outside of comments, documentation and except in Kconfig, spaces are never
 used for indentation, and the above example is deliberately broken.
 
@@ -69,7 +94,7 @@ void fun(int a, int b, int c)
                 next_statement;
 }
 
-                Chapter 3: Placing Braces
+                Chapter 3: Placing Braces and Spaces
 
 The other issue that always comes up in C styling is the placement of
 braces.  Unlike the indent size, there are few technical reasons to
@@ -81,6 +106,20 @@ brace last on the line, and put the closing brace first, thusly:
                 we do y
         }
 
+This applies to all non-function statement blocks (if, switch, for,
+while, do).  E.g.:
+
+        switch (action) {
+        case KOBJ_ADD:
+                return "add";
+        case KOBJ_REMOVE:
+                return "remove";
+        case KOBJ_CHANGE:
+                return "change";
+        default:
+                return NULL;
+        }
+
 However, there is one special case, namely functions: they have the
 opening brace at the beginning of the next line, thus:
 
@@ -121,6 +160,49 @@ supply of new-lines on your screen is not a renewable resource (think
 25-line terminal screens here), you have more empty lines to put
 comments on.
 
+                3.1:  Spaces
+
+Linux kernel style for use of spaces depends (mostly) on
+function-versus-keyword usage.  Use a space after (most) keywords.  The
+notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
+somewhat like functions (and are usually used with parentheses in Linux,
+although they are not required in the language, as in: "sizeof info" after
+"struct fileinfo info;" is declared).
+
+So use a space after these keywords:
+        if, switch, case, for, do, while
+but not with sizeof, typeof, alignof, or __attribute__.  E.g.,
+        s = sizeof(struct file);
+
+Do not add spaces around (inside) parenthesized expressions.  This example is
+*bad*:
+
+        s = sizeof( struct file );
+
+When declaring pointer data or a function that returns a pointer type, the
+preferred use of '*' is adjacent to the data name or function name and not
+adjacent to the type name.  Examples:
+
+        char *linux_banner;
+        unsigned long long memparse(char *ptr, char **retptr);
+        char *match_strdup(substring_t *s);
+
+Use one space around (on each side of) most binary and ternary operators,
+such as any of these:
+
+        =  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
+
+but no space after unary operators:
+        &  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined
+
+no space before the postfix increment & decrement unary operators:
+        ++  --
+
+no space after the prefix increment & decrement unary operators:
+        ++  --
+
+and no space around the '.' and "->" structure member operators.
+
 
                 Chapter 4: Naming
 
@@ -152,7 +234,7 @@ variable that is used to hold a temporary value.
 
 If you are afraid to mix up your local variable names, you have another
 problem, which is called the function-growth-hormone-imbalance syndrome.
-See next chapter.
+See chapter 6 (Functions).
 
 
                 Chapter 5: Typedefs
@@ -258,6 +340,20 @@ generally easily keep track of about 7 different things, anything more
 and it gets confused.  You know you're brilliant, but maybe you'd like
 to understand what you did 2 weeks from now.
 
+In source files, separate functions with one blank line.  If the function is
+exported, the EXPORT* macro for it should follow immediately after the closing
+function brace line.  E.g.:
+
+int system_is_up(void)
+{
+        return system_state == SYSTEM_RUNNING;
+}
+EXPORT_SYMBOL(system_is_up);
+
+In function prototypes, include parameter names with their data types.
+Although this is not required by the C language, it is preferred in Linux
+because it is a simple way to add valuable information for the reader.
+
 
                 Chapter 7: Centralized exiting of functions
 
@@ -306,16 +402,36 @@ time to explain badly written code.
 Generally, you want your comments to tell WHAT your code does, not HOW.
 Also, try to avoid putting comments inside a function body: if the
 function is so complex that you need to separately comment parts of it,
-you should probably go back to chapter 5 for a while.  You can make
+you should probably go back to chapter 6 for a while.  You can make
 small comments to note or warn about something particularly clever (or
 ugly), but try to avoid excess.  Instead, put the comments at the head
 of the function, telling people what it does, and possibly WHY it does
 it.
 
-When commenting the kernel API functions, please use the kerneldoc format.
+When commenting the kernel API functions, please use the kernel-doc format.
 See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
 for details.
 
+Linux style for comments is the C89 "/* ... */" style.
+Don't use C99-style "// ..." comments.
+
+The preferred style for long (multi-line) comments is:
+
+        /*
+         * This is the preferred style for multi-line
+         * comments in the Linux kernel source code.
+         * Please use it consistently.
+         *
+         * Description:  A column of asterisks on the left side,
+         * with beginning and ending almost-blank lines.
+         */
+
+It's also important to comment data, whether they are basic types or derived
+types.  To this end, use just one data declaration per line (no commas for
+multiple data declarations).  This leaves you room for a small comment on each
+item, explaining its use.
+
+
                 Chapter 9: You've made a mess of it
 
 That's OK, we all do.  You've probably been told by your long-time Unix
@@ -591,4 +707,4 @@ Kernel CodingStyle, by greg@kroah.com at OLS 2002:
 http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
 
 --
-Last updated on 30 April 2006.
+Last updated on 2006-December-06.
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 2ffb0d62f0fe..805db4b2cba6 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -77,7 +77,7 @@ To get this part of the dma_ API, you must #include <linux/dmapool.h>
 Many drivers need lots of small dma-coherent memory regions for DMA
 descriptors or I/O buffers.  Rather than allocating in units of a page
 or more using dma_alloc_coherent(), you can use DMA pools.  These work
-much like a kmem_cache_t, except that they use the dma-coherent allocator
+much like a struct kmem_cache, except that they use the dma-coherent allocator
 not __get_free_pages().  Also, they understand common hardware constraints
 for alignment, like queue heads needing to be aligned on N byte boundaries.
 
@@ -94,7 +94,7 @@ The pool create() routines initialize a pool of dma-coherent buffers
 for use with a given device.  It must be called in a context which
 can sleep.
 
-The "name" is for diagnostics (like a kmem_cache_t name); dev and size
+The "name" is for diagnostics (like a struct kmem_cache name); dev and size
 are like what you'd pass to dma_alloc_coherent().  The device's hardware
 alignment requirement for this type of data is "align" (which is expressed
 in bytes, and must be a power of two).  If your device has no boundary
@@ -431,10 +431,10 @@ be identical to those passed in (and returned by
 dma_alloc_noncoherent()).
 
 int
-dma_is_consistent(dma_addr_t dma_handle)
+dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
 
-returns true if the memory pointed to by the dma_handle is actually
-consistent.
+returns true if the device dev is performing consistent DMA on the memory
+area pointed to by the dma_handle.
 
 int
 dma_get_cache_alignment(void)
@@ -459,7 +459,7 @@ anything like this.  You must also be extra careful about accessing
 memory you intend to sync partially.
 
 void
-dma_cache_sync(void *vaddr, size_t size,
+dma_cache_sync(struct device *dev, void *vaddr, size_t size,
                enum dma_data_direction direction)
 
 Do a partial sync of memory that was allocated by
@@ -489,7 +489,7 @@ size is the size of the area (must be multiples of PAGE_SIZE).
 flags can be or'd together and are
 
 DMA_MEMORY_MAP - request that the memory returned from
-dma_alloc_coherent() be directly writeable.
+dma_alloc_coherent() be directly writable.
 
 DMA_MEMORY_IO - request that the memory returned from
 dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt
index 705f6be92bdb..e767805b4182 100644
--- a/Documentation/DMA-ISA-LPC.txt
+++ b/Documentation/DMA-ISA-LPC.txt
@@ -110,7 +110,7 @@ lock.
 
 Once the DMA transfer is finished (or timed out) you should disable
 the channel again. You should also check get_dma_residue() to make
-sure that all data has been transfered.
+sure that all data has been transferred.
 
 Example:
 
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 66e1cf733571..36526a1e76d7 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -9,7 +9,7 @@
 DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
             kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
             procfs-guide.xml writing_usb_driver.xml \
-            kernel-api.xml journal-api.xml lsm.xml usb.xml \
+            kernel-api.xml filesystems.xml lsm.xml usb.xml \
             gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
             genericirq.xml
 
@@ -190,9 +190,13 @@ quiet_cmd_fig2png = FIG2PNG $@
 ###
 # Help targets as used by the top-level makefile
 dochelp:
-        @echo  '  Linux kernel internal documentation in different formats:'
-        @echo  '  xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)'
-        @echo  '  htmldocs (HTML), mandocs (man pages, use installmandocs to install)'
+        @echo  ' Linux kernel internal documentation in different formats:'
+        @echo  '  htmldocs        - HTML'
+        @echo  '  installmandocs  - install man pages generated by mandocs'
+        @echo  '  mandocs         - man pages'
+        @echo  '  pdfdocs         - PDF'
+        @echo  '  psdocs          - Postscript'
+        @echo  '  xmldocs         - XML DocBook'
 
 ###
 # Temporary files left by various tools
diff --git a/Documentation/DocBook/journal-api.tmpl b/Documentation/DocBook/filesystems.tmpl
index 2077f9a28c19..39fa2aba7f9b 100644
--- a/Documentation/DocBook/journal-api.tmpl
+++ b/Documentation/DocBook/filesystems.tmpl
@@ -2,39 +2,11 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
         "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
 
-<book id="LinuxJBDAPI">
+<book id="Linux-filesystems-API">
  <bookinfo>
-  <title>The Linux Journalling API</title>
-  <authorgroup>
-  <author>
-     <firstname>Roger</firstname>
-     <surname>Gammans</surname>
-     <affiliation>
-     <address>
-      <email>rgammans@computer-surgery.co.uk</email>
-     </address>
-    </affiliation>
-     </author> 
-  </authorgroup>
-  
-  <authorgroup>
-   <author>
-    <firstname>Stephen</firstname>
-    <surname>Tweedie</surname>
-    <affiliation>
-     <address>
-      <email>sct@redhat.com</email>
-     </address>
-    </affiliation>
-   </author>
-  </authorgroup>
+  <title>Linux Filesystems API</title>
 
-  <copyright>
-   <year>2002</year>
-   <holder>Roger Gammans</holder>
-  </copyright>
-
-<legalnotice>
+  <legalnotice>
    <para>
      This documentation is free software; you can redistribute
      it and/or modify it under the terms of the GNU General Public
@@ -42,21 +14,21 @@
      version 2 of the License, or (at your option) any later
      version.
    </para>
-      
+
    <para>
      This program is distributed in the hope that it will be
      useful, but WITHOUT ANY WARRANTY; without even the implied
      warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      See the GNU General Public License for more details.
    </para>
-      
+
    <para>
      You should have received a copy of the GNU General Public
      License along with this program; if not, write to the Free
      Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
      MA 02111-1307 USA
    </para>
-      
+
    <para>
      For more details see the file COPYING in the source
      distribution of Linux.
@@ -66,17 +38,113 @@
 
 <toc></toc>
 
-  <chapter id="Overview">
+  <chapter id="vfs">
+     <title>The Linux VFS</title>
+     <sect1><title>The Filesystem types</title>
+!Iinclude/linux/fs.h
+     </sect1>
+     <sect1><title>The Directory Cache</title>
+!Efs/dcache.c
+!Iinclude/linux/dcache.h
+     </sect1>
+     <sect1><title>Inode Handling</title>
+!Efs/inode.c
+!Efs/bad_inode.c
+     </sect1>
+     <sect1><title>Registration and Superblocks</title>
+!Efs/super.c
+     </sect1>
+     <sect1><title>File Locks</title>
+!Efs/locks.c
+!Ifs/locks.c
+     </sect1>
+     <sect1><title>Other Functions</title>
+!Efs/mpage.c
+!Efs/namei.c
+!Efs/buffer.c
+!Efs/bio.c
+!Efs/seq_file.c
+!Efs/filesystems.c
+!Efs/fs-writeback.c
+!Efs/block_dev.c
+     </sect1>
+  </chapter>
+
+  <chapter id="proc">
+     <title>The proc filesystem</title>
+
+     <sect1><title>sysctl interface</title>
+!Ekernel/sysctl.c
+     </sect1>
+
+     <sect1><title>proc filesystem interface</title>
+!Ifs/proc/base.c
+     </sect1>
+  </chapter>
+
+  <chapter id="sysfs">
+     <title>The Filesystem for Exporting Kernel Objects</title>
+!Efs/sysfs/file.c
+!Efs/sysfs/symlink.c
+!Efs/sysfs/bin.c
+  </chapter>
+
+  <chapter id="debugfs">
+     <title>The debugfs filesystem</title>
+
+     <sect1><title>debugfs interface</title>
+!Efs/debugfs/inode.c
+!Efs/debugfs/file.c
+     </sect1>
+  </chapter>
+
+  <chapter id="LinuxJDBAPI">
+  <chapterinfo>
+  <title>The Linux Journalling API</title>
+
+  <authorgroup>
+  <author>
+     <firstname>Roger</firstname>
+     <surname>Gammans</surname>
+     <affiliation>
+     <address>
+      <email>rgammans@computer-surgery.co.uk</email>
+     </address>
+    </affiliation>
+     </author>
+  </authorgroup>
+
+  <authorgroup>
+   <author>
+    <firstname>Stephen</firstname>
+    <surname>Tweedie</surname>
+    <affiliation>
+     <address>
+      <email>sct@redhat.com</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <copyright>
+   <year>2002</year>
+   <holder>Roger Gammans</holder>
+  </copyright>
+  </chapterinfo>
+
+  <title>The Linux Journalling API</title>
+
+    <sect1>
      <title>Overview</title>
-  <sect1>
+    <sect2>
      <title>Details</title>
 <para>
-The journalling layer is  easy to use. You need to 
+The journalling layer is  easy to use. You need to
 first of all create a journal_t data structure. There are
 two calls to do this dependent on how you decide to allocate the physical
-media on which the journal resides. The journal_init_inode() call 
+media on which the journal resides. The journal_init_inode() call
 is for journals stored in filesystem inodes, or the journal_init_dev()
-call can be use for journal stored on a raw device (in a continuous range 
+call can be use for journal stored on a raw device (in a continuous range
 of blocks). A journal_t is a typedef for a struct pointer, so when
 you are finally finished make sure you call journal_destroy() on it
 to free up any used kernel memory.
@@ -91,27 +159,26 @@ need to call journal_create().
 <para>
 Most of the time however your journal file will already have been created, but
 before you load it you must call journal_wipe() to empty the journal file.
-Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the 
+Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
 job of the client file system to detect this and skip the call to journal_wipe().
 </para>
 
 <para>
 In either case the next call should be to journal_load() which prepares the
-journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery() 
+journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
 for you if it detects any outstanding transactions in the journal and similarly
 journal_load() will call journal_recover() if necessary.
 I would advise reading fs/ext3/super.c for examples on this stage.
-[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly 
-complicate the API. Or isn't a good idea for the journal layer to hide 
+[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
+complicate the API. Or isn't a good idea for the journal layer to hide
 dirty mounts from the client fs]
 </para>
 
 <para>
-Now you can go ahead and start modifying the underlying 
+Now you can go ahead and start modifying the underlying
 filesystem. Almost.
 </para>
 
-
 <para>
 
 You still need to actually journal your filesystem changes, this
@@ -138,10 +205,10 @@ individual buffers (blocks). Before you start to modify a buffer you
 need to call journal_get_{create,write,undo}_access() as appropriate,
 this allows the journalling layer to copy the unmodified data if it
 needs to. After all the buffer may be part of a previously uncommitted
-transaction. 
+transaction.
 At this point you are at last ready to modify a buffer, and once
 you are have done so you need to call journal_dirty_{meta,}data().
-Or if you've asked for access to a buffer you now know is now longer 
+Or if you've asked for access to a buffer you now know is now longer
 required to be pushed back on the device you can call journal_forget()
 in much the same way as you might have used bforget() in the past.
 </para>
@@ -156,7 +223,6 @@ Then at umount time , in your put_super() (2.4) or write_super() (2.5)
 you can then call journal_destroy() to clean up your in-core journal object.
 </para>
 
-
 <para>
 Unfortunately there a couple of ways the journal layer can cause a deadlock.
 The first thing to note is that each task can only have
@@ -164,19 +230,19 @@ a single outstanding transaction at any one time, remember nothing
 commits until the outermost journal_stop(). This means
 you must complete the transaction at the end of each file/inode/address
 etc. operation you perform, so that the journalling system isn't re-entered
-on another journal. Since transactions can't be nested/batched 
+on another journal. Since transactions can't be nested/batched
 across differing journals, and another filesystem other than
 yours (say ext3) may be modified in a later syscall.
 </para>
 
 <para>
-The second case to bear in mind is that journal_start() can 
-block if there isn't enough space in the journal for your transaction 
+The second case to bear in mind is that journal_start() can
+block if there isn't enough space in the journal for your transaction
 (based on the passed nblocks param) - when it blocks it merely(!) needs to
-wait for transactions to complete and be committed from other tasks, 
-so essentially we are waiting for journal_stop(). So to avoid 
+wait for transactions to complete and be committed from other tasks,
+so essentially we are waiting for journal_stop(). So to avoid
 deadlocks you must treat journal_start/stop() as if they
-were semaphores and include them in your semaphore ordering rules to prevent 
+were semaphores and include them in your semaphore ordering rules to prevent
 deadlocks. Note that journal_extend() has similar blocking behaviour to
 journal_start() so you can deadlock here just as easily as on journal_start().
 </para>
@@ -184,7 +250,7 @@ journal_start() so you can deadlock here just as easily as on journal_start().
 <para>
 Try to reserve the right number of blocks the first time. ;-). This will
 be the maximum number of blocks you are going to touch in this transaction.
-I advise having a look at at least ext3_jbd.h to see the basis on which 
+I advise having a look at at least ext3_jbd.h to see the basis on which
 ext3 uses to make these decisions.
 </para>
 
@@ -193,13 +259,13 @@ Another wriggle to watch out for is your on-disk block allocation strategy.
 why? Because, if you undo a delete, you need to ensure you haven't reused any
 of the freed blocks in a later transaction. One simple way of doing this
 is make sure any blocks you allocate only have checkpointed transactions
-listed against them. Ext3 does this in ext3_test_allocatable(). 
+listed against them. Ext3 does this in ext3_test_allocatable().
 </para>
 
 <para>
 Lock is also providing through journal_{un,}lock_updates(),
 ext3 uses this when it wants a window with a clean and stable fs for a moment.
-eg. 
+eg.
 </para>
 
 <programlisting>
@@ -230,19 +296,19 @@ extend it like this:-
                 struct journal_callback for_jbd;
                 // Stuff for myfs allocated together.
                 myfs_inode*    i_commited;
-        
+
         }
 </programlisting>
 
 <para>
-this would be useful if you needed to know when data was committed to a 
+this would be useful if you needed to know when data was committed to a
 particular inode.
 </para>
 
-</sect1>
+    </sect2>
 
-<sect1>
-<title>Summary</title>
+    <sect2>
+     <title>Summary</title>
 <para>
 Using the journal is a matter of wrapping the different context changes,
 being each mount, each modification (transaction) and each changed buffer
@@ -260,15 +326,15 @@ an example.
   if (clean) journal_wipe();
   journal_load();
 
-   foreach(transaction) { /*transactions must be 
+   foreach(transaction) { /*transactions must be
                             completed before
-                            a syscall returns to 
+                            a syscall returns to
                             userspace*/
 
           handle_t * xct=journal_start(my_jnrl);
           foreach(bh) {
                 journal_get_{create,write,undo}_access(xact,bh);
-                if ( myfs_modify(bh) ) { /* returns true 
+                if ( myfs_modify(bh) ) { /* returns true
                                         if makes changes */
                            journal_dirty_{meta,}data(xact,bh);
                 } else {
@@ -279,55 +345,57 @@ an example.
    }
    journal_destroy(my_jrnl);
 </programlisting>
-</sect1>
+    </sect2>
 
-</chapter>
+    </sect1>
 
-  <chapter id="adt">
+    <sect1>
      <title>Data Types</title>
-     <para>     
+     <para>
         The journalling layer uses typedefs to 'hide' the concrete definitions
         of the structures used. As a client of the JBD layer you can
         just rely on the using the pointer as a magic cookie  of some sort.
-        
+
         Obviously the hiding is not enforced as this is 'C'.
-        </para>
-        <sect1><title>Structures</title>
+     </para>
+        <sect2><title>Structures</title>
 !Iinclude/linux/jbd.h
-        </sect1>
-</chapter>
+        </sect2>
+    </sect1>
 
-  <chapter id="calls">
+    <sect1>
      <title>Functions</title>
-     <para>     
+     <para>
         The functions here are split into two groups those that
         affect a journal as a whole, and those which are used to
         manage transactions
-</para>
-        <sect1><title>Journal Level</title>
+     </para>
+        <sect2><title>Journal Level</title>
 !Efs/jbd/journal.c
 !Ifs/jbd/recovery.c
-        </sect1>
-        <sect1><title>Transasction Level</title>
-!Efs/jbd/transaction.c  
-        </sect1>
-</chapter>
-<chapter>
+        </sect2>
+        <sect2><title>Transasction Level</title>
+!Efs/jbd/transaction.c
+        </sect2>
+    </sect1>
+    <sect1>
      <title>See also</title>
         <para>
-        <citation>
+          <citation>
            <ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
-                Journaling the Linux ext2fs Filesystem,LinuxExpo 98, Stephen Tweedie
+                Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie
            </ulink>
-           </citation>
-           </para>
-           <para>
+          </citation>
+        </para>
+        <para>
            <citation>
            <ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">
-                Ext3 Journalling FileSystem , OLS 2000, Dr. Stephen Tweedie
+                Ext3 Journalling FileSystem, OLS 2000, Dr. Stephen Tweedie
            </ulink>
            </citation>
-           </para>
-</chapter>
+        </para>
+    </sect1>
+
+  </chapter>
 
 </book>
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 2b5ac604948c..3fa0c4b4541e 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -182,66 +182,6 @@ X!Ilib/string.c
      </sect1>
   </chapter>
 
-  <chapter id="vfs">
-     <title>The Linux VFS</title>
-     <sect1><title>The Filesystem types</title>
-!Iinclude/linux/fs.h
-     </sect1>
-     <sect1><title>The Directory Cache</title>
-!Efs/dcache.c
-!Iinclude/linux/dcache.h
-     </sect1>
-     <sect1><title>Inode Handling</title>
-!Efs/inode.c
-!Efs/bad_inode.c
-     </sect1>
-     <sect1><title>Registration and Superblocks</title>
-!Efs/super.c
-     </sect1>
-     <sect1><title>File Locks</title>
-!Efs/locks.c
-!Ifs/locks.c
-     </sect1>
-     <sect1><title>Other Functions</title>
-!Efs/mpage.c
-!Efs/namei.c
-!Efs/buffer.c
-!Efs/bio.c
-!Efs/seq_file.c
-!Efs/filesystems.c
-!Efs/fs-writeback.c
-!Efs/block_dev.c
-     </sect1>
-  </chapter>
-
-  <chapter id="proc">
-     <title>The proc filesystem</title>
- 
-     <sect1><title>sysctl interface</title>
-!Ekernel/sysctl.c
-     </sect1>
-
-     <sect1><title>proc filesystem interface</title>
-!Ifs/proc/base.c
-     </sect1>
-  </chapter>
-
-  <chapter id="sysfs">
-     <title>The Filesystem for Exporting Kernel Objects</title>
-!Efs/sysfs/file.c
-!Efs/sysfs/symlink.c
-!Efs/sysfs/bin.c
-  </chapter>
-
-  <chapter id="debugfs">
-     <title>The debugfs filesystem</title>
- 
-     <sect1><title>debugfs interface</title>
-!Efs/debugfs/inode.c
-!Efs/debugfs/file.c
-     </sect1>
-  </chapter>
-
   <chapter id="relayfs">
      <title>relay interface support</title>
 
@@ -478,9 +418,35 @@ X!Edrivers/pnp/system.c
 !Idrivers/parport/daisy.c
   </chapter>
 
-  <chapter id="viddev">
-     <title>Video4Linux</title>
-!Edrivers/media/video/videodev.c
+  <chapter id="message_devices">
+        <title>Message-based devices</title>
+     <sect1><title>Fusion message devices</title>
+!Edrivers/message/fusion/mptbase.c
+!Idrivers/message/fusion/mptbase.c
+!Edrivers/message/fusion/mptscsih.c
+!Idrivers/message/fusion/mptscsih.c
+!Idrivers/message/fusion/mptctl.c
+!Idrivers/message/fusion/mptspi.c
+!Idrivers/message/fusion/mptfc.c
+!Idrivers/message/fusion/mptlan.c
+     </sect1>
+     <sect1><title>I2O message devices</title>
+!Iinclude/linux/i2o.h
+!Idrivers/message/i2o/core.h
+!Edrivers/message/i2o/iop.c
+!Idrivers/message/i2o/iop.c
+!Idrivers/message/i2o/config-osm.c
+!Edrivers/message/i2o/exec-osm.c
+!Idrivers/message/i2o/exec-osm.c
+!Idrivers/message/i2o/bus-osm.c
+!Edrivers/message/i2o/device.c
+!Idrivers/message/i2o/device.c
+!Idrivers/message/i2o/driver.c
+!Idrivers/message/i2o/pci.c
+!Idrivers/message/i2o/i2o_block.c
+!Idrivers/message/i2o/i2o_scsi.c
+!Idrivers/message/i2o/i2o_proc.c
+     </sect1>
   </chapter>
 
   <chapter id="snddev">
@@ -593,4 +559,12 @@ X!Idrivers/video/console/fonts.c
 -->
      </sect1>
   </chapter>
+
+  <chapter id="input_subsystem">
+     <title>Input Subsystem</title>
+!Iinclude/linux/input.h
+!Edrivers/input/input.c
+!Edrivers/input/ff-core.c
+!Edrivers/input/ff-memless.c
+  </chapter>
 </book>
diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index 07cd34c1940b..d4188d4ff535 100644
--- a/Documentation/DocBook/writing_usb_driver.tmpl
+++ b/Documentation/DocBook/writing_usb_driver.tmpl
@@ -345,8 +345,7 @@ static inline void skel_delete (struct usb_skel *dev)
         usb_buffer_free (dev->udev, dev->bulk_out_size,
             dev->bulk_out_buffer,
             dev->write_urb->transfer_dma);
-    if (dev->write_urb != NULL)
-        usb_free_urb (dev->write_urb);
+    usb_free_urb (dev->write_urb);
     kfree (dev);
 }
   </programlisting>
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index d6f3dd1a3464..8d51c148f721 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -395,6 +395,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here)
 
 
 
+Managing bug reports
+--------------------
+
+One of the best ways to put into practice your hacking skills is by fixing
+bugs reported by other people. Not only you will help to make the kernel
+more stable, you'll learn to fix real world problems and you will improve
+your skills, and other developers will be aware of your presence. Fixing
+bugs is one of the best ways to get merits among other developers, because
+not many people like wasting time fixing other people's bugs.
+
+To work in the already reported bug reports, go to http://bugzilla.kernel.org.
+If you want to be advised of the future bug reports, you can subscribe to the
+bugme-new mailing list (only new bug reports are mailed here) or to the
+bugme-janitor mailing list (every change in the bugzilla is mailed here)
+
+        http://lists.osdl.org/mailman/listinfo/bugme-new
+        http://lists.osdl.org/mailman/listinfo/bugme-janitors
+
+
+
 Mailing lists
 -------------
 
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt
index 0e3924ecd76b..24dc3fcf1594 100644
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -365,6 +365,7 @@ You can change this at module load time (for a module) with:
        regshifts=<shift1>,<shift2>,...
        slave_addrs=<addr1>,<addr2>,...
        force_kipmid=<enable1>,<enable2>,...
+       unload_when_empty=[0|1]
 
 Each of these except si_trydefaults is a list, the first item for the
 first interface, second item for the second interface, etc.
@@ -416,6 +417,11 @@ by the driver, but systems with broken interrupts might need an enable,
 or users that don't want the daemon (don't need the performance, don't
 want the CPU hit) can disable it.
 
+If unload_when_empty is set to 1, the driver will be unloaded if it
+doesn't find any interfaces or all the interfaces fail to work.  The
+default is one.  Setting to 0 is useful with the hotmod, but is
+obviously only useful for modules.
+
 When compiled into the kernel, the parameters can be specified on the
 kernel command line as:
 
@@ -441,6 +447,25 @@ have high-res timers enabled in the kernel and you don't have
 interrupts enabled, the driver will run VERY slowly.  Don't blame me,
 these interfaces suck.
 
+The driver supports a hot add and remove of interfaces.  This way,
+interfaces can be added or removed after the kernel is up and running.
+This is done using /sys/modules/ipmi_si/hotmod, which is a write-only
+parameter.  You write a string to this interface.  The string has the
+format:
+   <op1>[:op2[:op3...]]
+The "op"s are:
+   add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]
+You can specify more than one interface on the line.  The "opt"s are:
+   rsp=<regspacing>
+   rsi=<regsize>
+   rsh=<regshift>
+   irq=<irq>
+   ipmb=<ipmb slave addr>
+and these have the same meanings as discussed above.  Note that you
+can also use this on the kernel command line for a more compact format
+for specifying an interface.  Note that when removing an interface,
+only the first three parameters (si type, address type, and address)
+are used for the comparison.  Any options are ignored for removing.
 
 The SMBus Driver
 ----------------
@@ -502,7 +527,10 @@ used to control it:
 
   modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
       preaction=<preaction type> preop=<preop type> start_now=x
-      nowayout=x
+      nowayout=x ifnum_to_use=n
+
+ifnum_to_use specifies which interface the watchdog timer should use.
+The default is -1, which means to pick the first one registered.
 
 The timeout is the number of seconds to the action, and the pretimeout
 is the amount of seconds before the reset that the pre-timeout panic will
@@ -624,5 +652,9 @@ command line.  The parameter is also available via the proc filesystem
 in /proc/sys/dev/ipmi/poweroff_powercycle.  Note that if the system
 does not support power cycling, it will always do the power off.
 
+The "ifnum_to_use" parameter specifies which interface the poweroff
+code should use.  The default is -1, which means to pick the first one
+registered.
+
 Note that if you have ACPI enabled, the system will prefer using ACPI to
 power off.
diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt
index c70306abb7b2..d389388c733e 100644
--- a/Documentation/MSI-HOWTO.txt
+++ b/Documentation/MSI-HOWTO.txt
@@ -219,7 +219,7 @@ into the field vector of each element contained in a second argument.
 Note that the pre-assigned IOAPIC dev->irq is valid only if the device
 operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
 using dev->irq by the device driver to request for interrupt service
-may result unpredictabe behavior.
+may result in unpredictable behavior.
 
 For each MSI-X vector granted, a device driver is responsible for calling
 other functions like request_irq(), enable_irq(), etc. to enable
@@ -470,7 +470,68 @@ LOC:     324553     325068
 ERR:          0
 MIS:          0
 
-6. FAQ
+6. MSI quirks
+
+Several PCI chipsets or devices are known to not support MSI.
+The PCI stack provides 3 possible levels of MSI disabling:
+* on a single device
+* on all devices behind a specific bridge
+* globally
+
+6.1. Disabling MSI on a single device
+
+Under some circumstances, it might be required to disable MSI on a
+single device, It may be achived by either not calling pci_enable_msi()
+or all, or setting the pci_dev->no_msi flag before (most of the time
+in a quirk).
+
+6.2. Disabling MSI below a bridge
+
+The vast majority of MSI quirks are required by PCI bridges not
+being able to route MSI between busses. In this case, MSI have to be
+disabled on all devices behind this bridge. It is achieves by setting
+the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
+subordinate bus. There is no need to set the same flag on bridges that
+are below the broken brigde. When pci_enable_msi() is called to enable
+MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
+flag in all parent busses of the device.
+
+Some bridges actually support dynamic MSI support enabling/disabling
+by changing some bits in their PCI configuration space (especially
+the Hypertransport chipsets such as the nVidia nForce and Serverworks
+HT2000). It may then be required to update the NO_MSI flag on the
+corresponding devices in the sysfs hierarchy. To enable MSI support
+on device "0000:00:0e", do:
+
+        echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus
+
+To disable MSI support, echo 0 instead of 1. Note that it should be
+used with caution since changing this value might break interrupts.
+
+6.3. Disabling MSI globally
+
+Some extreme cases may require to disable MSI globally on the system.
+For now, the only known case is a Serverworks PCI-X chipsets (MSI are
+not supported on several busses that are not all connected to the
+chipset in the Linux PCI hierarchy). In the vast majority of other
+cases, disabling only behind a specific bridge is enough.
+
+For debugging purpose, the user may also pass pci=nomsi on the kernel
+command-line to explicitly disable MSI globally. But, once the appro-
+priate quirks are added to the kernel, this option should not be
+required anymore.
+
+6.4. Finding why MSI cannot be enabled on a device
+
+Assuming that MSI are not enabled on a device, you should look at
+dmesg to find messages that quirks may output when disabling MSI
+on some devices, some bridges or even globally.
+Then, lspci -t gives the list of bridges above a device. Reading
+/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
+are enabled (1) or disabled (0). In 0 is found in a single bridge
+msi_bus file above the device, MSI cannot be enabled.
+
+7. FAQ
 
 Q1. Are there any limitations on using the MSI?
 
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index 7ac61f60037a..2270efa10153 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -66,3 +66,9 @@ kernel patches.
     See Documentation/ABI/README for more information.
 
 20: Check that it all passes `make headers_check'.
+
+21: Has been checked with injection of at least slab and page-allocation
+    fauilures.  See Documentation/fault-injection/.
+
+    If the new code is substantial, addition of subsystem-specific fault
+    injection might be appropriate.
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index b11792abd6b6..e9126e794ed7 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -7,6 +7,8 @@
  * Copyright (C) Balbir Singh, IBM Corp. 2006
  * Copyright (c) Jay Lan, SGI. 2006
  *
+ * Compile with
+ *      gcc -I/usr/src/linux/include getdelays.c -o getdelays
  */
 
 #include <stdio.h>
@@ -35,13 +37,20 @@
 #define NLA_DATA(na)            ((void *)((char*)(na) + NLA_HDRLEN))
 #define NLA_PAYLOAD(len)        (len - NLA_HDRLEN)
 
-#define err(code, fmt, arg...) do { printf(fmt, ##arg); exit(code); } while (0)
-int done = 0;
-int rcvbufsz=0;
-
-    char name[100];
-int dbg=0, print_delays=0;
+#define err(code, fmt, arg...)                  \
+        do {                                    \
+                fprintf(stderr, fmt, ##arg);    \
+                exit(code);                     \
+        } while (0)
+
+int done;
+int rcvbufsz;
+char name[100];
+int dbg;
+int print_delays;
+int print_io_accounting;
 __u64 stime, utime;
+
 #define PRINTF(fmt, arg...) {                   \
             if (dbg) {                          \
                 printf(fmt, ##arg);             \
@@ -49,7 +58,7 @@ __u64 stime, utime;
         }
 
 /* Maximum size of response requested or message sent */
-#define MAX_MSG_SIZE    256
+#define MAX_MSG_SIZE    1024
 /* Maximum number of cpus expected to be specified in a cpumask */
 #define MAX_CPUS        32
 /* Maximum length of pathname to log file */
@@ -78,8 +87,9 @@ static int create_nl_socket(int protocol)
         if (rcvbufsz)
                 if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
                                 &rcvbufsz, sizeof(rcvbufsz)) < 0) {
-                        printf("Unable to set socket rcv buf size to %d\n",
-                               rcvbufsz);
+                        fprintf(stderr, "Unable to set socket rcv buf size "
+                                        "to %d\n",
+                                rcvbufsz);
                         return -1;
                 }
 
@@ -186,6 +196,15 @@ void print_delayacct(struct taskstats *t)
                "count", "delay total", t->swapin_count, t->swapin_delay_total);
 }
 
+void print_ioacct(struct taskstats *t)
+{
+        printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
+                t->ac_comm,
+                (unsigned long long)t->read_bytes,
+                (unsigned long long)t->write_bytes,
+                (unsigned long long)t->cancelled_write_bytes);
+}
+
 int main(int argc, char *argv[])
 {
         int c, rc, rep_len, aggr_len, len2, cmd_type;
@@ -208,7 +227,7 @@ int main(int argc, char *argv[])
         struct msgtemplate msg;
 
         while (1) {
-                c = getopt(argc, argv, "dw:r:m:t:p:v:l");
+                c = getopt(argc, argv, "diw:r:m:t:p:v:l");
                 if (c < 0)
                         break;
 
@@ -217,6 +236,10 @@ int main(int argc, char *argv[])
                         printf("print delayacct stats ON\n");
                         print_delays = 1;
                         break;
+                case 'i':
+                        printf("printing IO accounting\n");
+                        print_io_accounting = 1;
+                        break;
                 case 'w':
                         strncpy(logfile, optarg, MAX_FILENAME);
                         printf("write to file %s\n", logfile);
@@ -238,14 +261,12 @@ int main(int argc, char *argv[])
                         if (!tid)
                                 err(1, "Invalid tgid\n");
                         cmd_type = TASKSTATS_CMD_ATTR_TGID;
-                        print_delays = 1;
                         break;
                 case 'p':
                         tid = atoi(optarg);
                         if (!tid)
                                 err(1, "Invalid pid\n");
                         cmd_type = TASKSTATS_CMD_ATTR_PID;
-                        print_delays = 1;
                         break;
                 case 'v':
                         printf("debug on\n");
@@ -277,7 +298,7 @@ int main(int argc, char *argv[])
         mypid = getpid();
         id = get_family_id(nl_sd);
         if (!id) {
-                printf("Error getting family id, errno %d", errno);
+                fprintf(stderr, "Error getting family id, errno %d\n", errno);
                 goto err;
         }
         PRINTF("family id %d\n", id);
@@ -288,7 +309,7 @@ int main(int argc, char *argv[])
                               &cpumask, strlen(cpumask) + 1);
                 PRINTF("Sent register cpumask, retval %d\n", rc);
                 if (rc < 0) {
-                        printf("error sending register cpumask\n");
+                        fprintf(stderr, "error sending register cpumask\n");
                         goto err;
                 }
         }
@@ -298,7 +319,7 @@ int main(int argc, char *argv[])
                               cmd_type, &tid, sizeof(__u32));
                 PRINTF("Sent pid/tgid, retval %d\n", rc);
                 if (rc < 0) {
-                        printf("error sending tid/tgid cmd\n");
+                        fprintf(stderr, "error sending tid/tgid cmd\n");
                         goto done;
                 }
         }
@@ -310,13 +331,15 @@ int main(int argc, char *argv[])
                 PRINTF("received %d bytes\n", rep_len);
 
                 if (rep_len < 0) {
-                        printf("nonfatal reply error: errno %d\n", errno);
+                        fprintf(stderr, "nonfatal reply error: errno %d\n",
+                                errno);
                         continue;
                 }
                 if (msg.n.nlmsg_type == NLMSG_ERROR ||
                     !NLMSG_OK((&msg.n), rep_len)) {
                         struct nlmsgerr *err = NLMSG_DATA(&msg);
-                        printf("fatal reply error,  errno %d\n", err->error);
+                        fprintf(stderr, "fatal reply error,  errno %d\n",
+                                err->error);
                         goto done;
                 }
 
@@ -356,6 +379,8 @@ int main(int argc, char *argv[])
                                                 count++;
                                                 if (print_delays)
                                                         print_delayacct((struct taskstats *) NLA_DATA(na));
+                                                if (print_io_accounting)
+                                                        print_ioacct((struct taskstats *) NLA_DATA(na));
                                                 if (fd) {
                                                         if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
                                                                 err(1,"write error\n");
@@ -365,7 +390,9 @@ int main(int argc, char *argv[])
                                                         goto done;
                                                 break;
                                         default:
-                                                printf("Unknown nested nla_type %d\n", na->nla_type);
+                                                fprintf(stderr, "Unknown nested"
+                                                        " nla_type %d\n",
+                                                        na->nla_type);
                                                 break;
                                         }
                                         len2 += NLA_ALIGN(na->nla_len);
@@ -374,7 +401,8 @@ int main(int argc, char *argv[])
                                 break;
 
                         default:
-                                printf("Unknown nla_type %d\n", na->nla_type);
+                                fprintf(stderr, "Unknown nla_type %d\n",
+                                        na->nla_type);
                                 break;
                         }
                         na = (struct nlattr *) (GENLMSG_DATA(&msg) + len);
diff --git a/Documentation/accounting/taskstats.txt b/Documentation/accounting/taskstats.txt
index 92ebf29e9041..ff06b738bb88 100644
--- a/Documentation/accounting/taskstats.txt
+++ b/Documentation/accounting/taskstats.txt
@@ -96,9 +96,9 @@ a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates
 a pid/tgid will be followed by some stats.
 
 b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
-is being returned.
+are being returned.
 
-c) TASKSTATS_TYPE_STATS: attribute with a struct taskstsats as payload. The
+c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
 same structure is used for both per-pid and per-tgid stats.
 
 3. New message sent by kernel whenever a task exits. The payload consists of a
@@ -122,12 +122,12 @@ of atomicity).
 
 However, maintaining per-process, in addition to per-task stats, within the
 kernel has space and time overheads. To address this, the taskstats code
-accumalates each exiting task's statistics into a process-wide data structure.
-When the last task of a process exits, the process level data accumalated also
+accumulates each exiting task's statistics into a process-wide data structure.
+When the last task of a process exits, the process level data accumulated also
 gets sent to userspace (along with the per-task data).
 
 When a user queries to get per-tgid data, the sum of all other live threads in
-the group is added up and added to the accumalated total for previously exited
+the group is added up and added to the accumulated total for previously exited
 threads of the same thread group.
 
 Extending taskstats
diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt
index e2a66f8143c5..a598fe10a297 100644
--- a/Documentation/block/as-iosched.txt
+++ b/Documentation/block/as-iosched.txt
@@ -24,8 +24,10 @@ very similar behavior to the deadline IO scheduler.
 Selecting IO schedulers
 -----------------------
 To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
-'noop' and 'as' (the default) are also available. IO schedulers are assigned
-globally at boot time only presently.
+'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
+assigned globally at boot time only presently. It's also possible to change
+the IO scheduler for a determined device on the fly, as described in
+Documentation/block/switching-sched.txt.
 
 
 Anticipatory IO scheduler Policies
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 34bf8f60d8f8..c6c9a9c10d7f 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -183,7 +183,7 @@ it, the pci dma mapping routines and associated data structures have now been
 modified to accomplish a direct page -> bus translation, without requiring
 a virtual address mapping (unlike the earlier scheme of virtual address
 -> bus translation). So this works uniformly for high-memory pages (which
-do not have a correponding kernel virtual address space mapping) and
+do not have a corresponding kernel virtual address space mapping) and
 low-memory pages.
 
 Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
@@ -391,7 +391,7 @@ forced such requests to be broken up into small chunks before being passed
 on to the generic block layer, only to be merged by the i/o scheduler
 when the underlying device was capable of handling the i/o in one shot.
 Also, using the buffer head as an i/o structure for i/os that didn't originate
-from the buffer cache unecessarily added to the weight of the descriptors
+from the buffer cache unnecessarily added to the weight of the descriptors
 which were generated for each such chunk.
 
 The following were some of the goals and expectations considered in the
@@ -403,14 +403,14 @@ i.  Should be appropriate as a descriptor for both raw and buffered i/o  -
     for raw i/o.
 ii. Ability to represent high-memory buffers (which do not have a virtual
     address mapping in kernel address space).
-iii.Ability to represent large i/os w/o unecessarily breaking them up (i.e
+iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e
     greater than PAGE_SIZE chunks in one shot)
 iv. At the same time, ability to retain independent identity of i/os from
     different sources or i/o units requiring individual completion (e.g. for
     latency reasons)
 v.  Ability to represent an i/o involving multiple physical memory segments
     (including non-page aligned page fragments, as specified via readv/writev)
-    without unecessarily breaking it up, if the underlying device is capable of
+    without unnecessarily breaking it up, if the underlying device is capable of
     handling it.
 vi. Preferably should be based on a memory descriptor structure that can be
     passed around different types of subsystems or layers, maybe even
@@ -1013,7 +1013,7 @@ Characteristics:
 i. Binary tree
 AS and deadline i/o schedulers use red black binary trees for disk position
 sorting and searching, and a fifo linked list for time-based searching. This
-gives good scalability and good availablility of information. Requests are
+gives good scalability and good availability of information. Requests are
 almost always dispatched in disk sort order, so a cache is kept of the next
 request in sort order to prevent binary tree lookups.
 
diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt
index 3d44c561fe6d..7715d2247c4d 100644
--- a/Documentation/cdrom/packet-writing.txt
+++ b/Documentation/cdrom/packet-writing.txt
@@ -90,6 +90,41 @@ Notes
   to create an ext2 filesystem on the disc.
 
 
+Using the pktcdvd sysfs interface
+---------------------------------
+
+Since Linux 2.6.19, the pktcdvd module has a sysfs interface
+and can be controlled by it. For example the "pktcdvd" tool uses
+this interface. (see http://people.freenet.de/BalaGi#pktcdvd )
+
+"pktcdvd" works similar to "pktsetup", e.g.:
+
+        # pktcdvd -a dev_name /dev/hdc
+        # mkudffs /dev/pktcdvd/dev_name
+        # mount -t udf -o rw,noatime /dev/pktcdvd/dev_name /dvdram
+        # cp files /dvdram
+        # umount /dvdram
+        # pktcdvd -r dev_name
+
+
+For a description of the sysfs interface look into the file:
+
+  Documentation/ABI/testing/sysfs-block-pktcdvd
+
+
+Using the pktcdvd debugfs interface
+-----------------------------------
+
+To read pktcdvd device infos in human readable form, do:
+
+        # cat /debug/pktcdvd/pktcdvd[0-7]/info
+
+For a description of the debugfs interface look into the file:
+
+  Documentation/ABI/testing/debugfs-pktcdvd
+
+
+
 Links
 -----
 
diff --git a/Documentation/cpu-freq/cpufreq-nforce2.txt b/Documentation/cpu-freq/cpufreq-nforce2.txt
index 9188337d8f6b..babce1315026 100644
--- a/Documentation/cpu-freq/cpufreq-nforce2.txt
+++ b/Documentation/cpu-freq/cpufreq-nforce2.txt
@@ -1,7 +1,7 @@
 
-The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms.
+The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
 
-This works better than on other plattforms, because the FSB of the CPU
+This works better than on other platforms, because the FSB of the CPU
 can be controlled independently from the PCI/AGP clock.
 
 The module has two options:
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index bc107cb157a8..cc60d29b954c 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -46,7 +46,7 @@ maxcpus=n    Restrict boot time cpus to n. Say if you have 4 cpus, using
              maxcpus=2 will only boot 2. You can choose to bring the
              other cpus later online, read FAQ's for more info.
 
-additional_cpus*=n      Use this to limit hotpluggable cpus. This option sets
+additional_cpus=n (*)   Use this to limit hotpluggable cpus. This option sets
                         cpu_possible_map = cpu_present_map + additional_cpus
 
 (*) Option valid only for following architectures
@@ -54,8 +54,8 @@ additional_cpus*=n	Use this to limit hotpluggable cpus. This option sets
 
 ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
 to determine the number of potentially hot-pluggable cpus. The implementation
-should only rely on this to count the #of cpus, but *MUST* not rely on the
-apicid values in those tables for disabled apics. In the event BIOS doesnt
+should only rely on this to count the # of cpus, but *MUST* not rely on the
+apicid values in those tables for disabled apics. In the event BIOS doesn't
 mark such hot-pluggable cpus as disabled entries, one could use this
 parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
 
@@ -101,15 +101,15 @@ cpu_possible_map/for_each_possible_cpu() to iterate.
 
 Never use anything other than cpumask_t to represent bitmap of CPUs.
 
-#include <linux/cpumask.h>
+        #include <linux/cpumask.h>
 
-for_each_possible_cpu     - Iterate over cpu_possible_map
-for_each_online_cpu       - Iterate over cpu_online_map
-for_each_present_cpu      - Iterate over cpu_present_map
-for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
+        for_each_possible_cpu     - Iterate over cpu_possible_map
+        for_each_online_cpu       - Iterate over cpu_online_map
+        for_each_present_cpu      - Iterate over cpu_present_map
+        for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
 
-#include <linux/cpu.h>
-lock_cpu_hotplug() and unlock_cpu_hotplug():
+        #include <linux/cpu.h>
+        lock_cpu_hotplug() and unlock_cpu_hotplug():
 
 The above calls are used to inhibit cpu hotplug operations. While holding the
 cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid
@@ -120,7 +120,7 @@ will work as long as stop_machine_run() is used to take a cpu down.
 
 CPU Hotplug - Frequently Asked Questions.
 
-Q: How to i enable my kernel to support CPU hotplug?
+Q: How to enable my kernel to support CPU hotplug?
 A: When doing make defconfig, Enable CPU hotplug support
 
    "Processor type and Features" -> Support for Hotpluggable CPUs
@@ -141,39 +141,39 @@ A: You should now notice an entry in sysfs.
 Check if sysfs is mounted, using the "mount" command. You should notice
 an entry as shown below in the output.
 
-....
-none on /sys type sysfs (rw)
-....
+        ....
+        none on /sys type sysfs (rw)
+        ....
 
-if this is not mounted, do the following.
+If this is not mounted, do the following.
 
-#mkdir /sysfs
-#mount -t sysfs sys /sys
+         #mkdir /sysfs
+        #mount -t sysfs sys /sys
 
-now you should see entries for all present cpu, the following is an example
+Now you should see entries for all present cpu, the following is an example
 in a 8-way system.
 
-#pwd
-#/sys/devices/system/cpu
-#ls -l
-total 0
-drwxr-xr-x  10 root root 0 Sep 19 07:44 .
-drwxr-xr-x  13 root root 0 Sep 19 07:45 ..
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu0
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu1
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu2
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu3
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu4
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu5
-drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu6
-drwxr-xr-x   3 root root 0 Sep 19 07:48 cpu7
+        #pwd
+        #/sys/devices/system/cpu
+        #ls -l
+        total 0
+        drwxr-xr-x  10 root root 0 Sep 19 07:44 .
+        drwxr-xr-x  13 root root 0 Sep 19 07:45 ..
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu0
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu1
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu2
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu3
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu4
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu5
+        drwxr-xr-x   3 root root 0 Sep 19 07:44 cpu6
+        drwxr-xr-x   3 root root 0 Sep 19 07:48 cpu7
 
 Under each directory you would find an "online" file which is the control
 file to logically online/offline a processor.
 
 Q: Does hot-add/hot-remove refer to physical add/remove of cpus?
 A: The usage of hot-add/remove may not be very consistently used in the code.
-CONFIG_CPU_HOTPLUG enables logical online/offline capability in the kernel.
+CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel.
 To support physical addition/removal, one would need some BIOS hooks and
 the platform should have something like an attention button in PCI hotplug.
 CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.
@@ -181,17 +181,17 @@ CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.
 Q: How do i logically offline a CPU?
 A: Do the following.
 
-#echo 0 > /sys/devices/system/cpu/cpuX/online
+        #echo 0 > /sys/devices/system/cpu/cpuX/online
 
-once the logical offline is successful, check
+Once the logical offline is successful, check
 
-#cat /proc/interrupts
+        #cat /proc/interrupts
 
-you should now not see the CPU that you removed. Also online file will report
+You should now not see the CPU that you removed. Also online file will report
 the state as 0 when a cpu if offline and 1 when its online.
 
-#To display the current cpu state.
-#cat /sys/devices/system/cpu/cpuX/online
+        #To display the current cpu state.
+        #cat /sys/devices/system/cpu/cpuX/online
 
 Q: Why cant i remove CPU0 on some systems?
 A: Some architectures may have some special dependency on a certain CPU.
@@ -234,8 +234,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and
    departure, how to i arrange for proper notification?
 A: This is what you would need in your kernel code to receive notifications.
 
-    #include <linux/cpu.h>
-    static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
+        #include <linux/cpu.h>
+        static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
                                             unsigned long action, void *hcpu)
         {
                 unsigned int cpu = (unsigned long)hcpu;
@@ -279,10 +279,10 @@ Q: I don't see my action being called for all CPUs already up and running?
 A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
    If you need to perform some action for each cpu already in the system, then
 
-  for_each_online_cpu(i) {
+        for_each_online_cpu(i) {
                 foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
-                foobar_cpu_callback(&foobar-cpu_notifier, CPU_ONLINE, i);
-  }
+                foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
+        }
 
 Q: If i would like to develop cpu hotplug support for a new architecture,
    what do i need at a minimum?
@@ -307,38 +307,38 @@ Q: I need to ensure that a particular cpu is not removed when there is some
    work specific to this cpu is in progress.
 A: First switch the current thread context to preferred cpu
 
-   int my_func_on_cpu(int cpu)
-   {
-       cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
-       int curr_cpu, err = 0;
-
-       saved_mask = current->cpus_allowed;
-       cpu_set(cpu, new_mask);
-       err = set_cpus_allowed(current, new_mask);
-
-       if (err)
-           return err;
-
-       /*
-        * If we got scheduled out just after the return from
-        * set_cpus_allowed() before running the work, this ensures
-        * we stay locked.
-        */
-       curr_cpu = get_cpu();
-
-       if (curr_cpu != cpu) {
-           err = -EAGAIN;
-           goto ret;
-       } else {
-           /*
-            * Do work : But cant sleep, since get_cpu() disables preempt
-            */
-       }
-    ret:
-        put_cpu();
-        set_cpus_allowed(current, saved_mask);
-        return err;
-    }
+        int my_func_on_cpu(int cpu)
+        {
+                cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
+                int curr_cpu, err = 0;
+
+                saved_mask = current->cpus_allowed;
+                cpu_set(cpu, new_mask);
+                err = set_cpus_allowed(current, new_mask);
+
+                if (err)
+                        return err;
+
+                /*
+                 * If we got scheduled out just after the return from
+                 * set_cpus_allowed() before running the work, this ensures
+                 * we stay locked.
+                 */
+                curr_cpu = get_cpu();
+
+                if (curr_cpu != cpu) {
+                        err = -EAGAIN;
+                        goto ret;
+                } else {
+                        /*
+                         * Do work : But cant sleep, since get_cpu() disables preempt
+                         */
+                }
+                ret:
+                        put_cpu();
+                        set_cpus_allowed(current, saved_mask);
+                        return err;
+                }
 
 
 Q: How do we determine how many CPUs are available for hotplug.
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 28c4f79662c2..8de132a02ba9 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -3,7 +3,7 @@
 
              Maintained by Torben Mathiasen <device@lanana.org>
 
-                      Last revised: 15 May 2006
+                      Last revised: 29 November 2006
 
 This list is the Linux Device List, the official registry of allocated
 device numbers and /dev directory nodes for the Linux operating
@@ -92,8 +92,9 @@ Your cooperation is appreciated.
                   7 = /dev/full         Returns ENOSPC on write
                   8 = /dev/random       Nondeterministic random number gen.
                   9 = /dev/urandom      Faster, less secure random number gen.
-                 10 = /dev/aio          Asyncronous I/O notification interface
+                 10 = /dev/aio          Asynchronous I/O notification interface
                  11 = /dev/kmsg         Writes to this come out as printk's
+
   1 block       RAM disk
                   0 = /dev/ram0         First RAM disk
                   1 = /dev/ram1         Second RAM disk
@@ -122,7 +123,7 @@ Your cooperation is appreciated.
                 devices are on major 128 and above and use the PTY
                 master multiplex (/dev/ptmx) to acquire a PTY on
                 demand.
-  
+
   2 block       Floppy disks
                   0 = /dev/fd0          Controller 0, drive 0, autodetect
                   1 = /dev/fd1          Controller 0, drive 1, autodetect
@@ -257,7 +258,7 @@ Your cooperation is appreciated.
                 129 = /dev/vcsa1        tty1 text/attribute contents
                     ...
                 191 = /dev/vcsa63       tty63 text/attribute contents
-        
+
                 NOTE: These devices permit both read and write access.
 
   7 block       Loopback devices
@@ -411,7 +412,7 @@ Your cooperation is appreciated.
                 207 = /dev/video/em8300_sp      EM8300 DVD decoder subpicture
                 208 = /dev/compaq/cpqphpc       Compaq PCI Hot Plug Controller
                 209 = /dev/compaq/cpqrid        Compaq Remote Insight Driver
-                210 = /dev/impi/bt      IMPI coprocessor block transfer 
+                210 = /dev/impi/bt      IMPI coprocessor block transfer
                 211 = /dev/impi/smic    IMPI coprocessor stream interface
                 212 = /dev/watchdogs/0  First watchdog device
                 213 = /dev/watchdogs/1  Second watchdog device
@@ -506,6 +507,7 @@ Your cooperation is appreciated.
                  33 = /dev/patmgr1      Sequencer patch manager
                  34 = /dev/midi02       Third MIDI port
                  50 = /dev/midi03       Fourth MIDI port
+
  14 block       BIOS harddrive callback support {2.6}
                   0 = /dev/dos_hda      First BIOS harddrive whole disk
                  64 = /dev/dos_hdb      Second BIOS harddrive whole disk
@@ -527,6 +529,7 @@ Your cooperation is appreciated.
 
  16 char        Non-SCSI scanners
                   0 = /dev/gs4500       Genius 4500 handheld scanner
+
  16 block       GoldStar CD-ROM
                   0 = /dev/gscd         GoldStar CD-ROM
 
@@ -548,6 +551,7 @@ Your cooperation is appreciated.
                   0 = /dev/ttyC0        First Cyclades port
                     ...
                  31 = /dev/ttyC31       32nd Cyclades port
+
  19 block       "Double" compressed disk
                   0 = /dev/double0      First compressed disk
                     ...
@@ -563,6 +567,7 @@ Your cooperation is appreciated.
                   0 = /dev/cub0         Callout device for ttyC0
                     ...
                  31 = /dev/cub31        Callout device for ttyC31
+
  20 block       Hitachi CD-ROM (under development)
                   0 = /dev/hitcd        Hitachi CD-ROM
 
@@ -582,7 +587,7 @@ Your cooperation is appreciated.
 
                 This device is used on the ARM-based Acorn RiscPC.
                 Partitions are handled the same way as for IDE disks
-                (see major number 3). 
+                (see major number 3).
 
  22 char        Digiboard serial card
                   0 = /dev/ttyD0        First Digiboard port
@@ -591,7 +596,7 @@ Your cooperation is appreciated.
  22 block       Second IDE hard disk/CD-ROM interface
                   0 = /dev/hdc          Master: whole disk (or CD-ROM)
                  64 = /dev/hdd          Slave: whole disk (or CD-ROM)
-                
+
                 Partitions are handled the same way as for the first
                 interface (see major number 3).
 
@@ -639,6 +644,7 @@ Your cooperation is appreciated.
 
  26 char        Quanta WinVision frame grabber {2.6}
                   0 = /dev/wvisfgrab    Quanta WinVision frame grabber
+
  26 block       Second Matsushita (Panasonic/SoundBlaster) CD-ROM
                   0 = /dev/sbpcd4       Panasonic CD-ROM controller 1 unit 0
                   1 = /dev/sbpcd5       Panasonic CD-ROM controller 1 unit 1
@@ -670,6 +676,7 @@ Your cooperation is appreciated.
                  37 = /dev/nrawqft1     Unit 1, no rewind-on-close, no file marks
                  38 = /dev/nrawqft2     Unit 2, no rewind-on-close, no file marks
                  39 = /dev/nrawqft3     Unit 3, no rewind-on-close, no file marks
+
  27 block       Third Matsushita (Panasonic/SoundBlaster) CD-ROM
                   0 = /dev/sbpcd8       Panasonic CD-ROM controller 2 unit 0
                   1 = /dev/sbpcd9       Panasonic CD-ROM controller 2 unit 1
@@ -681,6 +688,7 @@ Your cooperation is appreciated.
                   1 = /dev/staliomem1   Second Stallion card I/O memory
                   2 = /dev/staliomem2   Third Stallion card I/O memory
                   3 = /dev/staliomem3   Fourth Stallion card I/O memory
+
  28 char        Atari SLM ACSI laser printer (68k/Atari)
                   0 = /dev/slm0         First SLM laser printer
                   1 = /dev/slm1         Second SLM laser printer
@@ -690,6 +698,7 @@ Your cooperation is appreciated.
                   1 = /dev/sbpcd13      Panasonic CD-ROM controller 3 unit 1
                   2 = /dev/sbpcd14      Panasonic CD-ROM controller 3 unit 2
                   3 = /dev/sbpcd15      Panasonic CD-ROM controller 3 unit 3
+
  28 block       ACSI disk (68k/Atari)
                   0 = /dev/ada          First ACSI disk whole disk
                  16 = /dev/adb          Second ACSI disk whole disk
@@ -750,6 +759,7 @@ Your cooperation is appreciated.
  31 char        MPU-401 MIDI
                   0 = /dev/mpu401data   MPU-401 data port
                   1 = /dev/mpu401stat   MPU-401 status port
+
  31 block       ROM/flash memory card
                   0 = /dev/rom0         First ROM card (rw)
                       ...
@@ -801,7 +811,7 @@ Your cooperation is appreciated.
  34 block       Fourth IDE hard disk/CD-ROM interface
                   0 = /dev/hdg          Master: whole disk (or CD-ROM)
                  64 = /dev/hdh          Slave: whole disk (or CD-ROM)
-                
+
                 Partitions are handled the same way as for the first
                 interface (see major number 3).
 
@@ -818,6 +828,7 @@ Your cooperation is appreciated.
                 129 = /dev/smpte1       Second MIDI port, SMPTE timed
                 130 = /dev/smpte2       Third MIDI port, SMPTE timed
                 131 = /dev/smpte3       Fourth MIDI port, SMPTE timed
+
  35 block       Slow memory ramdisk
                   0 = /dev/slram        Slow memory ramdisk
 
@@ -828,6 +839,7 @@ Your cooperation is appreciated.
                  16 = /dev/tap0         First Ethertap device
                     ...
                  31 = /dev/tap15        16th Ethertap device
+
  36 block       MCA ESDI hard disk
                   0 = /dev/eda          First ESDI disk whole disk
                  64 = /dev/edb          Second ESDI disk whole disk
@@ -882,6 +894,7 @@ Your cooperation is appreciated.
 
  40 char        Matrox Meteor frame grabber {2.6}
                   0 = /dev/mmetfgrab    Matrox Meteor frame grabber
+
  40 block       Syquest EZ135 parallel port removable drive
                   0 = /dev/eza          Parallel EZ135 drive, whole disk
 
@@ -893,6 +906,7 @@ Your cooperation is appreciated.
 
  41 char        Yet Another Micro Monitor
                   0 = /dev/yamm         Yet Another Micro Monitor
+
  41 block       MicroSolutions BackPack parallel port CD-ROM
                   0 = /dev/bpcd         BackPack CD-ROM
 
@@ -901,6 +915,7 @@ Your cooperation is appreciated.
                 the parallel port ATAPI CD-ROM driver at major number 46.
 
  42 char        Demo/sample use
+
  42 block       Demo/sample use
 
                 This number is intended for use in sample code, as
@@ -918,6 +933,7 @@ Your cooperation is appreciated.
                   0 = /dev/ttyI0        First virtual modem
                     ...
                  63 = /dev/ttyI63       64th virtual modem
+
  43 block       Network block devices
                   0 = /dev/nb0          First network block device
                   1 = /dev/nb1          Second network block device
@@ -934,12 +950,13 @@ Your cooperation is appreciated.
                   0 = /dev/cui0         Callout device for ttyI0
                     ...
                  63 = /dev/cui63        Callout device for ttyI63
+
  44 block       Flash Translation Layer (FTL) filesystems
                   0 = /dev/ftla         FTL on first Memory Technology Device
                  16 = /dev/ftlb         FTL on second Memory Technology Device
                  32 = /dev/ftlc         FTL on third Memory Technology Device
                     ...
-                240 = /dev/ftlp         FTL on 16th Memory Technology Device 
+                240 = /dev/ftlp         FTL on 16th Memory Technology Device
 
                 Partitions are handled in the same way as for IDE
                 disks (see major number 3) except that the partition
@@ -958,6 +975,7 @@ Your cooperation is appreciated.
                 191 = /dev/ippp63       64th SyncPPP device
 
                 255 = /dev/isdninfo     ISDN monitor interface
+
  45 block       Parallel port IDE disk devices
                   0 = /dev/pda          First parallel port IDE disk
                  16 = /dev/pdb          Second parallel port IDE disk
@@ -1044,6 +1062,7 @@ Your cooperation is appreciated.
                   1 = /dev/dcbri1       Second DataComm card
                   2 = /dev/dcbri2       Third DataComm card
                   3 = /dev/dcbri3       Fourth DataComm card
+
  52 block       Mylex DAC960 PCI RAID controller; fifth controller
                   0 = /dev/rd/c4d0      First disk, whole disk
                   8 = /dev/rd/c4d1      Second disk, whole disk
@@ -1093,7 +1112,8 @@ Your cooperation is appreciated.
 
  55 char        DSP56001 digital signal processor
                   0 = /dev/dsp56k       First DSP56001
- 55 block       Mylex DAC960 PCI RAID controller; eigth controller
+
+ 55 block       Mylex DAC960 PCI RAID controller; eighth controller
                   0 = /dev/rd/c7d0      First disk, whole disk
                   8 = /dev/rd/c7d1      Second disk, whole disk
                     ...
@@ -1130,6 +1150,7 @@ Your cooperation is appreciated.
                   0 = /dev/cup0         Callout device for ttyP0
                   1 = /dev/cup1         Callout device for ttyP1
                     ...
+
  58 block       Reserved for logical volume manager
 
  59 char        sf firewall package
@@ -1149,6 +1170,7 @@ Your cooperation is appreciated.
                 NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc
 
  60-63 char     LOCAL/EXPERIMENTAL USE
+
  60-63 block    LOCAL/EXPERIMENTAL USE
                 Allocated for local/experimental use.  For devices not
                 assigned official numbers, these ranges should be
@@ -1434,7 +1456,6 @@ Your cooperation is appreciated.
                 DAC960 (see major number 48) except that the limit on
                 partitions is 15.
 
-
  78 char        PAM Software's multimodem boards
                   0 = /dev/ttyM0        First PAM modem
                   1 = /dev/ttyM1        Second PAM modem
@@ -1450,13 +1471,12 @@ Your cooperation is appreciated.
                 DAC960 (see major number 48) except that the limit on
                 partitions is 15.
 
-
  79 char        PAM Software's multimodem boards - alternate devices
                   0 = /dev/cum0         Callout device for ttyM0
                   1 = /dev/cum1         Callout device for ttyM1
                     ...
 
- 79 block       Compaq Intelligent Drive Array, eigth controller
+ 79 block       Compaq Intelligent Drive Array, eighth controller
                   0 = /dev/ida/c7d0     First logical drive whole disk
                  16 = /dev/ida/c7d1     Second logical drive whole disk
                     ...
@@ -1466,7 +1486,6 @@ Your cooperation is appreciated.
                 DAC960 (see major number 48) except that the limit on
                 partitions is 15.
 
-
  80 char        Photometrics AT200 CCD camera
                   0 = /dev/at200        Photometrics AT200 CCD camera
 
@@ -1679,7 +1698,7 @@ Your cooperation is appreciated.
                   1 = /dev/dcxx1        Second capture card
                     ...
 
- 94 block IBM S/390 DASD block storage
+ 94 block       IBM S/390 DASD block storage
                   0 = /dev/dasda First DASD device, major
                   1 = /dev/dasda1 First DASD device, block 1
                   2 = /dev/dasda2 First DASD device, block 2
@@ -1695,7 +1714,7 @@ Your cooperation is appreciated.
                   1 = /dev/ipnat        NAT control device/log file
                   2 = /dev/ipstate      State information log file
                   3 = /dev/ipauth       Authentication control device/log file
-                    ...         
+                    ...
 
  96 char        Parallel port ATAPI tape devices
                   0 = /dev/pt0          First parallel port ATAPI tape
@@ -1705,7 +1724,7 @@ Your cooperation is appreciated.
                 129 = /dev/npt1         Second p.p. ATAPI tape, no rewind
                     ...
 
- 96 block Inverse NAND Flash Translation Layer
+ 96 block       Inverse NAND Flash Translation Layer
                   0 = /dev/inftla First INFTL layer
                  16 = /dev/inftlb Second INFTL layer
                     ...
@@ -1900,7 +1919,7 @@ Your cooperation is appreciated.
                   1 = /dev/av1          Second A/V card
                     ...
 
-111 block       Compaq Next Generation Drive Array, eigth controller
+111 block       Compaq Next Generation Drive Array, eighth controller
                   0 = /dev/cciss/c7d0   First logical drive, whole disk
                  16 = /dev/cciss/c7d1   Second logical drive, whole disk
                     ...
@@ -1937,7 +1956,6 @@ Your cooperation is appreciated.
                     ...
 
 113 block       IBM iSeries virtual CD-ROM
-
                   0 = /dev/iseries/vcda First virtual CD-ROM
                   1 = /dev/iseries/vcdb Second virtual CD-ROM
                     ...
@@ -2059,11 +2077,12 @@ Your cooperation is appreciated.
                     ...
 
 119 char        VMware virtual network control
-                  0 = /dev/vnet0        1st virtual network
-                  1 = /dev/vnet1        2nd virtual network
+                  0 = /dev/vmnet0       1st virtual network
+                  1 = /dev/vmnet1       2nd virtual network
                     ...
 
 120-127 char    LOCAL/EXPERIMENTAL USE
+
 120-127 block   LOCAL/EXPERIMENTAL USE
                 Allocated for local/experimental use.  For devices not
                 assigned official numbers, these ranges should be
@@ -2075,7 +2094,6 @@ Your cooperation is appreciated.
                 nodes; instead they should be accessed through the
                 /dev/ptmx cloning interface.
 
-
 128 block       SCSI disk devices (128-143)
                   0 = /dev/sddy         129th SCSI disk whole disk
                  16 = /dev/sddz         130th SCSI disk whole disk
@@ -2087,7 +2105,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 129 block       SCSI disk devices (144-159)
                   0 = /dev/sdeo         145th SCSI disk whole disk
                  16 = /dev/sdep         146th SCSI disk whole disk
@@ -2123,7 +2140,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 132 block       SCSI disk devices (192-207)
                   0 = /dev/sdgk         193rd SCSI disk whole disk
                  16 = /dev/sdgl         194th SCSI disk whole disk
@@ -2135,7 +2151,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 133 block       SCSI disk devices (208-223)
                   0 = /dev/sdha         209th SCSI disk whole disk
                  16 = /dev/sdhb         210th SCSI disk whole disk
@@ -2147,7 +2162,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 134 block       SCSI disk devices (224-239)
                   0 = /dev/sdhq         225th SCSI disk whole disk
                  16 = /dev/sdhr         226th SCSI disk whole disk
@@ -2159,7 +2173,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 135 block       SCSI disk devices (240-255)
                   0 = /dev/sdig         241st SCSI disk whole disk
                  16 = /dev/sdih         242nd SCSI disk whole disk
@@ -2171,7 +2184,6 @@ Your cooperation is appreciated.
                 disks (see major number 3) except that the limit on
                 partitions is 15.
 
-
 136-143 char    Unix98 PTY slaves
                   0 = /dev/pts/0        First Unix98 pseudo-TTY
                   1 = /dev/pts/1        Second Unix98 pesudo-TTY
@@ -2384,6 +2396,7 @@ Your cooperation is appreciated.
                     ...
 
 159 char        RESERVED
+
 159 block       RESERVED
 
 160 char        General Purpose Instrument Bus (GPIB)
@@ -2427,7 +2440,7 @@ Your cooperation is appreciated.
 
                 Partitions are handled in the same way as for IDE
                 disks (see major number 3) except that the limit on
-                partitions is 31. 
+                partitions is 31.
 
 162 char        Raw block device interface
                   0 = /dev/rawctl       Raw I/O control device
@@ -2483,7 +2496,6 @@ Your cooperation is appreciated.
 
 171 char        Reserved for IEEE 1394 (Firewire)
 
-
 172 char        Moxa Intellio serial card
                   0 = /dev/ttyMX0       First Moxa port
                   1 = /dev/ttyMX1       Second Moxa port
@@ -2543,9 +2555,6 @@ Your cooperation is appreciated.
                  64 = /dev/usb/rio500   Diamond Rio 500
                  65 = /dev/usb/usblcd   USBLCD Interface (info@usblcd.de)
                  66 = /dev/usb/cpad0    Synaptics cPad (mouse/LCD)
-                 67 = /dev/usb/adutux0  1st Ontrak ADU device
-                    ...
-                 76 = /dev/usb/adutux10 10th Ontrak ADU device
                  96 = /dev/usb/hiddev0  1st USB HID device
                     ...
                 111 = /dev/usb/hiddev15 16th USB HID device
@@ -2558,7 +2567,7 @@ Your cooperation is appreciated.
                 132 = /dev/usb/idmouse  ID Mouse (fingerprint scanner) device
                 133 = /dev/usb/sisusbvga1       First SiSUSB VGA device
                     ...
-                140 = /dev/usb/sisusbvga8       Eigth SISUSB VGA device
+                140 = /dev/usb/sisusbvga8       Eighth SISUSB VGA device
                 144 = /dev/usb/lcd      USB LCD device
                 160 = /dev/usb/legousbtower0    1st USB Legotower device
                     ...
@@ -2571,7 +2580,7 @@ Your cooperation is appreciated.
                   0 = /dev/uba          First USB block device
                   8 = /dev/ubb          Second USB block device
                  16 = /dev/ubc          Third USB block device
-                    ...
+                    ...
 
 181 char        Conrad Electronic parallel port radio clocks
                   0 = /dev/pcfclock0    First Conrad radio clock
@@ -2657,7 +2666,7 @@ Your cooperation is appreciated.
                  32 = /dev/mvideo/status2       Third device
                     ...
                     ...
-                240 = /dev/mvideo/status15      16th device 
+                240 = /dev/mvideo/status15      16th device
                     ...
 
 195 char        Nvidia graphics devices
@@ -2795,6 +2804,10 @@ Your cooperation is appreciated.
                     ...
                  185 = /dev/ttyNX15             Hilscher netX serial port 15
                  186 = /dev/ttyJ0               JTAG1 DCC protocol based serial port emulation
+                 187 = /dev/ttyUL0              Xilinx uartlite - port 0
+                    ...
+                 190 = /dev/ttyUL3              Xilinx uartlite - port 3
+                 191 = /dev/xvc0                Xen virtual console - port 0
 
 205 char        Low-density serial ports (alternate device)
                   0 = /dev/culu0                Callout device for ttyLU0
@@ -2832,7 +2845,6 @@ Your cooperation is appreciated.
                  82 = /dev/cuvr0                Callout device for ttyVR0
                  83 = /dev/cuvr1                Callout device for ttyVR1
 
-
 206 char        OnStream SC-x0 tape devices
                   0 = /dev/osst0                First OnStream SCSI tape, mode 0
                   1 = /dev/osst1                Second OnStream SCSI tape, mode 0
@@ -2922,7 +2934,6 @@ Your cooperation is appreciated.
                     ...
 
 212 char        LinuxTV.org DVB driver subsystem
-
                   0 = /dev/dvb/adapter0/video0    first video decoder of first card
                   1 = /dev/dvb/adapter0/audio0    first audio decoder of first card
                   2 = /dev/dvb/adapter0/sec0      (obsolete/unused)
@@ -3008,9 +3019,9 @@ Your cooperation is appreciated.
                   2 = /dev/3270/tub2            Second 3270 terminal
                     ...
 
-229 char        IBM iSeries virtual console
-                  0 = /dev/iseries/vtty0        First console port
-                  1 = /dev/iseries/vtty1        Second console port
+229 char        IBM iSeries/pSeries virtual console
+                  0 = /dev/hvc0                 First console port
+                  1 = /dev/hvc1                 Second console port
                     ...
 
 230 char        IBM iSeries virtual tape
@@ -3083,12 +3094,14 @@ Your cooperation is appreciated.
 234-239         UNASSIGNED
 
 240-254 char    LOCAL/EXPERIMENTAL USE
+
 240-254 block   LOCAL/EXPERIMENTAL USE
                 Allocated for local/experimental use.  For devices not
                 assigned official numbers, these ranges should be
                 used in order to avoid conflicting with future assignments.
 
 255 char        RESERVED
+
 255 block       RESERVED
 
                 This major is reserved to assist the expansion to a
@@ -3115,7 +3128,20 @@ Your cooperation is appreciated.
 257 char        Phoenix Technologies Cryptographic Services Driver
                   0 = /dev/ptlsec       Crypto Services Driver
 
-
+257 block       SSFDC Flash Translation Layer filesystem
+                  0 = /dev/ssfdca       First SSFDC layer
+                  8 = /dev/ssfdcb       Second SSFDC layer
+                 16 = /dev/ssfdcc       Third SSFDC layer
+                 24 = /dev/ssfdcd       4th SSFDC layer
+                 32 = /dev/ssfdce       5th SSFDC layer
+                 40 = /dev/ssfdcf       6th SSFDC layer
+                 48 = /dev/ssfdcg       7th SSFDC layer
+                 56 = /dev/ssfdch       8th SSFDC layer
+
+258 block       ROM/Flash read-only translation layer
+                  0 = /dev/blockrom0    First ROM card's translation layer interface
+                  1 = /dev/blockrom1    Second ROM card's translation layer interface
+                  ...
 
  ****   ADDITIONAL /dev DIRECTORY ENTRIES
 
diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt
index 5eee3e0bfc4c..9f0bc3bfd776 100644
--- a/Documentation/driver-model/platform.txt
+++ b/Documentation/driver-model/platform.txt
@@ -1,99 +1,131 @@
 Platform Devices and Drivers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See <linux/platform_device.h> for the driver model interface to the
+platform bus:  platform_device, and platform_driver.  This pseudo-bus
+is used to connect devices on busses with minimal infrastructure,
+like those used to integrate peripherals on many system-on-chip
+processors, or some "legacy" PC interconnects; as opposed to large
+formally specified ones like PCI or USB.
+
 
 Platform devices
 ~~~~~~~~~~~~~~~~
 Platform devices are devices that typically appear as autonomous
 entities in the system. This includes legacy port-based devices and
-host bridges to peripheral buses. 
-
-
-Platform drivers
-~~~~~~~~~~~~~~~~
-Drivers for platform devices are typically very simple and
-unstructured. Either the device was present at a particular I/O port
-and the driver was loaded, or it was not. There was no possibility
-of hotplugging or alternative discovery besides probing at a specific
-I/O address and expecting a specific response.
+host bridges to peripheral buses, and most controllers integrated
+into system-on-chip platforms.  What they usually have in common
+is direct addressing from a CPU bus.  Rarely, a platform_device will
+be connected through a segment of some other kind of bus; but its
+registers will still be directly addressible.
 
+Platform devices are given a name, used in driver binding, and a
+list of resources such as addresses and IRQs.
 
-Other Architectures, Modern Firmware, and new Platforms
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-These devices are not always at the legacy I/O ports. This is true on
-other architectures and on some modern architectures. In most cases,
-the drivers are modified to discover the devices at other well-known
-ports for the given platform. However, the firmware in these systems
-does usually know where exactly these devices reside, and in some
-cases, it's the only way of discovering them. 
+struct platform_device {
+        const char      *name;
+        u32             id;
+        struct device   dev;
+        u32             num_resources;
+        struct resource *resource;
+};
 
 
-The Platform Bus
-~~~~~~~~~~~~~~~~
-A platform bus has been created to deal with these issues. First and
-foremost, it groups all the legacy devices under a common bus, and
-gives them a common parent if they don't already have one. 
-
-But, besides the organizational benefits, the platform bus can also
-accommodate firmware-based enumeration. 
-
-
-Device Discovery
+Platform drivers
 ~~~~~~~~~~~~~~~~
-The platform bus has no concept of probing for devices. Devices
-discovery is left up to either the legacy drivers or the
-firmware. These entities are expected to notify the platform of
-devices that it discovers via the bus's add() callback:
-
-        platform_bus.add(parent,bus_id).
-
-
-Bus IDs
-~~~~~~~
-Bus IDs are the canonical names for the devices. There is no globally
-standard addressing mechanism for legacy devices. In the IA-32 world,
-we have Pnp IDs to use, as well as the legacy I/O ports. However,
-neither tell what the device really is or have any meaning on other
-platforms. 
-
-Since both PnP IDs and the legacy I/O ports (and other standard I/O
-ports for specific devices) have a 1:1 mapping, we map the
-platform-specific name or identifier to a generic name (at least
-within the scope of the kernel).
-
-For example, a serial driver might find a device at I/O 0x3f8. The
-ACPI firmware might also discover a device with PnP ID (_HID)
-PNP0501. Both correspond to the same device and should be mapped to the
-canonical name 'serial'. 
-
-The bus_id field should be a concatenation of the canonical name and
-the instance of that type of device. For example, the device at I/O
-port 0x3f8 should have a bus_id of "serial0". This places the
-responsibility of enumerating devices of a particular type up to the
-discovery mechanism. But, they are the entity that should know best
-(as opposed to the platform bus driver).
-
-
-Drivers 
-~~~~~~~
-Drivers for platform devices should have a name that is the same as
-the canonical name of the devices they support. This allows the
-platform bus driver to do simple matching with the basic data
-structures to determine if a driver supports a certain device. 
-
-For example, a legacy serial driver should have a name of 'serial' and
-register itself with the platform bus. 
-
-
-Driver Binding
-~~~~~~~~~~~~~~
-Legacy drivers assume they are bound to the device once they start up
-and probe an I/O port. Divorcing them from this will be a difficult
-process. However, that shouldn't prevent us from implementing
-firmware-based enumeration. 
-
-The firmware should notify the platform bus about devices before the
-legacy drivers have had a chance to load. Once the drivers are loaded,
-they driver model core will attempt to bind the driver to any
-previously-discovered devices. Once that has happened, it will be free
-to discover any other devices it pleases.
+Platform drivers follow the standard driver model convention, where
+discovery/enumeration is handled outside the drivers, and drivers
+provide probe() and remove() methods.  They support power management
+and shutdown notifications using the standard conventions.
+
+struct platform_driver {
+        int (*probe)(struct platform_device *);
+        int (*remove)(struct platform_device *);
+        void (*shutdown)(struct platform_device *);
+        int (*suspend)(struct platform_device *, pm_message_t state);
+        int (*suspend_late)(struct platform_device *, pm_message_t state);
+        int (*resume_early)(struct platform_device *);
+        int (*resume)(struct platform_device *);
+        struct device_driver driver;
+};
+
+Note that probe() should general verify that the specified device hardware
+actually exists; sometimes platform setup code can't be sure.  The probing
+can use device resources, including clocks, and device platform_data.
+
+Platform drivers register themselves the normal way:
+
+        int platform_driver_register(struct platform_driver *drv);
+
+Or, in common situations where the device is known not to be hot-pluggable,
+the probe() routine can live in an init section to reduce the driver's
+runtime memory footprint:
+
+        int platform_driver_probe(struct platform_driver *drv,
+                          int (*probe)(struct platform_device *))
+
+
+Device Enumeration
+~~~~~~~~~~~~~~~~~~
+As a rule, platform specific (and often board-specific) setup code wil
+register platform devices:
+
+        int platform_device_register(struct platform_device *pdev);
+
+        int platform_add_devices(struct platform_device **pdevs, int ndev);
+
+The general rule is to register only those devices that actually exist,
+but in some cases extra devices might be registered.  For example, a kernel
+might be configured to work with an external network adapter that might not
+be populated on all boards, or likewise to work with an integrated controller
+that some boards might not hook up to any peripherals.
+
+In some cases, boot firmware will export tables describing the devices
+that are populated on a given board.   Without such tables, often the
+only way for system setup code to set up the correct devices is to build
+a kernel for a specific target board.  Such board-specific kernels are
+common with embedded and custom systems development.
+
+In many cases, the memory and IRQ resources associated with the platform
+device are not enough to let the device's driver work.  Board setup code
+will often provide additional information using the device's platform_data
+field to hold additional information.
+
+Embedded systems frequently need one or more clocks for platform devices,
+which are normally kept off until they're actively needed (to save power).
+System setup also associates those clocks with the device, so that that
+calls to clk_get(&pdev->dev, clock_name) return them as needed.
+
+
+Device Naming and Driver Binding
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The platform_device.dev.bus_id is the canonical name for the devices.
+It's built from two components:
+
+    * platform_device.name ... which is also used to for driver matching.
+
+    * platform_device.id ... the device instance number, or else "-1"
+      to indicate there's only one.
+
+These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and
+"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
+named "serial".  While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
+and use the platform_driver called "my_rtc".
+
+Driver binding is performed automatically by the driver core, invoking
+driver probe() after finding a match between device and driver.  If the
+probe() succeeds, the driver and device are bound as usual.  There are
+three different ways to find such a match:
+
+    - Whenever a device is registered, the drivers for that bus are
+      checked for matches.  Platform devices should be registered very
+      early during system boot.
+
+    - When a driver is registered using platform_driver_register(), all
+      unbound devices on that bus are checked for matches.  Drivers
+      usually register later during booting, or by module loading.
+
+    - Registering a driver using platform_driver_probe() works just like
+      using platform_driver_register(), except that the the driver won't
+      be probed later if another device registers.  (Which is OK, since
+      this interface is only for use with non-hotpluggable devices.)
 
diff --git a/Documentation/driver-model/porting.txt b/Documentation/driver-model/porting.txt
index 98b233cb8b36..92d86f7271b4 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt
@@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
 describing the relationship the device has to other entities. 
 
 
-- Embedd a struct device in the bus-specific device type. 
+- Embed a struct device in the bus-specific device type. 
 
 
 struct pci_dev {
diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt
index ca58e339d85f..cc09187a5db7 100644
--- a/Documentation/dvb/cards.txt
+++ b/Documentation/dvb/cards.txt
@@ -22,10 +22,10 @@ o Frontends drivers:
    - ves1x93            : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
    - cx24110            : Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL)
    - grundig_29504-491  : Grundig 29504-491 (Philips TDA8083 demodulator), tsa5522 PLL
-   - mt312              : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLL
+   - mt312              : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLLi, Technisat Sky2Pc with bios Rev. 2.3
    - stv0299            : Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL),
                           LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL),
-                          Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB
+                          Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB, Technisat Sky2Pc with bios Rev. 2.6
   DVB-C:
    - ves1820            : various (ves1820 demodulator, sp5659c or spXXXX PLL)
    - at76c651           : Atmel AT76c651(B) with DAT7021 PLL
diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt
index 531239b29082..2ecd834585e6 100644
--- a/Documentation/dvb/ci.txt
+++ b/Documentation/dvb/ci.txt
@@ -71,7 +71,7 @@ eliminating the need for any additional ioctls.
 The disadvantage is that the driver/hardware has to manage the rest. For
 the application programmer it would be as simple as sending/receiving an
 array to/from the CI ioctls as defined in the Linux DVB API. No changes
-have been made in the API to accomodate this feature.
+have been made in the API to accommodate this feature.
 
 
 * Why the need for another CI interface ?
@@ -102,7 +102,7 @@ This CI interface follows the CI high level interface, which is not
 implemented by most applications. Hence this area is revisited.
 
 This CI interface is quite different in the case that it tries to
-accomodate all other CI based devices, that fall into the other categories
+accommodate all other CI based devices, that fall into the other categories.
 
 This means that this CI interface handles the EN50221 style tags in the
 Application layer only and no session management is taken care of by the
diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt
index 6a099edadd62..60e361ba08c0 100644
--- a/Documentation/eisa.txt
+++ b/Documentation/eisa.txt
@@ -62,7 +62,7 @@ res           : root device I/O resource
 bus_base_addr : slot 0 address on this bus
 slots         : max slot number to probe
 force_probe   : Probe even when slot 0 is empty (no EISA mainboard)
-dma_mask      : Default DMA mask. Usualy the bridge device dma_mask.
+dma_mask      : Default DMA mask. Usually the bridge device dma_mask.
 bus_nr        : unique bus id, set by eisa_root_register
 
 ** Driver :
diff --git a/Documentation/fault-injection/failcmd.sh b/Documentation/fault-injection/failcmd.sh
new file mode 100644
index 000000000000..63177aba8106
--- /dev/null
+++ b/Documentation/fault-injection/failcmd.sh
@@ -0,0 +1,4 @@
+#!/bin/bash
+
+echo 1 > /proc/self/make-it-fail
+exec $*
diff --git a/Documentation/fault-injection/failmodule.sh b/Documentation/fault-injection/failmodule.sh
new file mode 100644
index 000000000000..474a8b971f9c
--- /dev/null
+++ b/Documentation/fault-injection/failmodule.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+#
+# Usage: failmodule <failname> <modulename> [stacktrace-depth]
+#
+#       <failname>: "failslab", "fail_alloc_page", or "fail_make_request"
+#
+#       <modulename>: module name that you want to inject faults.
+#
+#       [stacktrace-depth]: the maximum number of stacktrace walking allowed
+#
+
+STACKTRACE_DEPTH=5
+if [ $# -gt 2 ]; then
+        STACKTRACE_DEPTH=$3
+fi
+
+if [ ! -d /debug/$1 ]; then
+        echo "Fault-injection $1 does not exist" >&2
+        exit 1
+fi
+if [ ! -d /sys/module/$2 ]; then
+        echo "Module $2 does not exist" >&2
+        exit 1
+fi
+
+# Disable any fault injection
+echo 0 > /debug/$1/stacktrace-depth
+
+echo `cat /sys/module/$2/sections/.text` > /debug/$1/require-start
+echo `cat /sys/module/$2/sections/.exit.text` > /debug/$1/require-end
+echo $STACKTRACE_DEPTH > /debug/$1/stacktrace-depth
diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt
new file mode 100644
index 000000000000..b7ca560b9340
--- /dev/null
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -0,0 +1,225 @@
+Fault injection capabilities infrastructure
+===========================================
+
+See also drivers/md/faulty.c and "every_nth" module option for scsi_debug.
+
+
+Available fault injection capabilities
+--------------------------------------
+
+o failslab
+
+  injects slab allocation failures. (kmalloc(), kmem_cache_alloc(), ...)
+
+o fail_page_alloc
+
+  injects page allocation failures. (alloc_pages(), get_free_pages(), ...)
+
+o fail_make_request
+
+  injects disk IO errors on devices permitted by setting
+  /sys/block/<device>/make-it-fail or
+  /sys/block/<device>/<partition>/make-it-fail. (generic_make_request())
+
+Configure fault-injection capabilities behavior
+-----------------------------------------------
+
+o debugfs entries
+
+fault-inject-debugfs kernel module provides some debugfs entries for runtime
+configuration of fault-injection capabilities.
+
+- /debug/fail*/probability:
+
+        likelihood of failure injection, in percent.
+        Format: <percent>
+
+        Note that one-failure-per-hundred is a very high error rate
+        for some testcases.  Consider setting probability=100 and configure
+        /debug/fail*/interval for such testcases.
+
+- /debug/fail*/interval:
+
+        specifies the interval between failures, for calls to
+        should_fail() that pass all the other tests.
+
+        Note that if you enable this, by setting interval>1, you will
+        probably want to set probability=100.
+
+- /debug/fail*/times:
+
+        specifies how many times failures may happen at most.
+        A value of -1 means "no limit".
+
+- /debug/fail*/space:
+
+        specifies an initial resource "budget", decremented by "size"
+        on each call to should_fail(,size).  Failure injection is
+        suppressed until "space" reaches zero.
+
+- /debug/fail*/verbose
+
+        Format: { 0 | 1 | 2 }
+        specifies the verbosity of the messages when failure is
+        injected.  '0' means no messages; '1' will print only a single
+        log line per failure; '2' will print a call trace too -- useful
+        to debug the problems revealed by fault injection.
+
+- /debug/fail*/task-filter:
+
+        Format: { 'Y' | 'N' }
+        A value of 'N' disables filtering by process (default).
+        Any positive value limits failures to only processes indicated by
+        /proc/<pid>/make-it-fail==1.
+
+- /debug/fail*/require-start:
+- /debug/fail*/require-end:
+- /debug/fail*/reject-start:
+- /debug/fail*/reject-end:
+
+        specifies the range of virtual addresses tested during
+        stacktrace walking.  Failure is injected only if some caller
+        in the walked stacktrace lies within the required range, and
+        none lies within the rejected range.
+        Default required range is [0,ULONG_MAX) (whole of virtual address space).
+        Default rejected range is [0,0).
+
+- /debug/fail*/stacktrace-depth:
+
+        specifies the maximum stacktrace depth walked during search
+        for a caller within [require-start,require-end) OR
+        [reject-start,reject-end).
+
+- /debug/fail_page_alloc/ignore-gfp-highmem:
+
+        Format: { 'Y' | 'N' }
+        default is 'N', setting it to 'Y' won't inject failures into
+        highmem/user allocations.
+
+- /debug/failslab/ignore-gfp-wait:
+- /debug/fail_page_alloc/ignore-gfp-wait:
+
+        Format: { 'Y' | 'N' }
+        default is 'N', setting it to 'Y' will inject failures
+        only into non-sleep allocations (GFP_ATOMIC allocations).
+
+o Boot option
+
+In order to inject faults while debugfs is not available (early boot time),
+use the boot option:
+
+        failslab=
+        fail_page_alloc=
+        fail_make_request=<interval>,<probability>,<space>,<times>
+
+How to add new fault injection capability
+-----------------------------------------
+
+o #include <linux/fault-inject.h>
+
+o define the fault attributes
+
+  DECLARE_FAULT_INJECTION(name);
+
+  Please see the definition of struct fault_attr in fault-inject.h
+  for details.
+
+o provide a way to configure fault attributes
+
+- boot option
+
+  If you need to enable the fault injection capability from boot time, you can
+  provide boot option to configure it. There is a helper function for it:
+
+        setup_fault_attr(attr, str);
+
+- debugfs entries
+
+  failslab, fail_page_alloc, and fail_make_request use this way.
+  Helper functions:
+
+        init_fault_attr_entries(entries, attr, name);
+        void cleanup_fault_attr_entries(entries);
+
+- module parameters
+
+  If the scope of the fault injection capability is limited to a
+  single kernel module, it is better to provide module parameters to
+  configure the fault attributes.
+
+o add a hook to insert failures
+
+  Upon should_fail() returning true, client code should inject a failure.
+
+        should_fail(attr, size);
+
+Application Examples
+--------------------
+
+o inject slab allocation failures into module init/cleanup code
+
+------------------------------------------------------------------------------
+#!/bin/bash
+
+FAILCMD=Documentation/fault-injection/failcmd.sh
+BLACKLIST="root_plug evbug"
+
+FAILNAME=failslab
+echo Y > /debug/$FAILNAME/task-filter
+echo 10 > /debug/$FAILNAME/probability
+echo 100 > /debug/$FAILNAME/interval
+echo -1 > /debug/$FAILNAME/times
+echo 2 > /debug/$FAILNAME/verbose
+echo 1 > /debug/$FAILNAME/ignore-gfp-wait
+
+blacklist()
+{
+        echo $BLACKLIST | grep $1 > /dev/null 2>&1
+}
+
+oops()
+{
+        dmesg | grep BUG > /dev/null 2>&1
+}
+
+find /lib/modules/`uname -r` -name '*.ko' -exec basename {} .ko \; |
+        while read i
+        do
+                oops && exit 1
+
+                if ! blacklist $i
+                then
+                        echo inserting $i...
+                        bash $FAILCMD modprobe $i
+                fi
+        done
+
+lsmod | awk '{ if ($3 == 0) { print $1 } }' |
+        while read i
+        do
+                oops && exit 1
+
+                if ! blacklist $i
+                then
+                        echo removing $i...
+                        bash $FAILCMD modprobe -r $i
+                fi
+        done
+
+------------------------------------------------------------------------------
+
+o inject slab allocation failures only for a specific module
+
+------------------------------------------------------------------------------
+#!/bin/bash
+
+FAILMOD=Documentation/fault-injection/failmodule.sh
+
+echo injecting errors into the module $1...
+
+modprobe $1
+bash $FAILMOD failslab $1 10
+echo 25 > /debug/failslab/probability
+
+------------------------------------------------------------------------------
+
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 7ebca0775ec1..64ce44da5936 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -30,11 +30,39 @@ Who:	Adrian Bunk <bunk@stusta.de>
 ---------------------------
 
 What:   raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
-When:   November 2006
-Why:    Deprecated in favour of the new ioctl-based rawiso interface, which is
-        more efficient.  You should really be using libraw1394 for raw1394
-        access anyway.
-Who:    Jody McIntyre <scjody@modernduck.com>
+When:   June 2007
+Why:    Deprecated in favour of the more efficient and robust rawiso interface.
+        Affected are applications which use the deprecated part of libraw1394
+        (raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv,
+        raw1394_stop_iso_rcv) or bypass libraw1394.
+Who:    Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+---------------------------
+
+What:   dv1394 driver (CONFIG_IEEE1394_DV1394)
+When:   June 2007
+Why:    Replaced by raw1394 + userspace libraries, notably libiec61883.  This
+        shift of application support has been indicated on www.linux1394.org
+        and developers' mailinglists for quite some time.  Major applications
+        have been converted, with the exception of ffmpeg and hence xine.
+        Piped output of dvgrab2 is a partial equivalent to dv1394.
+Who:    Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+---------------------------
+
+What:   ieee1394 core's unused exports (CONFIG_IEEE1394_EXPORT_FULL_API)
+When:   January 2007
+Why:    There are no projects known to use these exported symbols, except
+        dfg1394 (uses one symbol whose functionality is core-internal now).
+Who:    Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+---------------------------
+
+What:   ieee1394's *_oui sysfs attributes (CONFIG_IEEE1394_OUI_DB)
+When:   January 2007
+Files:  drivers/ieee1394/: oui.db, oui2c.sh
+Why:    big size, little value
+Who:    Stefan Richter <stefanr@s5r6.in-berlin.de>
 
 ---------------------------
 
@@ -53,18 +81,6 @@ Who:	Mauro Carvalho Chehab <mchehab@brturbo.com.br>
 
 ---------------------------
 
-What:   sys_sysctl
-When:   January 2007
-Why:    The same information is available through /proc/sys and that is the
-        interface user space prefers to use. And there do not appear to be
-        any existing user in user space of sys_sysctl.  The additional
-        maintenance overhead of keeping a set of binary names gets
-        in the way of doing a good job of maintaining this interface.
-
-Who:    Eric Biederman <ebiederm@xmission.com>
-
----------------------------
-
 What:   PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
 When:   November 2005
 Files:  drivers/pcmcia/: pcmcia_ioctl.c
@@ -82,18 +98,6 @@ Who:	Dominik Brodowski <linux@brodo.de>
 
 ---------------------------
 
-What:   ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
-When:   December 2005
-Why:    This interface has been obsoleted by the new layer3-independent
-        "nfnetlink_queue".  The Kernel interface is compatible, so the old
-        ip[6]tables "QUEUE" targets still work and will transparently handle
-        all packets into nfnetlink queue number 0.  Userspace users will have
-        to link against API-compatible library on top of libnfnetlink_queue 
-        instead of the current 'libipq'.
-Who:    Harald Welte <laforge@netfilter.org>
-
----------------------------
-
 What:   remove EXPORT_SYMBOL(kernel_thread)
 When:   August 2006
 Files:  arch/*/kernel/*_ksyms.c
@@ -212,17 +216,6 @@ Who:	Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
-What:   i2c-ite and i2c-algo-ite drivers
-When:   September 2006
-Why:    These drivers never compiled since they were added to the kernel
-        tree 5 years ago. This feature removal can be reevaluated if
-        someone shows interest in the drivers, fixes them and takes over
-        maintenance.
-        http://marc.theaimsgroup.com/?l=linux-mips&m=115040510817448
-Who:    Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
 What:   Bridge netfilter deferred IPv4/IPv6 output hook calling
 When:   January 2007
 Why:    The deferred output hooks are a layering violation causing unusual
@@ -239,23 +232,8 @@ Who:	Patrick McHardy <kaber@trash.net>
 
 ---------------------------
 
-What:   frame diverter
-When:   November 2006
-Why:    The frame diverter is included in most distribution kernels, but is
-        broken. It does not correctly handle many things:
-        - IPV6
-        - non-linear skb's
-        - network device RCU on removal
-        - input frames not correctly checked for protocol errors
-        It also adds allocation overhead even if not enabled.
-        It is not clear if anyone is still using it.
-Who:    Stephen Hemminger <shemminger@osdl.org>
-
----------------------------
-
-
 What:   PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
-When:   Oktober 2008
+When:   October 2008
 Why:    The stacking of class devices makes these values misleading and
         inconsistent.
         Class devices should not carry any of these properties, and bus
@@ -273,11 +251,12 @@ Who:	Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
 
-What:   ftape
-When:   2.6.20
-Why:    Orphaned for ages.  SMP bugs long unfixed.  Few users left
-        in the world.
-Who:    Jeff Garzik <jeff@garzik.org>
+What:   IPv4 only connection tracking/NAT/helpers
+When:   2.6.22
+Why:    The new layer 3 independant connection tracking replaces the old
+        IPv4 only version. After some stabilization of the new code the
+        old one will be removed.
+Who:    Patrick McHardy <kaber@trash.net>
 
 ---------------------------
 
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index eb1a6cad21e6..790ef6fbe495 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -124,7 +124,7 @@ sync_fs:		no	no	read
 write_super_lockfs:     ?
 unlockfs:               ?
 statfs:                 no      no      no
-remount_fs:             no      yes     maybe           (see below)
+remount_fs:             yes     yes     maybe           (see below)
 clear_inode:            no
 umount_begin:           yes     no      no
 show_options:           no                              (vfsmount->sem)
diff --git a/Documentation/filesystems/adfs.txt b/Documentation/filesystems/adfs.txt
index 060abb0c7004..9e8811f92b84 100644
--- a/Documentation/filesystems/adfs.txt
+++ b/Documentation/filesystems/adfs.txt
@@ -3,7 +3,7 @@ Mount options for ADFS
 
   uid=nnn       All files in the partition will be owned by
                 user id nnn.  Default 0 (root).
-  gid=nnn       All files in the partition willbe in group
+  gid=nnn       All files in the partition will be in group
                 nnn.  Default 0 (root).
   ownmask=nnn   The permission mask for ADFS 'owner' permissions
                 will be nnn.  Default 0700.
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt
index c3a7afb5eabf..b34cdb50eab4 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -209,7 +209,7 @@ will happen for write(2).
 
 [struct config_group]
 
-A config_item cannot live in a vaccum.  The only way one can be created
+A config_item cannot live in a vacuum.  The only way one can be created
 is via mkdir(2) on a config_group.  This will trigger creation of a
 child item.
 
@@ -275,7 +275,7 @@ directory is not empty.
 
 [struct configfs_subsystem]
 
-A subsystem must register itself, ususally at module_init time.  This
+A subsystem must register itself, usually at module_init time.  This
 tells configfs to make the subsystem appear in the file tree.
 
         struct configfs_subsystem {
diff --git a/Documentation/filesystems/fuse.txt b/Documentation/filesystems/fuse.txt
index a584f05403a4..345392c4caeb 100644
--- a/Documentation/filesystems/fuse.txt
+++ b/Documentation/filesystems/fuse.txt
@@ -51,6 +51,22 @@ homepage:
 
   http://fuse.sourceforge.net/
 
+Filesystem type
+~~~~~~~~~~~~~~~
+
+The filesystem type given to mount(2) can be one of the following:
+
+'fuse'
+
+  This is the usual way to mount a FUSE filesystem.  The first
+  argument of the mount system call may contain an arbitrary string,
+  which is not interpreted by the kernel.
+
+'fuseblk'
+
+  The filesystem is block device based.  The first argument of the
+  mount system call is interpreted as the name of the device.
+
 Mount options
 ~~~~~~~~~~~~~
 
@@ -94,6 +110,11 @@ Mount options
   The default is infinite.  Note that the size of read requests is
   limited anyway to 32 pages (which is 128kbyte on i386).
 
+'blksize=N'
+
+  Set the block size for the filesystem.  The default is 512.  This
+  option is only valid for 'fuseblk' type mounts.
+
 Control filesystem
 ~~~~~~~~~~~~~~~~~~
 
@@ -111,7 +132,7 @@ For each connection the following files exist within this directory:
 
  'waiting'
 
-  The number of requests which are waiting to be transfered to
+  The number of requests which are waiting to be transferred to
   userspace or being processed by the filesystem daemon.  If there is
   no filesystem activity and 'waiting' is non-zero, then the
   filesystem is hung or deadlocked.
@@ -136,7 +157,7 @@ following will happen:
 
   2) If the request is not yet sent to userspace AND the signal is not
      fatal, then an 'interrupted' flag is set for the request.  When
-     the request has been successfully transfered to userspace and
+     the request has been successfully transferred to userspace and
      this flag is set, an INTERRUPT request is queued.
 
   3) If the request is already sent to userspace, then an INTERRUPT
diff --git a/Documentation/filesystems/hpfs.txt b/Documentation/filesystems/hpfs.txt
index 33dc360c8e89..38aba03efc5e 100644
--- a/Documentation/filesystems/hpfs.txt
+++ b/Documentation/filesystems/hpfs.txt
@@ -274,7 +274,7 @@ History
      Fixed race-condition in buffer code - it is in all filesystems in Linux;
         when reading device (cat /dev/hda) while creating files on it, files
         could be damaged
-2.02 Woraround for bug in breada in Linux. breada could cause accesses beyond
+2.02 Workaround for bug in breada in Linux. breada could cause accesses beyond
         end of partition
 2.03 Char, block devices and pipes are correctly created
      Fixed non-crashing race in unlink (Alexander Viro)
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 35f105b29e3e..13ba649bda75 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -337,7 +337,7 @@ Finally, for a mirrored volume, i.e. raid level 1, the table would look like
 this (note all values are in 512-byte sectors):
 
 --- cut here ---
-# Ofs Size   Raid   Log  Number Region Should Number Source  Start Taget  Start
+# Ofs Size   Raid   Log  Number Region Should Number Source  Start Target Start
 # in  of the type   type of log size   sync?  of     Device  in    Device in
 # vol volume             params              mirrors         Device       Device
 0    2056320 mirror core 2      16     nosync 2    /dev/hda1 0   /dev/hdb1 0
@@ -599,7 +599,7 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
         - Major bug fixes for reading files and volumes in corner cases which
           were being hit by Windows 2k/XP users.
 2.1.2:
-        - Major bug fixes aleviating the hangs in statfs experienced by some
+        - Major bug fixes alleviating the hangs in statfs experienced by some
           users.
 2.1.1:
         - Update handling of compressed files so people no longer get the
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt
index 4389c684a80a..8ccf0c1b58ed 100644
--- a/Documentation/filesystems/ocfs2.txt
+++ b/Documentation/filesystems/ocfs2.txt
@@ -30,7 +30,7 @@ Caveats
 Features which OCFS2 does not support yet:
         - sparse files
         - extended attributes
-        - shared writeable mmap
+        - shared writable mmap
         - loopback is supported, but data written will not
           be cluster coherent.
         - quotas
@@ -54,3 +54,6 @@ errors=panic		Panic and halt the machine if an error occurs.
 intr            (*)     Allow signals to interrupt cluster operations.
 nointr                  Do not allow signals to interrupt cluster
                         operations.
+atime_quantum=60(*)     OCFS2 will not update atime unless this number
+                        of seconds has passed since the last update.
+                        Set to zero to always update atime.
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 3355e6920105..72af5de1effb 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1220,9 +1220,9 @@ applications are using mlock(), or if you are running with no swap then
 you probably should increase the lower_zone_protection setting.
 
 The units of this tunable are fairly vague.  It is approximately equal
-to "megabytes".  So setting lower_zone_protection=100 will protect around 100
+to "megabytes," so setting lower_zone_protection=100 will protect around 100
 megabytes of the lowmem zone from user allocations.  It will also make
-those 100 megabytes unavaliable for use by applications and by
+those 100 megabytes unavailable for use by applications and by
 pagecache, so there is a cost.
 
 The effects of this tunable may be observed by monitoring
@@ -1538,10 +1538,10 @@ TCP settings
 tcp_ecn
 -------
 
-This file controls the use of the ECN bit in the IPv4 headers, this is a new
+This file controls the use of the ECN bit in the IPv4 headers. This is a new
 feature about Explicit Congestion Notification, but some routers and firewalls
-block trafic that has this bit set, so it could be necessary to echo 0 to
-/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info
+block traffic that has this bit set, so it could be necessary to echo 0 to
+/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
 you could read RFC2481.
 
 tcp_retrans_collapse
diff --git a/Documentation/filesystems/spufs.txt b/Documentation/filesystems/spufs.txt
index 982645a1981d..1343d118a9b2 100644
--- a/Documentation/filesystems/spufs.txt
+++ b/Documentation/filesystems/spufs.txt
@@ -210,7 +210,7 @@ FILES
    /signal2
        The two signal notification channels of an SPU.  These  are  read-write
        files  that  operate  on  a 32 bit word.  Writing to one of these files
-       triggers an interrupt on the SPU. The  value  writting  to  the  signal
+       triggers an interrupt on the SPU.  The  value  written  to  the  signal
        files can be read from the SPU through a channel read or from host user
        space through the file.  After the value has been read by the  SPU,  it
        is  reset  to zero.  The possible operations on an open signal1 or sig-
diff --git a/Documentation/filesystems/sysv-fs.txt b/Documentation/filesystems/sysv-fs.txt
index d81722418010..253b50d1328e 100644
--- a/Documentation/filesystems/sysv-fs.txt
+++ b/Documentation/filesystems/sysv-fs.txt
@@ -1,11 +1,8 @@
-This is the implementation of the SystemV/Coherent filesystem for Linux.
 It implements all of
   - Xenix FS,
   - SystemV/386 FS,
   - Coherent FS.
 
-This is version beta 4.
-
 To install:
 * Answer the 'System V and Coherent filesystem support' question with 'y'
   when configuring the kernel.
@@ -28,11 +25,173 @@ Bugs in the present implementation:
   for this FS on hard disk yet.
 
 
-Please report any bugs and suggestions to
-  Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de>
-  Pascal Haible <haible@izfm.uni-stuttgart.de>
-  Krzysztof G. Baranowski <kgb@manjak.knm.org.pl>
+These filesystems are rather similar. Here is a comparison with Minix FS:
+
+* Linux fdisk reports on partitions
+  - Minix FS     0x81 Linux/Minix
+  - Xenix FS     ??
+  - SystemV FS   ??
+  - Coherent FS  0x08 AIX bootable
+
+* Size of a block or zone (data allocation unit on disk)
+  - Minix FS     1024
+  - Xenix FS     1024 (also 512 ??)
+  - SystemV FS   1024 (also 512 and 2048)
+  - Coherent FS   512
+
+* General layout: all have one boot block, one super block and
+  separate areas for inodes and for directories/data.
+  On SystemV Release 2 FS (e.g. Microport) the first track is reserved and
+  all the block numbers (including the super block) are offset by one track.
+
+* Byte ordering of "short" (16 bit entities) on disk:
+  - Minix FS     little endian  0 1
+  - Xenix FS     little endian  0 1
+  - SystemV FS   little endian  0 1
+  - Coherent FS  little endian  0 1
+  Of course, this affects only the file system, not the data of files on it!
+
+* Byte ordering of "long" (32 bit entities) on disk:
+  - Minix FS     little endian  0 1 2 3
+  - Xenix FS     little endian  0 1 2 3
+  - SystemV FS   little endian  0 1 2 3
+  - Coherent FS  PDP-11         2 3 0 1
+  Of course, this affects only the file system, not the data of files on it!
+
+* Inode on disk: "short", 0 means non-existent, the root dir ino is:
+  - Minix FS                            1
+  - Xenix FS, SystemV FS, Coherent FS   2
+
+* Maximum number of hard links to a file:
+  - Minix FS     250
+  - Xenix FS     ??
+  - SystemV FS   ??
+  - Coherent FS  >=10000
+
+* Free inode management:
+  - Minix FS                             a bitmap
+  - Xenix FS, SystemV FS, Coherent FS
+      There is a cache of a certain number of free inodes in the super-block.
+      When it is exhausted, new free inodes are found using a linear search.
+
+* Free block management:
+  - Minix FS                             a bitmap
+  - Xenix FS, SystemV FS, Coherent FS
+      Free blocks are organized in a "free list". Maybe a misleading term,
+      since it is not true that every free block contains a pointer to
+      the next free block. Rather, the free blocks are organized in chunks
+      of limited size, and every now and then a free block contains pointers
+      to the free blocks pertaining to the next chunk; the first of these
+      contains pointers and so on. The list terminates with a "block number"
+      0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS.
+
+* Super-block location:
+  - Minix FS     block 1 = bytes 1024..2047
+  - Xenix FS     block 1 = bytes 1024..2047
+  - SystemV FS   bytes 512..1023
+  - Coherent FS  block 1 = bytes 512..1023
+
+* Super-block layout:
+  - Minix FS
+                    unsigned short s_ninodes;
+                    unsigned short s_nzones;
+                    unsigned short s_imap_blocks;
+                    unsigned short s_zmap_blocks;
+                    unsigned short s_firstdatazone;
+                    unsigned short s_log_zone_size;
+                    unsigned long s_max_size;
+                    unsigned short s_magic;
+  - Xenix FS, SystemV FS, Coherent FS
+                    unsigned short s_firstdatazone;
+                    unsigned long  s_nzones;
+                    unsigned short s_fzone_count;
+                    unsigned long  s_fzones[NICFREE];
+                    unsigned short s_finode_count;
+                    unsigned short s_finodes[NICINOD];
+                    char           s_flock;
+                    char           s_ilock;
+                    char           s_modified;
+                    char           s_rdonly;
+                    unsigned long  s_time;
+                    short          s_dinfo[4]; -- SystemV FS only
+                    unsigned long  s_free_zones;
+                    unsigned short s_free_inodes;
+                    short          s_dinfo[4]; -- Xenix FS only
+                    unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only
+                    char           s_fname[6];
+                    char           s_fpack[6];
+    then they differ considerably:
+        Xenix FS
+                    char           s_clean;
+                    char           s_fill[371];
+                    long           s_magic;
+                    long           s_type;
+        SystemV FS
+                    long           s_fill[12 or 14];
+                    long           s_state;
+                    long           s_magic;
+                    long           s_type;
+        Coherent FS
+                    unsigned long  s_unique;
+    Note that Coherent FS has no magic.
+
+* Inode layout:
+  - Minix FS
+                    unsigned short i_mode;
+                    unsigned short i_uid;
+                    unsigned long  i_size;
+                    unsigned long  i_time;
+                    unsigned char  i_gid;
+                    unsigned char  i_nlinks;
+                    unsigned short i_zone[7+1+1];
+  - Xenix FS, SystemV FS, Coherent FS
+                    unsigned short i_mode;
+                    unsigned short i_nlink;
+                    unsigned short i_uid;
+                    unsigned short i_gid;
+                    unsigned long  i_size;
+                    unsigned char  i_zone[3*(10+1+1+1)];
+                    unsigned long  i_atime;
+                    unsigned long  i_mtime;
+                    unsigned long  i_ctime;
+
+* Regular file data blocks are organized as
+  - Minix FS
+               7 direct blocks
+               1 indirect block (pointers to blocks)
+               1 double-indirect block (pointer to pointers to blocks)
+  - Xenix FS, SystemV FS, Coherent FS
+              10 direct blocks
+               1 indirect block (pointers to blocks)
+               1 double-indirect block (pointer to pointers to blocks)
+               1 triple-indirect block (pointer to pointers to pointers to blocks)
+
+* Inode size, inodes per block
+  - Minix FS        32   32
+  - Xenix FS        64   16
+  - SystemV FS      64   16
+  - Coherent FS     64    8
+
+* Directory entry on disk
+  - Minix FS
+                    unsigned short inode;
+                    char name[14/30];
+  - Xenix FS, SystemV FS, Coherent FS
+                    unsigned short inode;
+                    char name[14];
+
+* Dir entry size, dir entries per block
+  - Minix FS     16/32    64/32
+  - Xenix FS     16       64
+  - SystemV FS   16       64
+  - Coherent FS  16       32
+
+* How to implement symbolic links such that the host fsck doesn't scream:
+  - Minix FS     normal
+  - Xenix FS     kludge: as regular files with  chmod 1000
+  - SystemV FS   ??
+  - Coherent FS  kludge: as regular files with  chmod 1000
 
-Bruno Haible
-<haible@ma2s2.mathematik.uni-karlsruhe.de>
 
+Notation: We often speak of a "block" but mean a zone (the allocation unit)
+and not the disk driver's notion of "block".
diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt
index 511b4230c053..fde829a756e6 100644
--- a/Documentation/filesystems/udf.txt
+++ b/Documentation/filesystems/udf.txt
@@ -7,8 +7,17 @@ If you encounter problems with reading UDF discs using this driver,
 please report them to linux_udf@hpesjro.fc.hp.com, which is the
 developer's list.
 
-Write support requires a block driver which supports writing. The current
-scsi and ide cdrom drivers do not support writing.
+Write support requires a block driver which supports writing.  Currently
+dvd+rw drives and media support true random sector writes, and so a udf
+filesystem on such devices can be directly mounted read/write.  CD-RW
+media however, does not support this.  Instead the media can be formatted
+for packet mode using the utility cdrwtool, then the pktcdvd driver can
+be bound to the underlying cd device to provide the required buffering
+and read-modify-write cycles to allow the filesystem random sector writes
+while providing the hardware with only full packet writes.  While not
+required for dvd+rw media, use of the pktcdvd driver often enhances
+performance due to very poor read-modify-write support supplied internally
+by drive firmware.
 
 -------------------------------------------------------------------------------
 The following mount options are supported:
diff --git a/Documentation/ftape.txt b/Documentation/ftape.txt
deleted file mode 100644
index 7d8bb3384031..000000000000
--- a/Documentation/ftape.txt
+++ /dev/null
@@ -1,307 +0,0 @@
-Intro
-=====
-
-This file describes some issues involved when using the "ftape"
-floppy tape device driver that comes with the Linux kernel.
-
-ftape has a home page at
-
-http://ftape.dot-heine.de/
-
-which contains further information about ftape. Please cross check
-this WWW address against the address given (if any) in the MAINTAINERS
-file located in the top level directory of the Linux kernel source
-tree.
-
-NOTE: This is an unmaintained set of drivers, and it is not guaranteed to work.
-If you are interested in taking over maintenance, contact Claus-Justus Heine
-<ch@dot-heine.de>, the former maintainer.
-
-Contents
-========
-
-A minus 1: Ftape documentation
-
-A. Changes
-   1. Goal
-   2. I/O Block Size
-   3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape)
-   4. Formatting
-   5. Interchanging cartridges with other operating systems
-
-B. Debugging Output
-   1. Introduction
-   2. Tuning the debugging output
-
-C. Boot and load time configuration
-   1. Setting boot time parameters
-   2. Module load time parameters
-   3. Ftape boot- and load time options
-   4. Example kernel parameter setting
-   5. Example module parameter setting
-
-D. Support and contacts
-
-*******************************************************************************
-
-A minus 1. Ftape documentation
-==============================
-
-Unluckily, the ftape-HOWTO is out of date. This really needs to be
-changed. Up to date documentation as well as recent development
-versions of ftape and useful links to related topics can be found at
-the ftape home page at
-
-http://ftape.dot-heine.de/
-
-*******************************************************************************
-
-A. Changes
-==========
-
-1. Goal
-   ~~~~
-   The goal of all that incompatibilities was to give ftape an interface
-   that resembles the interface provided by SCSI tape drives as close
-   as possible. Thus any Unix backup program that is known to work
-   with SCSI tape drives should also work.
-
-   The concept of a fixed block size for read/write transfers is
-   rather unrelated to this SCSI tape compatibility at the file system
-   interface level. It developed out of a feature of zftape, a
-   block wise user transparent on-the-fly compression. That compression
-   support will not be dropped in future releases for compatibility
-   reasons with previous releases of zftape.
-
-2. I/O Block Size
-   ~~~~~~~~~~~~~~
-   The block size defaults to 10k which is the default block size of
-   GNU tar.
-
-   The block size can be tuned either during kernel configuration or
-   at runtime with the MTIOCTOP ioctl using the MTSETBLK operation
-   (i.e. do "mt -f /dev/qft0" setblk #BLKSZ). A block size of 0
-   switches to variable block size mode i.e. "mt setblk 0" switches
-   off the block size restriction. However, this disables zftape's
-   built in on-the-fly compression which doesn't work with variable
-   block size mode.
-
-   The BLKSZ parameter must be given as a byte count and must be a
-   multiple of 32k or 0, i.e. use "mt setblk 32768" to switch to a
-   block size of 32k.
-
-   The typical symptom of a block size mismatch is an "invalid
-   argument" error message.
-
-3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape)
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-   zftape (the file system interface of ftape-3.x) denies write access
-   to the tape cartridge when it isn't positioned either at BOT or
-   EOD.
-
-4. Formatting
-   ~~~~~~~~~~
-   ftape DOES support formatting of floppy tape cartridges. You need the
-   `ftformat' program that is shipped with the modules version of ftape.
-   Please get the latest version of ftape from
-
-   ftp://sunsite.unc.edu/pub/Linux/kernel/tapes
-
-   or from the ftape home page at
-
-   http://ftape.dot-heine.de/
-
-   `ftformat' is contained in the `./contrib/' subdirectory of that
-   separate ftape package.
-
-5. Interchanging cartridges with other operating systems
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-   The internal emulation of Unix tape device file marks has changed
-   completely. ftape now uses the volume table segment as specified
-   by the QIC-40/80/3010/3020/113 standards to emulate file marks. As
-   a consequence there is limited support to interchange cartridges
-   with other operating systems.
-
-   To be more precise: ftape will detect volumes written by other OS's
-   programs and other OS's programs will detect volumes written by
-   ftape.
-
-   However, it isn't possible to extract the data dumped to the tape
-   by some MSDOS program with ftape. This exceeds the scope of a
-   kernel device driver. If you need such functionality, then go ahead
-   and write a user space utility that is able to do that. ftape already
-   provides all kernel level support necessary to do that.
-
-*******************************************************************************
-
-B. Debugging Output
-   ================
-
-1. Introduction
-   ~~~~~~~~~~~~
-   The ftape driver can be very noisy in that is can print lots of
-   debugging messages to the kernel log files and the system console.
-   While this is useful for debugging it might be annoying during
-   normal use and enlarges the size of the driver by several kilobytes.
-
-   To reduce the size of the driver you can trim the maximal amount of
-   debugging information available during kernel configuration. Please
-   refer to the kernel configuration script and its on-line help
-   functionality.
-
-   The amount of debugging output maps to the "tracing" boot time
-   option and the "ft_tracing" modules option as follows:
-
-   0              bugs
-   1              + errors (with call-stack dump)
-   2              + warnings
-   3              + information
-   4              + more information
-   5              + program flow
-   6              + fdc/dma info
-   7              + data flow
-   8              + everything else
-
-2. Tuning the debugging output
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-   To reduce the amount of debugging output printed to the system
-   console you can
-
-   i)  trim the debugging output at run-time with
-
-       mt -f /dev/nqft0 setdensity #DBGLVL
-
-       where "#DBGLVL" is a number between 0 and 9
-
-   ii) trim the debugging output at module load time with
-
-       modprobe ftape ft_tracing=#DBGLVL
-
-       Of course, this applies only if you have configured ftape to be
-       compiled as a module.
-
-   iii) trim the debugging output during system boot time. Add the
-       following to the kernel command line:
-
-       ftape=#DBGLVL,tracing
-
-       Please refer also to the next section if you don't know how to
-       set boot time parameters.
-
-*******************************************************************************
-
-C. Boot and load time configuration
-   ================================
-
-1. Setting boot time parameters
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
-   Assuming that you use lilo, the LI)nux LO)ader, boot time kernel
-   parameters can be set by adding a line
-
-   append some_kernel_boot_time_parameter
-
-   to `/etc/lilo.conf' or at real boot time by typing in the options
-   at the prompt provided by LILO. I can't give you advice on how to
-   specify those parameters with other loaders as I don't use them.
-
-   For ftape, each "some_kernel_boot_time_parameter" looks like
-   "ftape=value,option". As an example, the debugging output can be
-   increased with
-
-   ftape=4,tracing
-
-   NOTE: the value precedes the option name.
-
-2. Module load time parameters
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-   Module parameters can be specified either directly when invoking
-   the program 'modprobe' at the shell prompt:
-
-   modprobe ftape ft_tracing=4
-
-   or by editing the file `/etc/modprobe.conf' in which case they take
-   effect each time when the module is loaded with `modprobe' (please
-   refer to the respective manual pages). Thus, you should add a line
-
-   options ftape ft_tracing=4
-
-   to `/etc/modprobe.conf` if you intend to increase the debugging
-   output of the driver.
-
-
-3. Ftape boot- and load time options
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-   i.   Controlling the amount of debugging output
-        DBGLVL has to be replaced by a number between 0 and 8.
-
-        module                 |  kernel command line
-        -----------------------|----------------------
-        ft_tracing=DBGLVL      |  ftape=DBGLVL,tracing
-
-   ii.  Hardware setup
-        BASE is the base address of your floppy disk controller,
-        IRQ and DMA give its interrupt and DMA channel, respectively.
-        BOOL is an integer, "0" means "no"; any other value means
-        "yes". You don't need to specify anything if connecting your tape
-        drive to the standard floppy disk controller. All of these
-        values have reasonable defaults. The defaults can be modified
-        during kernel configuration, i.e. while running "make config",
-        "make menuconfig" or "make xconfig" in the top level directory
-        of the Linux kernel source tree. Please refer also to the on
-        line documentation provided during that kernel configuration
-        process.
-
-        ft_probe_fc10 is set to a non-zero value if you wish for ftape to
-        probe for a Colorado FC-10 or FC-20 controller.
-
-        ft_mach2 is set to a non-zero value if you wish for ftape to probe
-        for a Mountain MACH-2 controller.
-
-        module                 |  kernel command line
-        -----------------------|----------------------
-        ft_fdc_base=BASE       |  ftape=BASE,ioport
-        ft_fdc_irq=IRQ         |  ftape=IRQ,irq
-        ft_fdc_dma=DMA         |  ftape=DMA,dma
-        ft_probe_fc10=BOOL     |  ftape=BOOL,fc10
-        ft_mach2=BOOL          |  ftape=BOOL,mach2
-        ft_fdc_threshold=THR   |  ftape=THR,threshold
-        ft_fdc_rate_limit=RATE |  ftape=RATE,datarate
-
-4. Example kernel parameter setting
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
-   To configure ftape to probe for a Colorado FC-10/FC-20 controller
-   and to increase the amount of debugging output a little bit, add
-   the following line to `/etc/lilo.conf':
-
-   append ftape=1,fc10 ftape=4,tracing
-
-5. Example module parameter setting
-   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-   To do the same, but with ftape compiled as a loadable kernel
-   module, add the following line to `/etc/modprobe.conf':
-
-   options ftape ft_probe_fc10=1 ft_tracing=4
-
-*******************************************************************************
-
-D. Support and contacts
-   ====================
-
-   Ftape is distributed under the GNU General Public License. There is
-   absolutely no warranty for this software. However, you can reach
-   the current maintainer of the ftape package under the email address
-   given in the MAINTAINERS file which is located in the top level
-   directory of the Linux kernel source tree. There you'll find also
-   the relevant mailing list to use as a discussion forum and the web
-   page to query for the most recent documentation, related work and
-   development versions of ftape.
-
-   Changelog:
-   ==========
-
-~1996:          Original Document
-
-10-24-2004:     General cleanup and updating, noting additional module options.
-                James Nelson <james4765@gmail.com>
diff --git a/Documentation/fujitsu/frv/gdbstub.txt b/Documentation/fujitsu/frv/gdbstub.txt
index 6ce5aa9abbc5..9304fb36ae8a 100644
--- a/Documentation/fujitsu/frv/gdbstub.txt
+++ b/Documentation/fujitsu/frv/gdbstub.txt
@@ -59,7 +59,7 @@ the following things on the "Kernel Hacking" tab:
 Then build as usual, download to the board and execute. Note that if
 "Immediate activation" was selected, then the kernel will wait for GDB to
 attach. If not, then the kernel will boot immediately and GDB will have to
-interupt it or wait for an exception to occur if before doing anything with
+interrupt it or wait for an exception to occur before doing anything with
 the kernel.
 
 
diff --git a/Documentation/fujitsu/frv/kernel-ABI.txt b/Documentation/fujitsu/frv/kernel-ABI.txt
index 8b0a5fc8bfd9..aaa1cec86f0b 100644
--- a/Documentation/fujitsu/frv/kernel-ABI.txt
+++ b/Documentation/fujitsu/frv/kernel-ABI.txt
@@ -156,7 +156,7 @@ with the main kernel in this regard. Hence the debug mode code (gdbstub) is
 almost completely self-contained. The only external code used is the
 sprintf family of functions.
 
-Futhermore, break.S is so complicated because single-step mode does not
+Furthermore, break.S is so complicated because single-step mode does not
 switch off on entry to an exception. That means unless manually disabled,
 single-stepping will blithely go on stepping into things like interrupts.
 See gdbstub.txt for more information.
diff --git a/Documentation/hwmon/adm9240 b/Documentation/hwmon/adm9240
index 35f618f32896..2c6f1fed4618 100644
--- a/Documentation/hwmon/adm9240
+++ b/Documentation/hwmon/adm9240
@@ -24,7 +24,7 @@ Authors:
     Frodo Looijaard <frodol@dds.nl>,
     Philip Edelbrock <phil@netroedge.com>,
     Michiel Rook <michiel@grendelproject.nl>,
-    Grant Coady <gcoady@gmail.com> with guidance
+    Grant Coady <gcoady.lk@gmail.com> with guidance
         from Jean Delvare <khali@linux-fr.org>
 
 Interface
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f
index 28c5b7d1eb90..2ca69df669c3 100644
--- a/Documentation/hwmon/f71805f
+++ b/Documentation/hwmon/f71805f
@@ -17,7 +17,7 @@ Thanks to Kris Chen from Fintek for answering technical questions and
 providing additional documentation.
 
 Thanks to Chris Lin from Jetway for providing wiring schematics and
-anwsering technical questions.
+answering technical questions.
 
 
 Description
diff --git a/Documentation/hwmon/k8temp b/Documentation/hwmon/k8temp
index bab445ab0f52..30d123b8d920 100644
--- a/Documentation/hwmon/k8temp
+++ b/Documentation/hwmon/k8temp
@@ -2,7 +2,7 @@ Kernel driver k8temp
 ====================
 
 Supported chips:
-  * AMD K8 CPU
+  * AMD Athlon64/FX or Opteron CPUs
     Prefix: 'k8temp'
     Addresses scanned: PCI space
     Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
@@ -13,10 +13,13 @@ Contact: Rudolf Marek <r.marek@sh.cvut.cz>
 Description
 -----------
 
-This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
-Official documentation says that it works from revision F of K8 core, but
-in fact it seems to be implemented for all revisions of K8 except the first
-two revisions (SH-B0 and SH-B3).
+This driver permits reading temperature sensor(s) embedded inside AMD K8
+family CPUs (Athlon64/FX, Opteron). Official documentation says that it works
+from revision F of K8 core, but in fact it seems to be implemented for all
+revisions of K8 except the first two revisions (SH-B0 and SH-B3).
+
+Please note that you will need at least lm-sensors 2.10.1 for proper userspace
+support.
 
 There can be up to four temperature sensors inside single CPU. The driver
 will auto-detect the sensors and will display only temperatures from
diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1
index c15bbe68264e..04a11124f667 100644
--- a/Documentation/hwmon/smsc47m1
+++ b/Documentation/hwmon/smsc47m1
@@ -2,12 +2,14 @@ Kernel driver smsc47m1
 ======================
 
 Supported chips:
-  * SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192
+  * SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x,
+    LPC47M15x and LPC47M192
     Addresses scanned: none, address read from Super I/O config space
     Prefix: 'smsc47m1'
     Datasheets:
         http://www.smsc.com/main/datasheets/47b27x.pdf
         http://www.smsc.com/main/datasheets/47m10x.pdf
+        http://www.smsc.com/main/datasheets/47m112.pdf
         http://www.smsc.com/main/tools/discontinued/47m13x.pdf
         http://www.smsc.com/main/datasheets/47m14x.pdf
         http://www.smsc.com/main/tools/discontinued/47m15x.pdf
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf
index fae3b781d82d..caa610a297e8 100644
--- a/Documentation/hwmon/w83627ehf
+++ b/Documentation/hwmon/w83627ehf
@@ -26,7 +26,7 @@ fan control mode).
 Temperatures are measured in degrees Celsius and measurement resolution is 1
 degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
 the temperature gets higher than high limit; it stays on until the temperature
-falls below the Hysteresis value.
+falls below the hysteresis value.
 
 Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
 triggered if the rotation speed has dropped below a programmable limit. Fan
@@ -67,9 +67,9 @@ Thermal Cruise mode
 
 If the temperature is in the range defined by:
 
-pwm[1-4]_target    - set target temperature, unit millidegree Celcius
+pwm[1-4]_target    - set target temperature, unit millidegree Celsius
                      (range 0 - 127000)
-pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000)
+pwm[1-4]_tolerance - tolerance, unit millidegree Celsius (range 0 - 15000)
 
 there are no changes to fan speed. Once the temperature leaves the interval,
 fan speed increases (temp is higher) or decreases if lower than desired.
diff --git a/Documentation/i2c/busses/i2c-amd8111 b/Documentation/i2c/busses/i2c-amd8111
index db294ee7455a..460dd6635fd2 100644
--- a/Documentation/i2c/busses/i2c-amd8111
+++ b/Documentation/i2c/busses/i2c-amd8111
@@ -5,7 +5,7 @@ Supported adapters:
 
 Datasheets:
         AMD datasheet not yet available, but almost everything can be found
-        in publically available ACPI 2.0 specification, which the adapter 
+        in the publicly available ACPI 2.0 specification, which the adapter
         follows.
 
 Author: Vojtech Pavlik <vojtech@suse.cz>
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index e46c23458242..3db69a086c41 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -9,7 +9,10 @@ Supported adapters:
   * Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported)
   * Intel 6300ESB
   * Intel 82801FB/FR/FW/FRW (ICH6)
-  * Intel ICH7
+  * Intel 82801G (ICH7)
+  * Intel 631xESB/632xESB (ESB2)
+  * Intel 82801H (ICH8)
+  * Intel ICH9
     Datasheets: Publicly available at the Intel website
 
 Authors: 
diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2
index cd49c428a3ab..7f61fbc03f7f 100644
--- a/Documentation/i2c/busses/i2c-nforce2
+++ b/Documentation/i2c/busses/i2c-nforce2
@@ -10,11 +10,11 @@ Supported adapters:
   * nForce4 MCP51              10de:0264
   * nForce4 MCP55              10de:0368
 
-Datasheet: not publically available, but seems to be similar to the
+Datasheet: not publicly available, but seems to be similar to the
            AMD-8111 SMBus 2.0 adapter.
 
 Authors:
-        Hans-Frieder Vogt <hfvogt@arcor.de>, 
+        Hans-Frieder Vogt <hfvogt@gmx.net>,
         Thomas Leibold <thomas@plx.com>, 
         Patrick Dreker <patrick@dreker.de>
         
@@ -38,7 +38,7 @@ Notes
 -----
 
 The SMBus adapter in the nForce2 chipset seems to be very similar to the
-SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get
+SMBus 2.0 adapter in the AMD-8111 south bridge. However, I could only get
 the driver to work with direct I/O access, which is different to the EC
 interface of the AMD-8111. Tested on Asus A7N8X. The ACPI DSDT table of the
 Asus A7N8X lists two SMBuses, both of which are supported by this driver.
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index c51314b1a463..9575de300a61 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -2,7 +2,7 @@
                      ----------------------------
 
                     H. Peter Anvin <hpa@zytor.com>
-                        Last update 2005-09-02
+                        Last update 2006-11-17
 
 On the i386 platform, the Linux kernel uses a rather complicated boot
 convention.  This has evolved partially due to historical aspects, as
@@ -35,6 +35,8 @@ Protocol 2.03:	(Kernel 2.4.18-pre1) Explicitly makes the highest possible
                 initrd address available to the bootloader.
 
 Protocol 2.04:  (Kernel 2.6.14) Extend the syssize field to four bytes.
+Protocol 2.05:  (Kernel 2.6.20) Make protected mode kernel relocatable.
+                Introduce relocatable_kernel and kernel_alignment fields.
 
 
 **** MEMORY LAYOUT
@@ -129,6 +131,8 @@ Offset	Proto	Name		Meaning
 0226/2  N/A     pad1            Unused
 0228/4  2.02+   cmd_line_ptr    32-bit pointer to the kernel command line
 022C/4  2.03+   initrd_addr_max Highest legal initrd address
+0230/4  2.05+   kernel_alignment Physical addr alignment required for kernel
+0234/1  2.05+   relocatable_kernel Whether kernel is relocatable or not
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
diff --git a/Documentation/ide.txt b/Documentation/ide.txt
index 0bf38baa2db9..786c3a766995 100644
--- a/Documentation/ide.txt
+++ b/Documentation/ide.txt
@@ -390,5 +390,5 @@ mlord@pobox.com
 Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
 maintainer.
 
-Wed Aug 20 22:31:29 CEST 2003 updated ide boot uptions to current ide.c
+Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c
 comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv>
diff --git a/Documentation/input/amijoy.txt b/Documentation/input/amijoy.txt
index 4f0e89df5c51..7dc4f175943c 100644
--- a/Documentation/input/amijoy.txt
+++ b/Documentation/input/amijoy.txt
@@ -91,8 +91,8 @@ JOY1DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0     X7  X6  X5  X4  X3  X2  X1  X0
          |   1    | M0HQ     | JOY0DAT Horizontal Clock (quadrature)   |
          |   2    | M0V      | JOY0DAT Vertical Clock                  |
          |   3    | M0VQ     | JOY0DAT Vertical Clock  (quadrature)    |
-         |   4    | M1V      | JOY1DAT Horizontall Clock               |
-         |   5    | M1VQ     | JOY1DAT Horizontall Clock (quadrature)  |
+         |   4    | M1V      | JOY1DAT Horizontal Clock                |
+         |   5    | M1VQ     | JOY1DAT Horizontal Clock (quadrature)   |
          |   6    | M1V      | JOY1DAT Vertical Clock                  |
          |   7    | M1VQ     | JOY1DAT Vertical Clock (quadrature)     |
          +--------+----------+-----------------------------------------+
diff --git a/Documentation/input/atarikbd.txt b/Documentation/input/atarikbd.txt
index 1e7e5853ba4c..668f4d0d97d6 100644
--- a/Documentation/input/atarikbd.txt
+++ b/Documentation/input/atarikbd.txt
@@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
 
 5.1 Joystick Event Reporting
 
-In this mode, the ikbd generates a record whever the joystick position is
+In this mode, the ikbd generates a record whenever the joystick position is
 changed (i.e. for each opening or closing of a joystick switch or trigger).
 
 The joystick event record is two bytes of the form:
@@ -277,8 +277,8 @@ default to 1 at RESET (or power-up).
 9.7 SET MOUSE SCALE
 
     0x0C
-    X                   ; horizontal mouse ticks per internel X
-    Y                   ; vertical mouse ticks per internel Y
+    X                   ; horizontal mouse ticks per internal X
+    Y                   ; vertical mouse ticks per internal Y
 
 This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
 In this mode, the specified number of mouse phase changes ('clicks') must
@@ -323,7 +323,7 @@ mouse position.
     0x0F
 
 This command makes the origin of the Y axis to be at the bottom of the
-logical coordinate system internel to the ikbd for all relative or absolute
+logical coordinate system internal to the ikbd for all relative or absolute
 mouse motion. This causes mouse motion toward the user to be negative in sign
 and away from the user to be positive.
 
@@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
 
 10. SCAN CODES
 
-The key scan codes return by the ikbd are chosen to simplify the
-implementaion of GSX.
+The key scan codes returned by the ikbd are chosen to simplify the
+implementation of GSX.
 
 GSX Standard Keyboard Mapping.
 
diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt
index b9111a703ce0..5427bdf225ed 100644
--- a/Documentation/input/xpad.txt
+++ b/Documentation/input/xpad.txt
@@ -3,20 +3,37 @@ xpad - Linux USB driver for X-Box gamepads
 This is the very first release of a driver for X-Box gamepads.
 Basically, this was hacked away in just a few hours, so don't expect
 miracles.
+
 In particular, there is currently NO support for the rumble pack.
 You won't find many ff-aware linux applications anyway.
 
 
-0. Status
----------
+0. Notes
+--------
+
+Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.)
 
-For now, this driver has only been tested on just one Linux-Box.
-This one is running a 2.4.18 kernel with usb-uhci on an amd athlon 600.
+The number of buttons/axes reported varies based on 3 things:
+- if you are using a known controller
+- if you are using a known dance pad
+- if using an unknown device (one not listed below), what you set in the
+  module configuration for "Map D-PAD to buttons rather than axes for unknown
+  pads" (module option dpad_to_buttons)
 
-The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) reports
-8 axes and 10 buttons.
+If you set dpad_to_buttons to 0 and you are using an unknown device (one
+not listed below), the driver will map the directional pad to axes (X/Y),
+if you said N it will map the d-pad to buttons, which is needed for dance
+style games to function correctly.  The default is Y.
+
+dpad_to_buttons has no effect for known pads.
+
+0.1 Normal Controllers
+----------------------
+With a normal controller, the directional pad is mapped to its own X/Y axes.
+The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) will report 8
+axes and 10 buttons.
 
-Alls 8 axes work, though they all have the same range (-32768..32767)
+All 8 axes work, though they all have the same range (-32768..32767)
 and the zero-setting is not correct for the triggers (I don't know if that
 is some limitation of jstest, since the input device setup should be fine. I
 didn't have a look at jstest itself yet).
@@ -30,16 +47,50 @@ in game functionality were OK. However, I find it rather difficult to
 play first person shooters with a pad. Your mileage may vary.
 
 
+0.2 Xbox Dance Pads
+-------------------
+When using a known dance pad, jstest will report 6 axes and 14 buttons.
+
+For dance style pads (like the redoctane pad) several changes
+have been made.  The old driver would map the d-pad to axes, resulting
+in the driver being unable to report when the user was pressing both
+left+right or up+down, making DDR style games unplayable.
+
+Known dance pads automatically map the d-pad to buttons and will work
+correctly out of the box.
+
+If your dance pad is recognized by the driver but is using axes instead
+of buttons, see section 0.3 - Unknown Controllers
+
+I've tested this with Stepmania, and it works quite well.
+
+
+0.3 Unkown Controllers
+----------------------
+If you have an unkown xbox controller, it should work just fine with
+the default settings.
+
+HOWEVER if you have an unknown dance pad not listed below, it will not
+work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
+
+PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
+a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
+whether it is a dance pad or normal controller) so that we can add your pad
+to the list of supported devices, ensuring that it will work out of the
+box in the future.
+
+
 1. USB adapter
 --------------
 
 Before you can actually use the driver, you need to get yourself an
-adapter cable to connect the X-Box controller to your Linux-Box.
+adapter cable to connect the X-Box controller to your Linux-Box. You
+can buy these online fairly cheap, or build your own.
 
-Such a cable is pretty easy to build. The Controller itself is a USB compound
-device (a hub with three ports for two expansion slots and the controller
-device) with the only difference in a nonstandard connector (5 pins vs. 4 on
-standard USB connector).
+Such a cable is pretty easy to build. The Controller itself is a USB
+compound device (a hub with three ports for two expansion slots and
+the controller device) with the only difference in a nonstandard connector
+(5 pins vs. 4 on standard USB connector).
 
 You just need to solder a USB connector onto the cable and keep the
 yellow wire unconnected. The other pins have the same order on both
@@ -51,36 +102,36 @@ original one. You can buy an extension cable and cut that instead. That way,
 you can still use the controller with your X-Box, if you have one ;)
 
 
-2. driver installation
+2. Driver Installation
 ----------------------
 
 Once you have the adapter cable and the controller is connected, you need
 to load your USB subsystem and should cat /proc/bus/usb/devices.
 There should be an entry like the one at the end [4].
 
-Currently (as of version 0.0.4), the following three devices are included:
+Currently (as of version 0.0.6), the following devices are included:
  original Microsoft XBOX controller (US), vendor=0x045e, product=0x0202
+ smaller  Microsoft XBOX controller (US), vendor=0x045e, product=0x0289
  original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285
  InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a
+ RedOctane Xbox Dance Pad (US), vendor=0x0c12, product=0x8809
 
-If you have another controller that is not listed above and is not recognized
-by the driver, please drop me a line with the appropriate info (that is, include
-the name, vendor and product ID, as well as the country where you bought it;
-sending the whole dump out of /proc/bus/usb/devices along would be even better).
+The driver should work with xbox pads not listed above as well, however
+you will need to do something extra for dance pads to work.
 
-In theory, the driver should work with other controllers than mine
-(InterAct PowerPad pro, bought in Germany) just fine, but I cannot test this
-for I only have this one controller.
+If you have a controller not listed above, see 0.3 - Unknown Controllers
 
 If you compiled and installed the driver, test the functionality:
 > modprobe xpad
 > modprobe joydev
 > jstest /dev/js0
 
-There should be a single line showing 18 inputs (8 axes, 10 buttons), and
-it's values should change if you move the sticks and push the buttons.
+If you're using a normal controller, there should be a single line showing
+18 inputs (8 axes, 10 buttons), and its values should change if you move
+the sticks and push the buttons.  If you're using a dance pad, it should
+show 20 inputs (6 axes, 14 buttons).
 
-It works? Voila, your done ;)
+It works? Voila, you're done ;)
 
 
 3. Thanks
@@ -111,6 +162,22 @@ I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
 E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl= 10ms
 E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl= 10ms
 
+5. /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
+
+T:  Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12  MxCh= 0
+D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
+P:  Vendor=0c12 ProdID=8809 Rev= 0.01
+S:  Product=XBOX DDR
+C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
+I:  If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
+E:  Ad=82(I) Atr=03(Int.) MxPS=  32 Ivl=4ms
+E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=4ms
+
 -- 
 Marko Friedemann <mfr@bmx-chemnitz.de>
 2002-07-16
+ - original doc
+
+Dominic Cerquetti <binary1230@yahoo.com>
+2005-03-19
+ - added stuff for dance pads, new d-pad->axes mappings
diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt
index 0a8c97e87d47..5360e434486c 100644
--- a/Documentation/input/yealink.txt
+++ b/Documentation/input/yealink.txt
@@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
   888888888888
   Linux Rocks!
 
-Writing to /sys/../lineX will set the coresponding LCD line.
+Writing to /sys/../lineX will set the corresponding LCD line.
  - Excess characters are ignored.
  - If less characters are written than allowed, the remaining digits are
    unchanged.
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index edc04d74ae23..5a8bd5bd88ef 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -191,3 +191,5 @@ Code	Seq#	Include File		Comments
                                         <mailto:aherrman@de.ibm.com>
 0xF3    00-3F   video/sisfb.h           sisfb (in development)
                                         <mailto:thomas@winischhofer.net>
+0xF4    00-1F   video/mbxfb.h           mbxfb
+                                        <mailto:raph@8d.com>
diff --git a/Documentation/ioctl/cdrom.txt b/Documentation/ioctl/cdrom.txt
index 8ec32cc49eb1..62d4af44ec4a 100644
--- a/Documentation/ioctl/cdrom.txt
+++ b/Documentation/ioctl/cdrom.txt
@@ -735,7 +735,7 @@ CDROM_DISC_STATUS		Get disc type, etc.
             Ok, this is where problems start.  The current interface for
             the CDROM_DISC_STATUS ioctl is flawed.  It makes the false
             assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
-            Unfortunatly, while this is often the case, it is also
+            Unfortunately, while this is often the case, it is also
             very common for CDs to have some tracks with data, and some
             tracks with audio.  Just because I feel like it, I declare
             the following to be the best way to cope.  If the CD has
diff --git a/Documentation/ioctl/ioctl-decoding.txt b/Documentation/ioctl/ioctl-decoding.txt
new file mode 100644
index 000000000000..bfdf7f3ee4f0
--- /dev/null
+++ b/Documentation/ioctl/ioctl-decoding.txt
@@ -0,0 +1,24 @@
+To decode a hex IOCTL code:
+
+Most architecures use this generic format, but check
+include/ARCH/ioctl.h for specifics, e.g. powerpc
+uses 3 bits to encode read/write and 13 bits for size.
+
+ bits    meaning
+ 31-30  00 - no parameters: uses _IO macro
+        10 - read: _IOR
+        01 - write: _IOW
+        11 - read/write: _IOWR
+
+ 29-16  size of arguments
+
+ 15-8   ascii character supposedly
+        unique to each driver
+
+ 7-0    function #
+
+
+ So for example 0x82187201 is a read with arg length of 0x218,
+character 'r' function 1. Grepping the source reveals this is:
+
+#define VFAT_IOCTL_READDIR_BOTH         _IOR('r', 1, struct dirent [2])
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 50f4eddf899c..4b3d6710c504 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -227,9 +227,9 @@ more details, with real examples.
         be included in a library, lib.a.
         All objects listed with lib-y are combined in a single
         library for that directory.
-        Objects that are listed in obj-y and additionaly listed in
-        lib-y will not be included in the library, since they will anyway
-        be accessible.
+        Objects that are listed in obj-y and additionally listed in
+        lib-y will not be included in the library, since they will
+        be accessible anyway.
         For consistency, objects listed in lib-m will be included in lib.a.
 
         Note that the same kbuild makefile may list files to be built-in
@@ -535,7 +535,7 @@ Both possibilities are described in the following.
         Host programs can be made up based on composite objects.
         The syntax used to define composite objects for host programs is
         similar to the syntax used for kernel objects.
-        $(<executeable>-objs) lists all objects used to link the final
+        $(<executable>-objs) lists all objects used to link the final
         executable.
 
         Example:
@@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
         In this example, there are two possible targets, requiring different
         options to the linker. The linker options are specified using the
         LDFLAGS_$@ syntax - one for each potential target.
-        $(targets) are assinged all potential targets, by which kbuild knows
+        $(targets) are assigned all potential targets, by which kbuild knows
         the targets and will:
                 1) check for commandline changes
                 2) delete target during make clean
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index c65233d430f0..284e7e198e93 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -17,7 +17,7 @@ are:
   special place-holders for where the extracted documentation should
   go.
 
-- scripts/docproc.c
+- scripts/basic/docproc.c
 
   This is a program for converting SGML template files into SGML
   files. When a file is referenced it is searched for symbols
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index ff571f9298e0..d8323b8893c3 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -164,6 +164,10 @@ and is between 256 and 4096 characters. It is defined in the file
         acpi_skip_timer_override [HW,ACPI]
                         Recognize and ignore IRQ0/pin2 Interrupt Override.
                         For broken nForce2 BIOS resulting in XT-PIC timer.
+        acpi_use_timer_override [HW,ACPI}
+                        Use timer override. For some broken Nvidia NF5 boards
+                        that require a timer override, but don't have
+                        HPET
 
         acpi_dbg_layer= [HW,ACPI]
                         Format: <int>
@@ -544,6 +548,13 @@ and is between 256 and 4096 characters. It is defined in the file
         eurwdt=         [HW,WDT] Eurotech CPU-1220/1410 onboard watchdog.
                         Format: <io>[,<irq>]
 
+        failslab=
+        fail_page_alloc=
+        fail_make_request=[KNL]
+                        General fault injection mechanism.
+                        Format: <interval>,<probability>,<space>,<times>
+                        See also /Documentation/fault-injection/.
+
         fd_mcs=         [HW,SCSI]
                         See header of drivers/scsi/fd_mcs.c.
 
@@ -553,9 +564,6 @@ and is between 256 and 4096 characters. It is defined in the file
         floppy=         [HW]
                         See Documentation/floppy.txt.
 
-        ftape=          [HW] Floppy Tape subsystem debugging options.
-                        See Documentation/ftape.txt.
-
         gamecon.map[2|3]=
                         [HW,JOY] Multisystem joystick and NES/SNES/PSX pad
                         support via parallel port (up to 5 devices per port)
@@ -598,8 +606,6 @@ and is between 256 and 4096 characters. It is defined in the file
 
         hugepages=      [HW,IA-32,IA-64] Maximal number of HugeTLB pages.
 
-        noirqbalance    [IA-32,SMP,KNL] Disable kernel irq balancing
-
         i8042.direct    [HW] Put keyboard port into non-translated mode
         i8042.dumbkbd   [HW] Pretend that controller can only read data from
                              keyboard and cannot control its state
@@ -649,6 +655,10 @@ and is between 256 and 4096 characters. It is defined in the file
         idle=           [HW]
                         Format: idle=poll or idle=halt
 
+        ignore_loglevel [KNL]
+                        Ignore loglevel setting - this will print /all/
+                        kernel messages to the console. Useful for debugging.
+
         ihash_entries=  [KNL]
                         Set number of hash buckets for inode cache.
 
@@ -713,7 +723,12 @@ and is between 256 and 4096 characters. It is defined in the file
                         Format: <RDP>,<reset>,<pci_scan>,<verbosity>
 
         isolcpus=       [KNL,SMP] Isolate CPUs from the general scheduler.
-                        Format: <cpu number>,...,<cpu number>
+                        Format:
+                        <cpu number>,...,<cpu number>
+                        or
+                        <cpu number>-<cpu number>  (must be a positive range in ascending order)
+                        or a mixture
+                        <cpu number>,...,<cpu number>-<cpu number>
                         This option can be used to specify one or more CPUs
                         to isolate from the general SMP balancing and scheduling
                         algorithms. The only way to move a process onto or off
@@ -1011,6 +1026,10 @@ and is between 256 and 4096 characters. It is defined in the file
                         emulation library even if a 387 maths coprocessor
                         is present.
 
+        noaliencache    [MM, NUMA] Disables the allcoation of alien caches in
+                        the slab allocator.  Saves per-node memory, but will
+                        impact performance on real NUMA hardware.
+
         noalign         [KNL,ARM]
 
         noapic          [SMP,APIC] Tells the kernel to not make use of any
@@ -1051,9 +1070,14 @@ and is between 256 and 4096 characters. It is defined in the file
                         in certain environments such as networked servers or
                         real-time systems.
 
+        noirqbalance    [IA-32,SMP,KNL] Disable kernel irq balancing
+
         noirqdebug      [IA-32] Disables the code which attempts to detect and
                         disable unhandled interrupt sources.
 
+        no_timer_check  [IA-32,X86_64,APIC] Disables the code which tests for
+                        broken timer IRQ sources.
+
         noisapnp        [ISAPNP] Disables ISA PnP code.
 
         noinitrd        [RAM] Tells the kernel not to load any configured
@@ -1231,6 +1255,11 @@ and is between 256 and 4096 characters. It is defined in the file
                                 machine check when some devices' config space
                                 is read. But various workarounds are disabled
                                 and some IOMMU drivers will not work.
+                bfsort          Sort PCI devices into breadth-first order.
+                                This sorting is done to get a device
+                                order compatible with older (<= 2.4) kernels.
+                nobfsort        Don't sort PCI devices into breadth-first order.
+
         pcmv=           [HW,PCMCIA] BadgePAD 4
 
         pd.             [PARIDE]
@@ -1279,6 +1308,7 @@ and is between 256 and 4096 characters. It is defined in the file
                         Param: "schedule" - profile schedule points.
                         Param: <number> - step/bucket size as a power of 2 for
                                 statistical time based profiling.
+                        Param: "sleep" - profile D-state sleeping (millisecs)
 
         processor.max_cstate=   [HW,ACPI]
                         Limit processor to maximum C-state
@@ -1360,6 +1390,12 @@ and is between 256 and 4096 characters. It is defined in the file
         resume=         [SWSUSP]
                         Specify the partition device for software suspend
 
+        resume_offset=  [SWSUSP]
+                        Specify the offset from the beginning of the partition
+                        given by "resume=" at which the swap header is located,
+                        in <PAGE_SIZE> units (needed only for swap files).
+                        See  Documentation/power/swsusp-and-swap-files.txt
+
         rhash_entries=  [KNL,NET]
                         Set number of hash buckets for route cache
 
@@ -1410,6 +1446,11 @@ and is between 256 and 4096 characters. It is defined in the file
 
         scsi_logging=   [SCSI]
 
+        scsi_mod.scan=  [SCSI] sync (default) scans SCSI busses as they are
+                        discovered.  async scans them in kernel threads,
+                        allowing boot to proceed.  none ignores them, expecting
+                        user space to do the scan.
+
         selinux         [SELINUX] Disable or enable SELinux at boot time.
                         Format: { "0" | "1" }
                         See security/selinux/Kconfig help text.
@@ -1721,6 +1762,9 @@ and is between 256 and 4096 characters. It is defined in the file
         norandmaps      Don't use address space randomization
                         Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
 
+        unwind_debug=N  N > 0 will enable dwarf2 unwinder debugging
+                        This is useful to get more information why
+                        you got a "dwarf2 unwinder stuck"
 
 ______________________________________________________________________
 
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 3da586bc7859..60c665d9cfaa 100644
--- a/Documentation/keys.txt
+++ b/Documentation/keys.txt
@@ -304,7 +304,7 @@ about the status of the key service:
         R       Revoked
         D       Dead
         Q       Contributes to user's quota
-        U       Under contruction by callback to userspace
+        U       Under construction by callback to userspace
         N       Negative key
 
      This file must be enabled at kernel configuration time as it allows anyone
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index ba26201d5023..d71fafffce90 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -442,9 +442,10 @@ static int __init kprobe_init(void)
         kp.fault_handler = handler_fault;
         kp.symbol_name = "do_fork";
 
-        if ((ret = register_kprobe(&kp) < 0)) {
+        ret = register_kprobe(&kp);
+        if (ret < 0) {
                 printk("register_kprobe failed, returned %d\n", ret);
-                return -1;
+                return ret;
         }
         printk("kprobe registered\n");
         return 0;
diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt
index c487186eb2b9..6f639e3473af 100644
--- a/Documentation/laptop-mode.txt
+++ b/Documentation/laptop-mode.txt
@@ -121,7 +121,7 @@ contains the following options:
 MAX_AGE:
 
 Maximum time, in seconds, of hard drive spindown time that you are
-confortable with. Worst case, it's possible that you could lose this
+comfortable with. Worst case, it's possible that you could lose this
 amount of work if your battery fails while you're in laptop mode.
 
 MINIMUM_BATTERY_MINUTES:
@@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
 
 --------------------CONFIG FILE BEGIN-------------------------------------------
 # Maximum time, in seconds, of hard drive spindown time that you are
-# confortable with. Worst case, it's possible that you could lose this
+# comfortable with. Worst case, it's possible that you could lose this
 # amount of work if your battery fails you while in laptop mode.
 #MAX_AGE=600
 
@@ -350,7 +350,7 @@ fi
 # set defaults instead:
 
 # Maximum time, in seconds, of hard drive spindown time that you are
-# confortable with. Worst case, it's possible that you could lose this
+# comfortable with. Worst case, it's possible that you could lose this
 # amount of work if your battery fails you while in laptop mode.
 MAX_AGE=${MAX_AGE:-'600'}
 
@@ -699,7 +699,7 @@ ACPI integration
 Dax Kelson submitted this so that the ACPI acpid daemon will
 kick off the laptop_mode script and run hdparm. The part that
 automatically disables laptop mode when the battery is low was
-writen by Jan Topinski.
+written by Jan Topinski.
 
 -----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
 event=ac_adapter
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 994355b0cd19..58408dd023c7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU:
 
         STORE *X = c, d = LOAD *X
 
-     (Loads and stores overlap if they are targetted at overlapping pieces of
+     (Loads and stores overlap if they are targeted at overlapping pieces of
      memory).
 
 And there are a number of things that _must_ or _must_not_ be assumed:
@@ -1016,7 +1016,7 @@ There are some more advanced barrier functions:
 
  (*) set_mb(var, value)
 
-     This assigns the value to the variable and then inserts at least a write
+     This assigns the value to the variable and then inserts a full memory
      barrier after it, depending on the function.  It isn't guaranteed to
      insert anything more than a compiler barrier in a UP compilation.
 
@@ -1898,7 +1898,7 @@ queue before processing any further requests:
         smp_wmb();
         <A:modify v=2>  <C:busy>
                         <C:queue v=2>
-        p = &b;         q = p;
+        p = &v;         q = p;
                         <D:request p>
         <B:modify p=&v> <D:commit p=&v>
                         <D:read p>
diff --git a/Documentation/mips/time.README b/Documentation/mips/time.README
index 69ddc5c14b79..a4ce603ed3b3 100644
--- a/Documentation/mips/time.README
+++ b/Documentation/mips/time.README
@@ -38,19 +38,14 @@ The new time code provide the following services:
 
   a) Implements functions required by Linux common code:
         time_init
-        do_gettimeofday
-        do_settimeofday
 
   b) provides an abstraction of RTC and null RTC implementation as default.
         extern unsigned long (*rtc_get_time)(void);
         extern int (*rtc_set_time)(unsigned long);
 
-  c) a set of gettimeoffset functions for different CPUs and different
-     needs.
-
-  d) high-level and low-level timer interrupt routines where the timer 
-     interrupt source  may or may not be the CPU timer.  The high-level 
-     routine is dispatched through do_IRQ() while the low-level is 
+  c) high-level and low-level timer interrupt routines where the timer
+     interrupt source  may or may not be the CPU timer.  The high-level
+     routine is dispatched through do_IRQ() while the low-level is
      dispatched in assemably code (usually int-handler.S)
 
 
@@ -63,7 +58,7 @@ the following functions or values:
   a) board_time_init - a function pointer.  Invoked at the beginnig of
      time_init().  It is optional.
         1. (optional) set up RTC routines
-        2. (optional) calibrate and set the mips_counter_frequency
+        2. (optional) calibrate and set the mips_hpt_frequency
 
   b) plat_timer_setup - a function pointer.  Invoked at the end of time_init()
         1. (optional) over-ride any decisions made in time_init()
@@ -72,9 +67,8 @@ the following functions or values:
 
   c) (optional) board-specific RTC routines.
 
-  d) (optional) mips_counter_frequency - It must be definied if the board
-     is using CPU counter for timer interrupt or it is using fixed rate
-     gettimeoffset().
+  d) (optional) mips_hpt_frequency - It must be definied if the board
+     is using CPU counter for timer interrupt.
 
 
 PORTING GUIDE
@@ -89,22 +83,12 @@ Step 1: decide how you like to implement the time services.
      If the answer is no, you need a timer to provide the timer interrupt
      at 100 HZ speed.
 
-     You cannot use the fast gettimeoffset functions, i.e.,
-
-        unsigned long fixed_rate_gettimeoffset(void);
-        unsigned long calibrate_div32_gettimeoffset(void);
-        unsigned long calibrate_div64_gettimeoffset(void);
-
-    You can use null_gettimeoffset() will gives the same time resolution as
-    jiffy.  Or you can implement your own gettimeoffset (probably based on 
-    some ad hoc hardware on your machine.)
-
   c) The following sub steps assume your CPU has counter register.
      Do you plan to use the CPU counter register as the timer interrupt
      or use an exnternal timer?
 
      In order to use CPU counter register as the timer interrupt source, you
-     must know the counter speed (mips_counter_frequency).  It is usually the
+     must know the counter speed (mips_hpt_frequency).  It is usually the
      same as the CPU speed or an integral divisor of it.
 
   d) decide on whether you want to use high-level or low-level timer
@@ -121,10 +105,10 @@ Step 3: implement rtc routines, board_time_init() and plat_timer_setup()
   if needed.
 
   board_time_init() -
-        a) (optional) set up RTC routines, 
-        b) (optional) calibrate and set the mips_counter_frequency
-            (only needed if you intended to use fixed_rate_gettimeoffset
-             or use cpu counter as timer interrupt source)
+        a) (optional) set up RTC routines,
+        b) (optional) calibrate and set the mips_hpt_frequency
+            (only needed if you intended to use cpu counter as timer interrupt
+             source)
 
   plat_timer_setup() -
         a) (optional) over-write any choices made above by time_init().
@@ -154,8 +138,8 @@ for some of the functions in time.c.
 For example, you may define your own timer interrupt routine, which does
 some of its own processing and then calls timer_interrupt().
 
-You can also over-ride any of the built-in functions (gettimeoffset,
-RTC routines and/or timer interrupt routine).
+You can also over-ride any of the built-in functions (RTC routines
+and/or timer interrupt routine).
 
 
 PORTING NOTES FOR SMP
@@ -187,10 +171,3 @@ You need to decide on your timer interrupt sources.
 
         You can also do the low-level version of those interrupt routines,
         following similar dispatching routes described above.
-
-Note about do_gettimeoffset():
-
-  It is very likely the CPU counter registers are not sync'ed up in a SMP box.
-  Therefore you cannot really use the many of the existing routines that
-  are based on CPU counter.  You should wirte your own gettimeoffset rouinte
-  if you want intra-jiffy resolution.
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index b1181ce232d9..e06b6e3c1db5 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -58,6 +58,8 @@ fore200e.txt
         - FORE Systems PCA-200E/SBA-200E ATM NIC driver info.
 framerelay.txt
         - info on using Frame Relay/Data Link Connection Identifier (DLCI).
+generic_netlink.txt
+        - info on Generic Netlink
 ip-sysctl.txt
         - /proc/sys/net/ipv4/* variables
 ip_dynaddr.txt
diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt
index 93af3e87c65b..fb8dc6422a52 100644
--- a/Documentation/networking/NAPI_HOWTO.txt
+++ b/Documentation/networking/NAPI_HOWTO.txt
@@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
                 Move all to dev->poll()
 
 C) Ability to detect new work correctly.
-NAPI works by shutting down event interrupts when theres work and
-turning them on when theres none. 
+NAPI works by shutting down event interrupts when there's work and
+turning them on when there's none. 
 New packets might show up in the small window while interrupts were being 
 re-enabled (refer to appendix 2).  A packet might sneak in during the period 
 we are enabling interrupts. We only get to know about such a packet when the 
@@ -114,7 +114,7 @@ Locking rules and environmental guarantees
 only one CPU can pick the initial interrupt and hence the initial
 netif_rx_schedule(dev);
 - The core layer invokes devices to send packets in a round robin format.
-This implies receive is totaly lockless because of the guarantee only that 
+This implies receive is totally lockless because of the guarantee that only 
 one CPU is executing it.
 -  contention can only be the result of some other CPU accessing the rx
 ring. This happens only in close() and suspend() (when these methods
@@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget)
                         an interrupt will be generated */
                         goto done;
         }
-        /* done! at least thats what it looks like ;->
+        /* done! at least that's what it looks like ;->
         if new packets came in after our last check on status bits
         they'll be caught by the while check and we go back and clear them 
         since we havent exceeded our quota */
@@ -535,11 +535,11 @@ done:
         * 1. it can race with disabling irqs in irq handler (which are done to 
         * schedule polls)
         * 2. it can race with dis/enabling irqs in other poll threads
-        * 3. if an irq raised after the begining of the outer  beginning 
-        * loop(marked in the code above), it will be immediately
+        * 3. if an irq raised after the beginning of the outer beginning 
+        * loop (marked in the code above), it will be immediately
         * triggered here.
         *
-        * Summarizing: the logic may results in some redundant irqs both
+        * Summarizing: the logic may result in some redundant irqs both
         * due to races in masking and due to too late acking of already
         * processed irqs. The good news: no events are ever lost.
         */
@@ -601,7 +601,7 @@ a)
         
 5) dev->close() and dev->suspend() issues
 ==========================================
-The driver writter neednt worry about this. The top net layer takes
+The driver writer needn't worry about this; the top net layer takes
 care of it.
 
 6) Adding new Stats to /proc 
@@ -622,9 +622,9 @@ FC should be programmed to apply in the case when the system cant pull out
 packets fast enough i.e send a pause only when you run out of rx buffers.
 Note FC in itself is a good solution but we have found it to not be
 much of a commodity feature (both in NICs and switches) and hence falls
-under the same category as using NIC based mitigation. Also experiments
-indicate that its much harder to resolve the resource allocation
-issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
+under the same category as using NIC based mitigation. Also, experiments
+indicate that it's much harder to resolve the resource allocation
+issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
 proved harder. In any case, FC works even better with NAPI but is not
 necessary.
 
@@ -678,10 +678,10 @@ routine:
 CSR5 bit of interest is only the rx status. 
 If you look at the last if statement: 
 you just finished grabbing all the packets from the rx ring .. you check if
-status bit says theres more packets just in ... it says none; you then
+status bit says there are more packets just in ... it says none; you then
 enable rx interrupts again; if a new packet just came in during this check,
 we are counting that CSR5 will be set in that small window of opportunity
-and that by re-enabling interrupts, we would actually triger an interrupt
+and that by re-enabling interrupts, we would actually trigger an interrupt
 to register the new packet for processing.
 
 [The above description nay be very verbose, if you have better wording 
diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt
index 64896470e279..6387d3decf85 100644
--- a/Documentation/networking/cs89x0.txt
+++ b/Documentation/networking/cs89x0.txt
@@ -248,7 +248,7 @@ c) The driver's hardware probe routine is designed to avoid
    with device probing.  To avoid this behaviour, add one
    to the `io=' module parameter.  This doesn't actually change
    the I/O address, but it is a flag to tell the driver
-   topartially initialise the hardware before trying to
+   to partially initialise the hardware before trying to
    identify the card.  This could be dangerous if you are
    not sure that there is a cs89x0 card at the provided address.
 
@@ -620,8 +620,8 @@ I/O Address    	Device                        IRQ      Device
                                                 12       Mouse (PS/2)                              
 Memory Address  Device                          13       Math Coprocessor
 --------------  ---------------------           14       Hard Disk controller
-A000-BFFF       EGA Graphics Adpater
-A000-C7FF       VGA Graphics Adpater
+A000-BFFF       EGA Graphics Adapter
+A000-C7FF       VGA Graphics Adapter
 B000-BFFF       Mono Graphics Adapter
 B800-BFFF       Color Graphics Adapter
 E000-FFFF       AT BIOS
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
index 74563b38ffd9..387482e46c47 100644
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -19,40 +19,92 @@ for real time and multimedia traffic.
 
 It has a base protocol and pluggable congestion control IDs (CCIDs).
 
-It is at draft RFC status and the homepage for DCCP as a protocol is at:
-        http://www.icir.org/kohler/dcp/
+It is at proposed standard RFC status and the homepage for DCCP as a protocol
+is at:
+        http://www.read.cs.ucla.edu/dccp/
 
 Missing features
 ================
 
 The DCCP implementation does not currently have all the features that are in
-the draft RFC.
+the RFC.
 
-In particular the following are missing:
-- CCID2 support
-- feature negotiation
-
-When testing against other implementations it appears that elapsed time
-options are not coded compliant to the specification.
+The known bugs are at:
+        http://linux-net.osdl.org/index.php/TODO#DCCP
 
 Socket options
 ==============
 
-DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for
-calculations.
-
 DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
 service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
 the socket will fall back to 0 (which means that no meaningful service code
 is present). Connecting sockets set at most one service option; for
 listening sockets, multiple service codes can be specified.
 
+DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
+partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
+always cover the entire packet and that only fully covered application data is
+accepted by the receiver. Hence, when using this feature on the sender, it must
+be enabled at the receiver, too with suitable choice of CsCov.
+
+DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
+        range 0..15 are acceptable. The default setting is 0 (full coverage),
+        values between 1..15 indicate partial coverage.
+DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
+        sets a threshold, where again values 0..15 are acceptable. The default
+        of 0 means that all packets with a partial coverage will be discarded.
+        Values in the range 1..15 indicate that packets with minimally such a
+        coverage value are also acceptable. The higher the number, the more
+        restrictive this setting (see [RFC 4340, sec. 9.2.1]).
+
+Sysctl variables
+================
+Several DCCP default parameters can be managed by the following sysctls
+(sysctl net.dccp.default or /proc/sys/net/dccp/default):
+
+request_retries
+        The number of active connection initiation retries (the number of
+        Requests minus one) before timing out. In addition, it also governs
+        the behaviour of the other, passive side: this variable also sets
+        the number of times DCCP repeats sending a Response when the initial
+        handshake does not progress from RESPOND to OPEN (i.e. when no Ack
+        is received after the initial Request).  This value should be greater
+        than 0, suggested is less than 10. Analogue of tcp_syn_retries.
+
+retries1
+        How often a DCCP Response is retransmitted until the listening DCCP
+        side considers its connecting peer dead. Analogue of tcp_retries1.
+
+retries2
+        The number of times a general DCCP packet is retransmitted. This has
+        importance for retransmitted acknowledgments and feature negotiation,
+        data packets are never retransmitted. Analogue of tcp_retries2.
+
+send_ndp = 1
+        Whether or not to send NDP count options (sec. 7.7.2).
+
+send_ackvec = 1
+        Whether or not to send Ack Vector options (sec. 11.5).
+
+ack_ratio = 2
+        The default Ack Ratio (sec. 11.3) to use.
+
+tx_ccid = 2
+        Default CCID for the sender-receiver half-connection.
+
+rx_ccid = 2
+        Default CCID for the receiver-sender half-connection.
+
+seq_window = 100
+        The initial sequence window (sec. 7.5.2).
+
+tx_qlen = 5
+        The size of the transmit buffer in packets. A value of 0 corresponds
+        to an unbounded transmit buffer.
+
 Notes
 =====
 
-SELinux does not yet have support for DCCP. You will need to turn it off or
-else you will get EACCES.
-
-DCCP does not travel through NAT successfully at present. This is because
-the checksum covers the psuedo-header as per TCP and UDP. It should be
-relatively trivial to add Linux NAT support for DCCP.
+DCCP does not travel through NAT successfully at present on many boxes. This is
+because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
+support for DCCP has been added.
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
index 5c0a5cc03998..61b171cf5313 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.txt
@@ -1,7 +1,7 @@
 Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
 ===============================================================
 
-November 15, 2005
+September 26, 2006
 
 
 Contents
@@ -9,6 +9,7 @@ Contents
 
 - In This Release
 - Identifying Your Adapter
+- Building and Installation
 - Command Line Parameters
 - Speed and Duplex Configuration
 - Additional Configurations
@@ -41,6 +42,9 @@ or later), lspci, and ifconfig to obtain the same information.
 Instructions on updating ethtool can be found in the section "Additional
 Configurations" later in this document.
 
+NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
+support.
+
 
 Identifying Your Adapter
 ========================
@@ -51,28 +55,27 @@ Driver ID Guide at:
     http://support.intel.com/support/network/adapter/pro100/21397.htm
 
 For the latest Intel network drivers for Linux, refer to the following
-website. In the search field, enter your adapter name or type, or use the
+website.  In the search field, enter your adapter name or type, or use the
 networking link on the left to search for your adapter:
 
     http://downloadfinder.intel.com/scripts-df/support_intel.asp
 
 
-Command Line Parameters =======================
+Command Line Parameters
+=======================
 
 If the driver is built as a module, the  following optional parameters
-are used by entering them on the command line with the modprobe or insmod
-command using this syntax:
+are used by entering them on the command line with the modprobe command
+using this syntax:
 
      modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
 
-     insmod e1000 [<option>=<VAL1>,<VAL2>,...]
-
 For example, with two PRO/1000 PCI adapters, entering:
 
-     insmod e1000 TxDescriptors=80,128
+     modprobe e1000 TxDescriptors=80,128
 
-loads the e1000 driver with 80 TX descriptors for the first adapter and 128
-TX descriptors for the second adapter.
+loads the e1000 driver with 80 TX descriptors for the first adapter and
+128 TX descriptors for the second adapter.
 
 The default value for each parameter is generally the recommended setting,
 unless otherwise noted.
@@ -87,7 +90,7 @@ NOTES:  For more information about the AutoNeg, Duplex, and Speed
         http://www.intel.com/design/network/applnots/ap450.htm
 
         A descriptor describes a data buffer and attributes related to
-        the data buffer. This information is accessed by the hardware.
+        the data buffer.  This information is accessed by the hardware.
 
 
 AutoNeg
@@ -96,9 +99,9 @@ AutoNeg
 Valid Range:   0x01-0x0F, 0x20-0x2F
 Default Value: 0x2F
 
-This parameter is a bit mask that specifies which speed and duplex
-settings the board advertises. When this parameter is used, the Speed
-and Duplex parameters must not be specified.
+This parameter is a bit-mask that specifies the speed and duplex settings
+advertised by the adapter.  When this parameter is used, the Speed and
+Duplex parameters must not be specified.
 
 NOTE:  Refer to the Speed and Duplex section of this readme for more
        information on the AutoNeg parameter.
@@ -110,14 +113,15 @@ Duplex
 Valid Range:   0-2 (0=auto-negotiate, 1=half, 2=full)
 Default Value: 0
 
-Defines the direction in which data is allowed to flow. Can be either
-one or two-directional. If both Duplex and the link partner are set to
-auto-negotiate, the board auto-detects the correct duplex. If the link
-partner is forced (either full or half), Duplex defaults to half-duplex.
+This defines the direction in which data is allowed to flow.  Can be
+either one or two-directional.  If both Duplex and the link partner are
+set to auto-negotiate, the board auto-detects the correct duplex.  If the
+link partner is forced (either full or half), Duplex defaults to half-
+duplex.
 
 
 FlowControl
-----------
+-----------
 Valid Range:   0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
 Default Value: Reads flow control settings from the EEPROM
 
@@ -127,57 +131,107 @@ to Ethernet PAUSE frames.
 
 InterruptThrottleRate
 ---------------------
-(not supported on Intel 82542, 82543 or 82544-based adapters)
-Valid Range:   100-100000 (0=off, 1=dynamic)
-Default Value: 8000
-
-This value represents the maximum number of interrupts per second the
-controller generates. InterruptThrottleRate is another setting used in
-interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
-InterruptThrottleRate based on the current traffic load.
+(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
+Valid Range:   0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
+Default Value: 3
+
+The driver can limit the amount of interrupts per second that the adapter
+will generate for incoming packets. It does this by writing a value to the 
+adapter that is based on the maximum amount of interrupts that the adapter 
+will generate per second.
+
+Setting InterruptThrottleRate to a value greater or equal to 100
+will program the adapter to send out a maximum of that many interrupts
+per second, even if more packets have come in. This reduces interrupt
+load on the system and can lower CPU utilization under heavy load,
+but will increase latency as packets are not processed as quickly.
+
+The default behaviour of the driver previously assumed a static 
+InterruptThrottleRate value of 8000, providing a good fallback value for 
+all traffic types,but lacking in small packet performance and latency. 
+The hardware can handle many more small packets per second however, and 
+for this reason an adaptive interrupt moderation algorithm was implemented.
+
+Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
+it dynamically adjusts the InterruptThrottleRate value based on the traffic 
+that it receives. After determining the type of incoming traffic in the last
+timeframe, it will adjust the InterruptThrottleRate to an appropriate value 
+for that traffic.
+
+The algorithm classifies the incoming traffic every interval into
+classes.  Once the class is determined, the InterruptThrottleRate value is 
+adjusted to suit that traffic type the best. There are three classes defined: 
+"Bulk traffic", for large amounts of packets of normal size; "Low latency",
+for small amounts of traffic and/or a significant percentage of small
+packets; and "Lowest latency", for almost completely small packets or 
+minimal traffic.
+
+In dynamic conservative mode, the InterruptThrottleRate value is set to 4000 
+for traffic that falls in class "Bulk traffic". If traffic falls in the "Low 
+latency" or "Lowest latency" class, the InterruptThrottleRate is increased 
+stepwise to 20000. This default mode is suitable for most applications.
+
+For situations where low latency is vital such as cluster or
+grid computing, the algorithm can reduce latency even more when
+InterruptThrottleRate is set to mode 1. In this mode, which operates
+the same as mode 3, the InterruptThrottleRate will be increased stepwise to 
+70000 for traffic in class "Lowest latency".
+
+Setting InterruptThrottleRate to 0 turns off any interrupt moderation
+and may improve small packet latency, but is generally not suitable
+for bulk throughput traffic.
 
 NOTE:  InterruptThrottleRate takes precedence over the TxAbsIntDelay and
-       RxAbsIntDelay parameters. In other words, minimizing the receive
+       RxAbsIntDelay parameters.  In other words, minimizing the receive
        and/or transmit absolute delays does not force the controller to
        generate more interrupts than what the Interrupt Throttle Rate
        allows.
 
-CAUTION:  If you are using the Intel PRO/1000 CT Network Connection
+CAUTION:  If you are using the Intel(R) PRO/1000 CT Network Connection
           (controller 82547), setting InterruptThrottleRate to a value
           greater than 75,000, may hang (stop transmitting) adapters
-          under certain network conditions. If this occurs a NETDEV
-          WATCHDOG message is logged in the system event log. In
+          under certain network conditions.  If this occurs a NETDEV
+          WATCHDOG message is logged in the system event log.  In
           addition, the controller is automatically reset, restoring
-          the network connection. To eliminate the potential for the
+          the network connection.  To eliminate the potential for the
           hang, ensure that InterruptThrottleRate is set no greater
           than 75,000 and is not set to 0.
 
 NOTE:  When e1000 is loaded with default settings and multiple adapters
        are in use simultaneously, the CPU utilization may increase non-
-       linearly. In order to limit the CPU utilization without impacting
+       linearly.  In order to limit the CPU utilization without impacting
        the overall throughput, we recommend that you load the driver as
        follows:
 
-           insmod e1000.o InterruptThrottleRate=3000,3000,3000
+           modprobe e1000 InterruptThrottleRate=3000,3000,3000
 
        This sets the InterruptThrottleRate to 3000 interrupts/sec for
-       the first, second, and third instances of the driver. The range
+       the first, second, and third instances of the driver.  The range
        of 2000 to 3000 interrupts per second works on a majority of
        systems and is a good starting point, but the optimal value will
-       be platform-specific. If CPU utilization is not a concern, use
+       be platform-specific.  If CPU utilization is not a concern, use
        RX_POLLING (NAPI) and default driver settings.
 
 
+
 RxDescriptors
 -------------
 Valid Range:   80-256 for 82542 and 82543-based adapters
                80-4096 for all other supported adapters
 Default Value: 256
 
-This value specifies the number of receive descriptors allocated by the
-driver. Increasing this value allows the driver to buffer more incoming
-packets.  Each descriptor is 16 bytes.  A receive buffer is also
-allocated for each descriptor and is 2048.
+This value specifies the number of receive buffer descriptors allocated
+by the driver.  Increasing this value allows the driver to buffer more
+incoming packets, at the expense of increased system memory utilization.
+
+Each descriptor is 16 bytes.  A receive buffer is also allocated for each
+descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending 
+on the MTU setting. The maximum MTU size is 16110.
+
+NOTE:  MTU designates the frame size.  It only needs to be set for Jumbo 
+       Frames.  Depending on the available system resources, the request 
+       for a higher number of receive descriptors may be denied.  In this 
+       case, use a lower number.
 
 
 RxIntDelay
@@ -187,17 +241,17 @@ Default Value: 0
 
 This value delays the generation of receive interrupts in units of 1.024
 microseconds.  Receive interrupt reduction can improve CPU efficiency if
-properly tuned for specific network traffic. Increasing this value adds
+properly tuned for specific network traffic.  Increasing this value adds
 extra latency to frame reception and can end up decreasing the throughput
-of TCP traffic. If the system is reporting dropped receives, this value
+of TCP traffic.  If the system is reporting dropped receives, this value
 may be set too high, causing the driver to run out of available receive
 descriptors.
 
 CAUTION:  When setting RxIntDelay to a value other than 0, adapters may
-          hang (stop transmitting) under certain network conditions. If
+          hang (stop transmitting) under certain network conditions.  If
           this occurs a NETDEV WATCHDOG message is logged in the system
-          event log. In addition, the controller is automatically reset,
-          restoring the network connection. To eliminate the potential
+          event log.  In addition, the controller is automatically reset,
+          restoring the network connection.  To eliminate the potential
           for the hang ensure that RxIntDelay is set to 0.
 
 
@@ -208,7 +262,7 @@ Valid Range:   0-65535 (0=off)
 Default Value: 128
 
 This value, in units of 1.024 microseconds, limits the delay in which a
-receive interrupt is generated. Useful only if RxIntDelay is non-zero,
+receive interrupt is generated.  Useful only if RxIntDelay is non-zero,
 this value ensures that an interrupt is generated after the initial
 packet is received within the set amount of time.  Proper tuning,
 along with RxIntDelay, may improve traffic throughput in specific network
@@ -222,9 +276,9 @@ Valid Settings: 0, 10, 100, 1000
 Default Value:  0 (auto-negotiate at all supported speeds)
 
 Speed forces the line speed to the specified value in megabits per second
-(Mbps). If this parameter is not specified or is set to 0 and the link
+(Mbps).  If this parameter is not specified or is set to 0 and the link
 partner is set to auto-negotiate, the board will auto-detect the correct
-speed. Duplex should also be set when Speed is set to either 10 or 100.
+speed.  Duplex should also be set when Speed is set to either 10 or 100.
 
 
 TxDescriptors
@@ -234,7 +288,7 @@ Valid Range:   80-256 for 82542 and 82543-based adapters
 Default Value: 256
 
 This value is the number of transmit descriptors allocated by the driver.
-Increasing this value allows the driver to queue more transmits. Each
+Increasing this value allows the driver to queue more transmits.  Each
 descriptor is 16 bytes.
 
 NOTE:  Depending on the available system resources, the request for a
@@ -248,8 +302,8 @@ Valid Range:   0-65535 (0=off)
 Default Value: 64
 
 This value delays the generation of transmit interrupts in units of
-1.024 microseconds. Transmit interrupt reduction can improve CPU
-efficiency if properly tuned for specific network traffic. If the
+1.024 microseconds.  Transmit interrupt reduction can improve CPU
+efficiency if properly tuned for specific network traffic.  If the
 system is reporting dropped transmits, this value may be set too high
 causing the driver to run out of available transmit descriptors.
 
@@ -261,7 +315,7 @@ Valid Range:   0-65535 (0=off)
 Default Value: 64
 
 This value, in units of 1.024 microseconds, limits the delay in which a
-transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
+transmit interrupt is generated.  Useful only if TxIntDelay is non-zero,
 this value ensures that an interrupt is generated after the initial
 packet is sent on the wire within the set amount of time.  Proper tuning,
 along with TxIntDelay, may improve traffic throughput in specific
@@ -288,15 +342,15 @@ fiber interface board only links at 1000 Mbps full-duplex.
 
 For copper-based boards, the keywords interact as follows:
 
-  The default operation is auto-negotiate. The board advertises all
+  The default operation is auto-negotiate.  The board advertises all
   supported speed and duplex combinations, and it links at the highest
   common speed and duplex mode IF the link partner is set to auto-negotiate.
 
   If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
   is advertised (The 1000BaseT spec requires auto-negotiation.)
 
-  If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
-  negotiation is disabled, and the AutoNeg parameter is ignored. Partner
+  If Speed = 10 or 100, then both Speed and Duplex should be set.  Auto-
+  negotiation is disabled, and the AutoNeg parameter is ignored.  Partner
   SHOULD also be forced.
 
 The AutoNeg parameter is used when more control is required over the
@@ -304,7 +358,7 @@ auto-negotiation process.  It should be used when you wish to control which
 speed and duplex combinations are advertised during the auto-negotiation
 process.
 
-The parameter may be specified as either a decimal or hexidecimal value as
+The parameter may be specified as either a decimal or hexadecimal value as
 determined by the bitmap below.
 
 Bit position   7      6      5       4       3      2      1       0
@@ -337,20 +391,19 @@ Additional Configurations
 
   Configuring the Driver on Different Distributions
   -------------------------------------------------
-
   Configuring a network driver to load properly when the system is started
-  is distribution dependent. Typically, the configuration process involves
+  is distribution dependent.  Typically, the configuration process involves
   adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
-  as editing other system startup scripts and/or configuration files. Many
+  as editing other system startup scripts and/or configuration files.  Many
   popular Linux distributions ship with tools to make these changes for you.
   To learn the proper way to configure a network device for your system,
-  refer to your distribution documentation. If during this process you are
+  refer to your distribution documentation.  If during this process you are
   asked for the driver or module name, the name for the Linux Base Driver
-  for the Intel PRO/1000 Family of Adapters is e1000.
+  for the Intel(R) PRO/1000 Family of Adapters is e1000.
 
   As an example, if you install the e1000 driver for two PRO/1000 adapters
   (eth0 and eth1) and set the speed and duplex to 10full and 100half, add
-  the following to modules.conf or modprobe.conf:
+  the following to modules.conf or or modprobe.conf:
 
        alias eth0 e1000
        alias eth1 e1000
@@ -358,9 +411,8 @@ Additional Configurations
 
   Viewing Link Messages
   ---------------------
-
   Link messages will not be displayed to the console if the distribution is
-  restricting system messages. In order to see network driver link messages
+  restricting system messages.  In order to see network driver link messages
   on your console, set dmesg to eight by entering the following:
 
        dmesg -n 8
@@ -369,11 +421,9 @@ Additional Configurations
 
   Jumbo Frames
   ------------
-
-  The driver supports Jumbo Frames for all adapters except 82542 and
-  82573-based adapters. Jumbo Frames support is enabled by changing the
-  MTU to a value larger than the default of 1500. Use the ifconfig command
-  to increase the MTU size. For example:
+  Jumbo Frames support is enabled by changing the MTU to a value larger than
+  the default of 1500.  Use the ifconfig command to increase the MTU size.
+  For example:
 
        ifconfig eth<x> mtu 9000 up
 
@@ -390,26 +440,49 @@ Additional Configurations
 
   - To enable Jumbo Frames, increase the MTU size on the interface beyond
     1500.
-  - The maximum MTU setting for Jumbo Frames is 16110. This value coincides
+
+  - The maximum MTU setting for Jumbo Frames is 16110.  This value coincides
     with the maximum Jumbo Frames size of 16128.
+
   - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
     loss of link.
+
   - Some Intel gigabit adapters that support Jumbo Frames have a frame size
     limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes.
-    The adapters with this limitation are based on the Intel 82571EB and
-    82572EI controllers, which correspond to these product names:
-     Intel® PRO/1000 PT Dual Port Server Adapter
-     Intel® PRO/1000 PF Dual Port Server Adapter
-     Intel® PRO/1000 PT Server Adapter
-     Intel® PRO/1000 PT Desktop Adapter
-     Intel® PRO/1000 PF Server Adapter
-
-  - The Intel PRO/1000 PM Network Connection does not support jumbo frames.
+    The adapters with this limitation are based on the Intel(R) 82571EB,
+    82572EI, 82573L and 80003ES2LAN controller.  These correspond to the
+    following product names:
+     Intel(R) PRO/1000 PT Server Adapter
+     Intel(R) PRO/1000 PT Desktop Adapter
+     Intel(R) PRO/1000 PT Network Connection
+     Intel(R) PRO/1000 PT Dual Port Server Adapter
+     Intel(R) PRO/1000 PT Dual Port Network Connection
+     Intel(R) PRO/1000 PF Server Adapter
+     Intel(R) PRO/1000 PF Network Connection
+     Intel(R) PRO/1000 PF Dual Port Server Adapter
+     Intel(R) PRO/1000 PB Server Connection
+     Intel(R) PRO/1000 PL Network Connection
+     Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
+     Intel(R) PRO/1000 EB Backplane Connection with I/O Acceleration
+     Intel(R) PRO/1000 PT Quad Port Server Adapter
+
+  - Adapters based on the Intel(R) 82542 and 82573V/E controller do not
+    support Jumbo Frames. These correspond to the following product names:
+     Intel(R) PRO/1000 Gigabit Server Adapter
+     Intel(R) PRO/1000 PM Network Connection
+
+  - The following adapters do not support Jumbo Frames:
+     Intel(R) 82562V 10/100 Network Connection
+     Intel(R) 82566DM Gigabit Network Connection
+     Intel(R) 82566DC Gigabit Network Connection
+     Intel(R) 82566MM Gigabit Network Connection
+     Intel(R) 82566MC Gigabit Network Connection
+     Intel(R) 82562GT 10/100 Network Connection
+     Intel(R) 82562G 10/100 Network Connection
 
 
   Ethtool
   -------
-
   The driver utilizes the ethtool interface for driver configuration and
   diagnostics, as well as displaying statistical information.  Ethtool
   version 1.6 or later is required for this functionality.
@@ -417,15 +490,14 @@ Additional Configurations
   The latest release of ethtool can be found from
   http://sourceforge.net/projects/gkernel.
 
-  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
+  NOTE: Ethtool 1.6 only supports a limited set of ethtool options.  Support
   for a more complete ethtool feature set can be enabled by upgrading
   ethtool to ethtool-1.8.1.
 
   Enabling Wake on LAN* (WoL)
   ---------------------------
-
-  WoL is configured through the Ethtool* utility. Ethtool is included with
-  all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
+  WoL is configured through the Ethtool* utility.  Ethtool is included with
+  all versions of Red Hat after Red Hat 7.2.  For other Linux distributions,
   download and install Ethtool from the following website:
   http://sourceforge.net/projects/gkernel.
 
@@ -436,11 +508,17 @@ Additional Configurations
   For this driver version, in order to enable WoL, the e1000 driver must be
   loaded when shutting down or rebooting the system.
 
+  Wake On LAN is only supported on port A for the following devices:
+  Intel(R) PRO/1000 PT Dual Port Network Connection
+  Intel(R) PRO/1000 PT Dual Port Server Connection
+  Intel(R) PRO/1000 PT Dual Port Server Adapter
+  Intel(R) PRO/1000 PF Dual Port Server Adapter
+  Intel(R) PRO/1000 PT Quad Port Server Adapter 
+
   NAPI
   ----
-
-  NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
-  or disabled based on the configuration of the kernel. To override
+  NAPI (Rx polling mode) is supported in the e1000 driver.  NAPI is enabled
+  or disabled based on the configuration of the kernel.  To override
   the default, use the following compile-time flags.
 
   To enable NAPI, compile the driver module, passing in a configuration option:
@@ -457,88 +535,105 @@ Additional Configurations
 Known Issues
 ============
 
-  Jumbo Frames System Requirement
-  -------------------------------
-
-  Memory allocation failures have been observed on Linux systems with 64 MB
-  of RAM or less that are running Jumbo Frames. If you are using Jumbo
-  Frames, your system may require more than the advertised minimum
-  requirement of 64 MB of system memory.
-
-  Performance Degradation with Jumbo Frames
-  -----------------------------------------
-
-  Degradation in throughput performance may be observed in some Jumbo frames
-  environments. If this is observed, increasing the application's socket
-  buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
-  may help. See the specific application manual and
-  /usr/src/linux*/Documentation/
-  networking/ip-sysctl.txt for more details.
-
-  Jumbo frames on Foundry BigIron 8000 switch
-  -------------------------------------------
-  There is a known issue using Jumbo frames when connected to a Foundry
-  BigIron 8000 switch. This is a 3rd party limitation. If you experience
-  loss of packets, lower the MTU size.
-
-  Multiple Interfaces on Same Ethernet Broadcast Network
-  ------------------------------------------------------
-
-  Due to the default ARP behavior on Linux, it is not possible to have
-  one system on two IP networks in the same Ethernet broadcast domain
-  (non-partitioned switch) behave as expected. All Ethernet interfaces
-  will respond to IP traffic for any IP address assigned to the system.
-  This results in unbalanced receive traffic.
-
-  If you have multiple interfaces in a server, either turn on ARP
-  filtering by entering:
-
-      echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
-  (this only works if your kernel's version is higher than 2.4.5),
-
-  NOTE: This setting is not saved across reboots. The configuration
-  change can be made permanent by adding the line:
-      net.ipv4.conf.all.arp_filter = 1
-  to the file /etc/sysctl.conf
-
-        or,
-
-  install the interfaces in separate broadcast domains (either in
-  different switches or in a switch partitioned to VLANs).
-
-  82541/82547 can't link or are slow to link with some link partners
-  -----------------------------------------------------------------
-
-  There is a known compatibility issue with 82541/82547 and some
-  low-end switches where the link will not be established, or will
-  be slow to establish.  In particular, these switches are known to
-  be incompatible with 82541/82547:
-
-      Planex FXG-08TE
-      I-O Data ETG-SH8
-
-  To workaround this issue, the driver can be compiled with an override
-  of the PHY's master/slave setting.  Forcing master or forcing slave
-  mode will improve time-to-link.
-
-      # make EXTRA_CFLAGS=-DE1000_MASTER_SLAVE=<n>
-
-  Where <n> is:
-
-      0 = Hardware default
-      1 = Master mode
-      2 = Slave mode
-      3 = Auto master/slave
-
-  Disable rx flow control with ethtool
-  ------------------------------------
-
-  In order to disable receive flow control using ethtool, you must turn
-  off auto-negotiation on the same command line.
-
-  For example:
-
-     ethtool -A eth? autoneg off rx off
+Dropped Receive Packets on Half-duplex 10/100 Networks
+------------------------------------------------------
+If you have an Intel PCI Express adapter running at 10mbps or 100mbps, half-
+duplex, you may observe occasional dropped receive packets.  There are no
+workarounds for this problem in this network configuration.  The network must
+be updated to operate in full-duplex, and/or 1000mbps only.
+
+Jumbo Frames System Requirement
+-------------------------------
+Memory allocation failures have been observed on Linux systems with 64 MB
+of RAM or less that are running Jumbo Frames.  If you are using Jumbo
+Frames, your system may require more than the advertised minimum
+requirement of 64 MB of system memory.
+
+Performance Degradation with Jumbo Frames
+-----------------------------------------
+Degradation in throughput performance may be observed in some Jumbo frames
+environments.  If this is observed, increasing the application's socket
+buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
+may help.  See the specific application manual and
+/usr/src/linux*/Documentation/
+networking/ip-sysctl.txt for more details.
+
+Jumbo Frames on Foundry BigIron 8000 switch
+-------------------------------------------
+There is a known issue using Jumbo frames when connected to a Foundry
+BigIron 8000 switch.  This is a 3rd party limitation.  If you experience
+loss of packets, lower the MTU size.
+
+Allocating Rx Buffers when Using Jumbo Frames 
+---------------------------------------------
+Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if 
+the available memory is heavily fragmented. This issue may be seen with PCI-X 
+adapters or with packet split disabled. This can be reduced or eliminated 
+by changing the amount of available memory for receive buffer allocation, by
+increasing /proc/sys/vm/min_free_kbytes. 
+
+Multiple Interfaces on Same Ethernet Broadcast Network
+------------------------------------------------------
+Due to the default ARP behavior on Linux, it is not possible to have
+one system on two IP networks in the same Ethernet broadcast domain
+(non-partitioned switch) behave as expected.  All Ethernet interfaces
+will respond to IP traffic for any IP address assigned to the system.
+This results in unbalanced receive traffic.
+
+If you have multiple interfaces in a server, either turn on ARP
+filtering by entering:
+
+    echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+(this only works if your kernel's version is higher than 2.4.5),
+
+NOTE: This setting is not saved across reboots.  The configuration
+change can be made permanent by adding the line:
+    net.ipv4.conf.all.arp_filter = 1
+to the file /etc/sysctl.conf
+
+      or,
+
+install the interfaces in separate broadcast domains (either in
+different switches or in a switch partitioned to VLANs).
+
+82541/82547 can't link or are slow to link with some link partners
+-----------------------------------------------------------------
+There is a known compatibility issue with 82541/82547 and some
+low-end switches where the link will not be established, or will
+be slow to establish.  In particular, these switches are known to
+be incompatible with 82541/82547:
+
+    Planex FXG-08TE
+    I-O Data ETG-SH8
+
+To workaround this issue, the driver can be compiled with an override
+of the PHY's master/slave setting.  Forcing master or forcing slave
+mode will improve time-to-link.
+
+    # make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
+
+Where <n> is:
+
+    0 = Hardware default
+    1 = Master mode
+    2 = Slave mode
+    3 = Auto master/slave
+
+Disable rx flow control with ethtool
+------------------------------------
+In order to disable receive flow control using ethtool, you must turn
+off auto-negotiation on the same command line.
+
+For example:
+
+   ethtool -A eth? autoneg off rx off
+
+Unplugging network cable while ethtool -p is running
+----------------------------------------------------
+In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging
+the network cable while ethtool -p is running will cause the system to
+become unresponsive to keyboard commands, except for control-alt-delete.
+Restarting the system appears to be the only remedy.
 
 
 Support
@@ -548,24 +643,10 @@ For general information, go to the Intel support website at:
 
     http://support.intel.com
 
-    or the Intel Wired Networking project hosted by Sourceforge at:
+or the Intel Wired Networking project hosted by Sourceforge at:
 
     http://sourceforge.net/projects/e1000
 
 If an issue is identified with the released source code on the supported
 kernel with a supported adapter, email the specific information related
-to the issue to e1000-devel@lists.sourceforge.net
-
-
-License
-=======
-
-This software program is released under the terms of a license agreement
-between you ('Licensee') and Intel. Do not use or load this software or any
-associated materials (collectively, the 'Software') until you have carefully
-read the full terms and conditions of the file COPYING located in this software
-package. By loading or using the Software, you agree to the terms of this
-Agreement. If you do not agree with the terms of this Agreement, do not
-install or use the Software.
-
-* Other names and brands may be claimed as the property of others.
+to the issue to e1000-devel@lists.sf.net
diff --git a/Documentation/networking/generic_netlink.txt b/Documentation/networking/generic_netlink.txt
new file mode 100644
index 000000000000..d4f8b8b9b53c
--- /dev/null
+++ b/Documentation/networking/generic_netlink.txt
@@ -0,0 +1,3 @@
+A wiki document on how to use Generic Netlink can be found here:
+
+ * http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index fd3c0c012351..a0f6842368c3 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER
 
 TCP variables: 
 
+somaxconn - INTEGER
+        Limit of socket listen() backlog, known in userspace as SOMAXCONN.
+        Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
+        for TCP sockets.
+
 tcp_abc - INTEGER
         Controls Appropriate Byte Count (ABC) defined in RFC3465.
         ABC is a way of increasing congestion window (cwnd) more slowly
@@ -112,48 +117,51 @@ tcp_abc - INTEGER
                   of two segments to compensate for delayed acknowledgments.
         Default: 0 (off)
 
-tcp_syn_retries - INTEGER
-        Number of times initial SYNs for an active TCP connection attempt
-        will be retransmitted. Should not be higher than 255. Default value
-        is 5, which corresponds to ~180seconds.
+tcp_abort_on_overflow - BOOLEAN
+        If listening service is too slow to accept new connections,
+        reset them. Default state is FALSE. It means that if overflow
+        occurred due to a burst, connection will recover. Enable this
+        option _only_ if you are really sure that listening daemon
+        cannot be tuned to accept connections faster. Enabling this
+        option can harm clients of your server.
 
-tcp_synack_retries - INTEGER
-        Number of times SYNACKs for a passive TCP connection attempt will
-        be retransmitted. Should not be higher than 255. Default value
-        is 5, which corresponds to ~180seconds.
+tcp_adv_win_scale - INTEGER
+        Count buffering overhead as bytes/2^tcp_adv_win_scale
+        (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
+        if it is <= 0.
+        Default: 2
 
-tcp_keepalive_time - INTEGER
-        How often TCP sends out keepalive messages when keepalive is enabled.
-        Default: 2hours.
+tcp_allowed_congestion_control - STRING
+        Show/set the congestion control choices available to non-privileged
+        processes. The list is a subset of those listed in
+        tcp_available_congestion_control.
+        Default is "reno" and the default setting (tcp_congestion_control).
 
-tcp_keepalive_probes - INTEGER
-        How many keepalive probes TCP sends out, until it decides that the
-        connection is broken. Default value: 9.
+tcp_app_win - INTEGER
+        Reserve max(window/2^tcp_app_win, mss) of window for application
+        buffer. Value 0 is special, it means that nothing is reserved.
+        Default: 31
 
-tcp_keepalive_intvl - INTEGER
-        How frequently the probes are send out. Multiplied by
-        tcp_keepalive_probes it is time to kill not responding connection,
-        after probes started. Default value: 75sec i.e. connection
-        will be aborted after ~11 minutes of retries.
+tcp_available_congestion_control - STRING
+        Shows the available congestion control choices that are registered.
+        More congestion control algorithms may be available as modules,
+        but not loaded.
 
-tcp_retries1 - INTEGER
-        How many times to retry before deciding that something is wrong
-        and it is necessary to report this suspicion to network layer.
-        Minimal RFC value is 3, it is default, which corresponds
-        to ~3sec-8min depending on RTO.
+tcp_congestion_control - STRING
+        Set the congestion control algorithm to be used for new
+        connections. The algorithm "reno" is always available, but
+        additional choices may be available based on kernel configuration.
+        Default is set as part of kernel configuration.
 
-tcp_retries2 - INTEGER
-        How may times to retry before killing alive TCP connection.
-        RFC1122 says that the limit should be longer than 100 sec.
-        It is too small number. Default value 15 corresponds to ~13-30min
-        depending on RTO.
+tcp_dsack - BOOLEAN
+        Allows TCP to send "duplicate" SACKs.
 
-tcp_orphan_retries - INTEGER
-        How may times to retry before killing TCP connection, closed
-        by our side. Default value 7 corresponds to ~50sec-16min
-        depending on RTO. If you machine is loaded WEB server,
-        you should think about lowering this value, such sockets
-        may consume significant resources. Cf. tcp_max_orphans.
+tcp_ecn - BOOLEAN
+        Enable Explicit Congestion Notification in TCP.
+
+tcp_fack - BOOLEAN
+        Enable FACK congestion avoidance and fast retransmission.
+        The value is not used, if tcp_sack is not enabled.
 
 tcp_fin_timeout - INTEGER
         Time to hold socket in state FIN-WAIT-2, if it was closed
@@ -166,24 +174,33 @@ tcp_fin_timeout - INTEGER
         because they eat maximum 1.5K of memory, but they tend
         to live longer. Cf. tcp_max_orphans.
 
-tcp_max_tw_buckets - INTEGER
-        Maximal number of timewait sockets held by system simultaneously.
-        If this number is exceeded time-wait socket is immediately destroyed
-        and warning is printed. This limit exists only to prevent
-        simple DoS attacks, you _must_ not lower the limit artificially,
-        but rather increase it (probably, after increasing installed memory),
-        if network conditions require more than default value.
+tcp_frto - BOOLEAN
+        Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
+        timeouts.  It is particularly beneficial in wireless environments
+        where packet loss is typically due to random radio interference
+        rather than intermediate router congestion.
 
-tcp_tw_recycle - BOOLEAN
-        Enable fast recycling TIME-WAIT sockets. Default value is 0.
-        It should not be changed without advice/request of technical
-        experts.
+tcp_keepalive_time - INTEGER
+        How often TCP sends out keepalive messages when keepalive is enabled.
+        Default: 2hours.
 
-tcp_tw_reuse - BOOLEAN
-        Allow to reuse TIME-WAIT sockets for new connections when it is
-        safe from protocol viewpoint. Default value is 0.
-        It should not be changed without advice/request of technical
-        experts.
+tcp_keepalive_probes - INTEGER
+        How many keepalive probes TCP sends out, until it decides that the
+        connection is broken. Default value: 9.
+
+tcp_keepalive_intvl - INTEGER
+        How frequently the probes are send out. Multiplied by
+        tcp_keepalive_probes it is time to kill not responding connection,
+        after probes started. Default value: 75sec i.e. connection
+        will be aborted after ~11 minutes of retries.
+
+tcp_low_latency - BOOLEAN
+        If set, the TCP stack makes decisions that prefer lower
+        latency as opposed to higher throughput.  By default, this
+        option is not set meaning that higher throughput is preferred.
+        An example of an application where this default should be
+        changed would be a Beowulf compute cluster.
+        Default: 0
 
 tcp_max_orphans - INTEGER
         Maximal number of TCP sockets not attached to any user file handle,
@@ -197,41 +214,6 @@ tcp_max_orphans - INTEGER
         more aggressively. Let me to remind again: each orphan eats
         up to ~64K of unswappable memory.
 
-tcp_abort_on_overflow - BOOLEAN
-        If listening service is too slow to accept new connections,
-        reset them. Default state is FALSE. It means that if overflow
-        occurred due to a burst, connection will recover. Enable this
-        option _only_ if you are really sure that listening daemon
-        cannot be tuned to accept connections faster. Enabling this
-        option can harm clients of your server.
-
-tcp_syncookies - BOOLEAN
-        Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
-        Send out syncookies when the syn backlog queue of a socket 
-        overflows. This is to prevent against the common 'syn flood attack'
-        Default: FALSE
-
-        Note, that syncookies is fallback facility.
-        It MUST NOT be used to help highly loaded servers to stand
-        against legal connection rate. If you see synflood warnings
-        in your logs, but investigation shows that they occur
-        because of overload with legal connections, you should tune
-        another parameters until this warning disappear.
-        See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
-
-        syncookies seriously violate TCP protocol, do not allow
-        to use TCP extensions, can result in serious degradation
-        of some services (f.e. SMTP relaying), visible not by you,
-        but your clients and relays, contacting you. While you see
-        synflood warnings in logs not being really flooded, your server
-        is seriously misconfigured.
-
-tcp_stdurg - BOOLEAN
-        Use the Host requirements interpretation of the TCP urg pointer field.
-        Most hosts use the older BSD interpretation, so if you turn this on
-        Linux might not communicate correctly with them.        
-        Default: FALSE 
-        
 tcp_max_syn_backlog - INTEGER
         Maximal number of remembered connection requests, which are
         still did not receive an acknowledgment from connecting client.
@@ -239,24 +221,34 @@ tcp_max_syn_backlog - INTEGER
         and 128 for low memory machines. If server suffers of overload,
         try to increase this number.
 
-tcp_window_scaling - BOOLEAN
-        Enable window scaling as defined in RFC1323.
+tcp_max_tw_buckets - INTEGER
+        Maximal number of timewait sockets held by system simultaneously.
+        If this number is exceeded time-wait socket is immediately destroyed
+        and warning is printed. This limit exists only to prevent
+        simple DoS attacks, you _must_ not lower the limit artificially,
+        but rather increase it (probably, after increasing installed memory),
+        if network conditions require more than default value.
 
-tcp_timestamps - BOOLEAN
-        Enable timestamps as defined in RFC1323.
+tcp_mem - vector of 3 INTEGERs: min, pressure, max
+        min: below this number of pages TCP is not bothered about its
+        memory appetite.
 
-tcp_sack - BOOLEAN
-        Enable select acknowledgments (SACKS).
+        pressure: when amount of memory allocated by TCP exceeds this number
+        of pages, TCP moderates its memory consumption and enters memory
+        pressure mode, which is exited when memory consumption falls
+        under "min".
 
-tcp_fack - BOOLEAN
-        Enable FACK congestion avoidance and fast retransmission.
-        The value is not used, if tcp_sack is not enabled.
+        max: number of pages allowed for queueing by all TCP sockets.
 
-tcp_dsack - BOOLEAN
-        Allows TCP to send "duplicate" SACKs.
+        Defaults are calculated at boot time from amount of available
+        memory.
 
-tcp_ecn - BOOLEAN
-        Enable Explicit Congestion Notification in TCP.
+tcp_orphan_retries - INTEGER
+        How may times to retry before killing TCP connection, closed
+        by our side. Default value 7 corresponds to ~50sec-16min
+        depending on RTO. If you machine is loaded WEB server,
+        you should think about lowering this value, such sockets
+        may consume significant resources. Cf. tcp_max_orphans.
 
 tcp_reordering - INTEGER
         Maximal reordering of packets in a TCP stream.
@@ -267,20 +259,23 @@ tcp_retrans_collapse - BOOLEAN
         On retransmit try to send bigger packets to work around bugs in
         certain TCP stacks.
 
-tcp_wmem - vector of 3 INTEGERs: min, default, max
-        min: Amount of memory reserved for send buffers for TCP socket.
-        Each TCP socket has rights to use it due to fact of its birth.
-        Default: 4K
+tcp_retries1 - INTEGER
+        How many times to retry before deciding that something is wrong
+        and it is necessary to report this suspicion to network layer.
+        Minimal RFC value is 3, it is default, which corresponds
+        to ~3sec-8min depending on RTO.
 
-        default: Amount of memory allowed for send buffers for TCP socket
-        by default. This value overrides net.core.wmem_default used
-        by other protocols, it is usually lower than net.core.wmem_default.
-        Default: 16K
+tcp_retries2 - INTEGER
+        How may times to retry before killing alive TCP connection.
+        RFC1122 says that the limit should be longer than 100 sec.
+        It is too small number. Default value 15 corresponds to ~13-30min
+        depending on RTO.
 
-        max: Maximal amount of memory allowed for automatically selected
-        send buffers for TCP socket. This value does not override
-        net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
-        Default: 128K
+tcp_rfc1337 - BOOLEAN
+        If set, the TCP stack behaves conforming to RFC1337. If unset,
+        we are not conforming to RFC, but prevent TCP TIME_WAIT
+        assassination.
+        Default: 0
 
 tcp_rmem - vector of 3 INTEGERs: min, default, max
         min: Minimal size of receive buffer used by TCP sockets.
@@ -299,67 +294,91 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
         net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
         Default: 87380*2 bytes.
 
-tcp_mem - vector of 3 INTEGERs: min, pressure, max
-        min: below this number of pages TCP is not bothered about its
-        memory appetite.
+tcp_sack - BOOLEAN
+        Enable select acknowledgments (SACKS).
 
-        pressure: when amount of memory allocated by TCP exceeds this number
-        of pages, TCP moderates its memory consumption and enters memory
-        pressure mode, which is exited when memory consumption falls
-        under "min".
+tcp_slow_start_after_idle - BOOLEAN
+        If set, provide RFC2861 behavior and time out the congestion
+        window after an idle period.  An idle period is defined at
+        the current RTO.  If unset, the congestion window will not
+        be timed out after an idle period.
+        Default: 1
 
-        max: number of pages allowed for queueing by all TCP sockets.
+tcp_stdurg - BOOLEAN
+        Use the Host requirements interpretation of the TCP urg pointer field.
+        Most hosts use the older BSD interpretation, so if you turn this on
+        Linux might not communicate correctly with them.
+        Default: FALSE
 
-        Defaults are calculated at boot time from amount of available
-        memory.
+tcp_synack_retries - INTEGER
+        Number of times SYNACKs for a passive TCP connection attempt will
+        be retransmitted. Should not be higher than 255. Default value
+        is 5, which corresponds to ~180seconds.
 
-tcp_app_win - INTEGER
-        Reserve max(window/2^tcp_app_win, mss) of window for application
-        buffer. Value 0 is special, it means that nothing is reserved.
-        Default: 31
+tcp_syncookies - BOOLEAN
+        Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
+        Send out syncookies when the syn backlog queue of a socket
+        overflows. This is to prevent against the common 'syn flood attack'
+        Default: FALSE
 
-tcp_adv_win_scale - INTEGER
-        Count buffering overhead as bytes/2^tcp_adv_win_scale
-        (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
-        if it is <= 0.
-        Default: 2
+        Note, that syncookies is fallback facility.
+        It MUST NOT be used to help highly loaded servers to stand
+        against legal connection rate. If you see synflood warnings
+        in your logs, but investigation shows that they occur
+        because of overload with legal connections, you should tune
+        another parameters until this warning disappear.
+        See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
 
-tcp_rfc1337 - BOOLEAN
-        If set, the TCP stack behaves conforming to RFC1337. If unset,
-        we are not conforming to RFC, but prevent TCP TIME_WAIT
-        assassination.   
-        Default: 0
+        syncookies seriously violate TCP protocol, do not allow
+        to use TCP extensions, can result in serious degradation
+        of some services (f.e. SMTP relaying), visible not by you,
+        but your clients and relays, contacting you. While you see
+        synflood warnings in logs not being really flooded, your server
+        is seriously misconfigured.
 
-tcp_low_latency - BOOLEAN
-        If set, the TCP stack makes decisions that prefer lower
-        latency as opposed to higher throughput.  By default, this
-        option is not set meaning that higher throughput is preferred.
-        An example of an application where this default should be
-        changed would be a Beowulf compute cluster.
-        Default: 0
+tcp_syn_retries - INTEGER
+        Number of times initial SYNs for an active TCP connection attempt
+        will be retransmitted. Should not be higher than 255. Default value
+        is 5, which corresponds to ~180seconds.
+
+tcp_timestamps - BOOLEAN
+        Enable timestamps as defined in RFC1323.
 
 tcp_tso_win_divisor - INTEGER
-       This allows control over what percentage of the congestion window
-       can be consumed by a single TSO frame.
-       The setting of this parameter is a choice between burstiness and
-       building larger TSO frames.
-       Default: 3
+        This allows control over what percentage of the congestion window
+        can be consumed by a single TSO frame.
+        The setting of this parameter is a choice between burstiness and
+        building larger TSO frames.
+        Default: 3
 
-tcp_frto - BOOLEAN
-        Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
-        timeouts.  It is particularly beneficial in wireless environments
-        where packet loss is typically due to random radio interference
-        rather than intermediate router congestion.
+tcp_tw_recycle - BOOLEAN
+        Enable fast recycling TIME-WAIT sockets. Default value is 0.
+        It should not be changed without advice/request of technical
+        experts.
 
-tcp_congestion_control - STRING
-        Set the congestion control algorithm to be used for new
-        connections. The algorithm "reno" is always available, but
-        additional choices may be available based on kernel configuration.
+tcp_tw_reuse - BOOLEAN
+        Allow to reuse TIME-WAIT sockets for new connections when it is
+        safe from protocol viewpoint. Default value is 0.
+        It should not be changed without advice/request of technical
+        experts.
 
-somaxconn - INTEGER
-        Limit of socket listen() backlog, known in userspace as SOMAXCONN.
-        Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
-        for TCP sockets.
+tcp_window_scaling - BOOLEAN
+        Enable window scaling as defined in RFC1323.
+
+tcp_wmem - vector of 3 INTEGERs: min, default, max
+        min: Amount of memory reserved for send buffers for TCP socket.
+        Each TCP socket has rights to use it due to fact of its birth.
+        Default: 4K
+
+        default: Amount of memory allowed for send buffers for TCP socket
+        by default. This value overrides net.core.wmem_default used
+        by other protocols, it is usually lower than net.core.wmem_default.
+        Default: 16K
+
+        max: Maximal amount of memory allowed for automatically selected
+        send buffers for TCP socket. This value does not override
+        net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
+        Default: 128K
 
 tcp_workaround_signed_windows - BOOLEAN
         If set, assume no receipt of a window scaling option means the
@@ -368,13 +387,6 @@ tcp_workaround_signed_windows - BOOLEAN
         not receive a window scaling option from them.
         Default: 0
 
-tcp_slow_start_after_idle - BOOLEAN
-        If set, provide RFC2861 behavior and time out the congestion
-        window after an idle period.  An idle period is defined at
-        the current RTO.  If unset, the congestion window will not
-        be timed out after an idle period.
-        Default: 1
-
 CIPSOv4 Variables:
 
 cipso_cache_enable - BOOLEAN
@@ -974,4 +986,3 @@ no_cong_thresh FIXME
 slot_timeout FIXME
 warn_noreply_time FIXME
 
-$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $
diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt
index 493203a080a8..55eac4a784e2 100644
--- a/Documentation/networking/iphase.txt
+++ b/Documentation/networking/iphase.txt
@@ -81,7 +81,7 @@ Installation
     1M. The RAM size decides the number of buffers and buffer size. The default 
     size and number of buffers are set as following: 
 
-          Totol    Rx RAM   Tx RAM   Rx Buf   Tx Buf   Rx buf   Tx buf
+          Total    Rx RAM   Tx RAM   Rx Buf   Tx Buf   Rx buf   Tx buf
          RAM size   size     size     size     size      cnt      cnt
          --------  ------   ------   ------   ------   ------   ------
            128K      64K      64K      10K      10K       6        6
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 12a008a5c221..5a232d946be3 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -284,7 +284,7 @@ the necessary memory, so normally limits can be reached.
 -------------------
 
 If you check the source code you will see that what I draw here as a frame
-is not only the link level frame. At the begining of each frame there is a 
+is not only the link level frame. At the beginning of each frame there is a 
 header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
 meta information like timestamp. So what we draw here a frame it's really 
 the following (from include/linux/if_packet.h):
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 29ccae409031..0bc95eab1512 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -1,7 +1,7 @@
 
 -------
 PHY Abstraction Layer
-(Updated 2005-07-21)
+(Updated 2006-11-30)
 
 Purpose
 
@@ -97,11 +97,12 @@ Letting the PHY Abstraction Layer do Everything
  
  Next, you need to know the device name of the PHY connected to this device. 
  The name will look something like, "phy0:0", where the first number is the
- bus id, and the second is the PHY's address on that bus.
+ bus id, and the second is the PHY's address on that bus.  Typically,
+ the bus is responsible for making its ID unique.
  
  Now, to connect, just call this function:
  
-   phydev = phy_connect(dev, phy_name, &adjust_link, flags);
+   phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
 
  phydev is a pointer to the phy_device structure which represents the PHY.  If
  phy_connect is successful, it will return the pointer.  dev, here, is the
@@ -115,6 +116,10 @@ Letting the PHY Abstraction Layer do Everything
  This is useful if the system has put hardware restrictions on
  the PHY/controller, of which the PHY needs to be aware.
 
+ interface is a u32 which specifies the connection type used
+ between the controller and the PHY.  Examples are GMII, MII,
+ RGMII, and SGMII.  For a full list, see include/linux/phy.h
+
  Now just make sure that phydev->supported and phydev->advertising have any
  values pruned from them which don't make sense for your controller (a 10/100
  controller may be connected to a gigabit capable PHY, so you would need to
@@ -191,7 +196,7 @@ Doing it all yourself
    start, or disables then frees them for stop.
 
  struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
-                 u32 flags);
+                 u32 flags, phy_interface_t interface);
 
    Attaches a network device to a particular PHY, binding the PHY to a generic
    driver if none was found during bus initialization.  Passes in
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index c8eee23be8c0..c6cf4a3c16e0 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -63,8 +63,8 @@ Current:
 Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
   763292pps 390Mb/sec (390805504bps) errors: 39664
 
-Confguring threads and devices
-==============================
+Configuring threads and devices
+================================
 This is done via the /proc interface easiest done via pgset in the scripts
 
 Examples:
@@ -116,7 +116,7 @@ Examples:
                                          there must be no spaces between the
                                          arguments. Leading zeros are required.
                                          Do not set the bottom of stack bit,
-                                         thats done automatically. If you do
+                                         that's done automatically. If you do
                                          set the bottom of stack bit, that
                                          indicates that you want to randomly
                                          generate that address and the flag
diff --git a/Documentation/networking/proc_net_tcp.txt b/Documentation/networking/proc_net_tcp.txt
index 59cb915c3713..5e21f7cb6383 100644
--- a/Documentation/networking/proc_net_tcp.txt
+++ b/Documentation/networking/proc_net_tcp.txt
@@ -25,7 +25,7 @@ up into 3 parts because of the length of the line):
 
    1000        0 54165785 4 cd1e6040 25 4 27 3 -1
     |          |    |     |    |     |  | |  | |--> slow start size threshold, 
-    |          |    |     |    |     |  | |  |      or -1 if the treshold
+    |          |    |     |    |     |  | |  |      or -1 if the threshold
     |          |    |     |    |     |  | |  |      is >= 0xFFFF
     |          |    |     |    |     |  | |  |----> sending congestion window
     |          |    |     |    |     |  | |-------> (ack.quick<<1)|ack.pingpong
diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt
index 4e1cc745ec63..8590a954df1d 100644
--- a/Documentation/networking/sk98lin.txt
+++ b/Documentation/networking/sk98lin.txt
@@ -346,7 +346,7 @@ Possible modes:
       depending on the load of the system. If the driver detects that the
       system load is too high, the driver tries to shield the system against 
       too much network load by enabling interrupt moderation. If - at a later
-      time - the CPU utilizaton decreases again (or if the network load is 
+      time - the CPU utilization decreases again (or if the network load is 
       negligible) the interrupt moderation will automatically be disabled.
 
 Interrupt moderation should be used when the driver has to handle one or more
diff --git a/Documentation/networking/slicecom.txt b/Documentation/networking/slicecom.txt
index 2f04c9267f89..32d3b916afad 100644
--- a/Documentation/networking/slicecom.txt
+++ b/Documentation/networking/slicecom.txt
@@ -126,7 +126,7 @@ comx0/boardnum	- board number of the SliceCom in the PC (using the 'natural'
 
 Though the options below are to be set on a single interface, they apply to the
 whole board. The restriction, to use them on 'UP' interfaces, is because the 
-command sequence below could lead to unpredicable results.
+command sequence below could lead to unpredictable results.
 
         # echo 0        >boardnum
         # echo internal >clock_source
diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt
new file mode 100644
index 000000000000..dd6f46b83dab
--- /dev/null
+++ b/Documentation/networking/udplite.txt
@@ -0,0 +1,281 @@
+  ===========================================================================
+                      The UDP-Lite protocol (RFC 3828)
+  ===========================================================================
+
+
+  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
+  is a variable-length checksum. This has advantages for transport of multimedia
+  (video, VoIP) over wireless networks, as partly damaged packets can still be
+  fed into the codec instead of being discarded due to a failed checksum test.
+
+  This file briefly describes the existing kernel support and the socket API.
+  For in-depth information, you can consult:
+
+   o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
+       Fom here you can also download some example application source code.
+
+   o The UDP-Lite HOWTO on
+       http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
+
+   o The Wireshark UDP-Lite WiKi (with capture files):
+       http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
+
+   o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
+
+
+  I) APPLICATIONS
+
+  Several applications have been ported successfully to UDP-Lite. Ethereal
+  (now called wireshark) has UDP-Litev4/v6 support by default. The tarball on
+
+   http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
+
+  has source code for several v4/v6 client-server and network testing examples.
+
+  Porting applications to UDP-Lite is straightforward: only socket level and
+  IPPROTO need to be changed; senders additionally set the checksum coverage
+  length (default = header length = 8). Details are in the next section.
+
+
+  II) PROGRAMMING API
+
+  UDP-Lite provides a connectionless, unreliable datagram service and hence
+  uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
+  very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
+  call so that the statement looks like:
+
+      s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
+
+                      or, respectively,
+
+      s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
+
+  With just the above change you are able to run UDP-Lite services or connect
+  to UDP-Lite servers. The kernel will assume that you are not interested in
+  using partial checksum coverage and so emulate UDP mode (full coverage).
+
+  To make use of the partial checksum coverage facilities requires setting a
+  single socket option, which takes an integer specifying the coverage length:
+
+    * Sender checksum coverage: UDPLITE_SEND_CSCOV
+
+      For example,
+
+        int val = 20;
+        setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
+
+      sets the checksum coverage length to 20 bytes (12b data + 8b header).
+      Of each packet only the first 20 bytes (plus the pseudo-header) will be
+      checksummed. This is useful for RTP applications which have a 12-byte
+      base header.
+
+
+    * Receiver checksum coverage: UDPLITE_RECV_CSCOV
+
+      This option is the receiver-side analogue. It is truly optional, i.e. not
+      required to enable traffic with partial checksum coverage. Its function is
+      that of a traffic filter: when enabled, it instructs the kernel to drop
+      all packets which have a coverage _less_ than this value. For example, if
+      RTP and UDP headers are to be protected, a receiver can enforce that only
+      packets with a minimum coverage of 20 are admitted:
+
+        int min = 20;
+        setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
+
+  The calls to getsockopt(2) are analogous. Being an extension and not a stand-
+  alone protocol, all socket options known from UDP can be used in exactly the
+  same manner as before, e.g. UDP_CORK or UDP_ENCAP.
+
+  A detailed discussion of UDP-Lite checksum coverage options is in section IV.
+
+
+  III) HEADER FILES
+
+  The socket API requires support through header files in /usr/include:
+
+    * /usr/include/netinet/in.h
+        to define IPPROTO_UDPLITE
+
+    * /usr/include/netinet/udplite.h
+        for UDP-Lite header fields and protocol constants
+
+  For testing purposes, the following can serve as a `mini' header file:
+
+    #define IPPROTO_UDPLITE       136
+    #define SOL_UDPLITE           136
+    #define UDPLITE_SEND_CSCOV     10
+    #define UDPLITE_RECV_CSCOV     11
+
+  Ready-made header files for various distros are in the UDP-Lite tarball.
+
+
+  IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS
+
+  To enable debugging messages, the log level need to be set to 8, as most
+  messages use the KERN_DEBUG level (7).
+
+  1) Sender Socket Options
+
+  If the sender specifies a value of 0 as coverage length, the module
+  assumes full coverage, transmits a packet with coverage length of 0
+  and according checksum.  If the sender specifies a coverage < 8 and
+  different from 0, the kernel assumes 8 as default value.  Finally,
+  if the specified coverage length exceeds the packet length, the packet
+  length is used instead as coverage length.
+
+  2) Receiver Socket Options
+
+  The receiver specifies the minimum value of the coverage length it
+  is willing to accept.  A value of 0 here indicates that the receiver
+  always wants the whole of the packet covered. In this case, all
+  partially covered packets are dropped and an error is logged.
+
+  It is not possible to specify illegal values (<0 and <8); in these
+  cases the default of 8 is assumed.
+
+  All packets arriving with a coverage value less than the specified
+  threshold are discarded, these events are also logged.
+
+  3) Disabling the Checksum Computation
+
+  On both sender and receiver, checksumming will always be performed
+  and can not be disabled using SO_NO_CHECK. Thus
+
+        setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );
+
+  will always will be ignored, while the value of
+
+        getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
+
+  is meaningless (as in TCP). Packets with a zero checksum field are
+  illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.
+
+  4) Fragmentation
+
+  The checksum computation respects both buffersize and MTU. The size
+  of UDP-Lite packets is determined by the size of the send buffer. The
+  minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
+  in include/net/sock.h), the default value is configurable as
+  net.core.wmem_default or via setting the SO_SNDBUF socket(7)
+  option. The maximum upper bound for the send buffer is determined
+  by net.core.wmem_max.
+
+  Given a payload size larger than the send buffer size, UDP-Lite will
+  split the payload into several individual packets, filling up the
+  send buffer size in each case.
+
+  The precise value also depends on the interface MTU. The interface MTU,
+  in turn, may trigger IP fragmentation. In this case, the generated
+  UDP-Lite packet is split into several IP packets, of which only the
+  first one contains the L4 header.
+
+  The send buffer size has implications on the checksum coverage length.
+  Consider the following example:
+
+  Payload: 1536 bytes          Send Buffer:     1024 bytes
+  MTU:     1500 bytes          Coverage Length:  856 bytes
+
+  UDP-Lite will ship the 1536 bytes in two separate packets:
+
+  Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
+  Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes
+
+  The coverage packet covers the UDP-Lite header and 848 bytes of the
+  payload in the first packet, the second packet is fully covered. Note
+  that for the second packet, the coverage length exceeds the packet
+  length. The kernel always re-adjusts the coverage length to the packet
+  length in such cases.
+
+  As an example of what happens when one UDP-Lite packet is split into
+  several tiny fragments, consider the following example.
+
+  Payload: 1024 bytes            Send buffer size: 1024 bytes
+  MTU:      300 bytes            Coverage length:   575 bytes
+
+  +-+-----------+--------------+--------------+--------------+
+  |8|    272    |      280     |     280      |     280      |
+  +-+-----------+--------------+--------------+--------------+
+               280            560            840           1032
+                                    ^
+  *****checksum coverage*************
+
+  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
+  header). According to the interface MTU, these are split into 4 IP
+  packets (280 byte IP payload + 20 byte IP header). The kernel module
+  sums the contents of the entire first two packets, plus 15 bytes of
+  the last packet before releasing the fragments to the IP module.
+
+  To see the analogous case for IPv6 fragmentation, consider a link
+  MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
+  coverage is less than 1232 bytes (MTU minus IPv6/fragment header
+  lengths), only the first fragment needs to be considered. When using
+  larger checksum coverage lengths, each eligible fragment needs to be
+  checksummed. Suppose we have a checksum coverage of 3062. The buffer
+  of 3356 bytes will be split into the following fragments:
+
+    Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
+    Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
+    Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data
+
+  The first two fragments have to be checksummed in full, of the last
+  fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
+
+  While it is important that such cases are dealt with correctly, they
+  are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
+  performance over wireless (or generally noisy) links and thus smaller
+  coverage lenghts are likely to be expected.
+
+
+  V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
+
+  Exceptional and error conditions are logged to syslog at the KERN_DEBUG
+  level.  Live statistics about UDP-Lite are available in /proc/net/snmp
+  and can (with newer versions of netstat) be viewed using
+
+                            netstat -svu
+
+  This displays UDP-Lite statistics variables, whose meaning is as follows.
+
+   InDatagrams:     Total number of received datagrams.
+
+   NoPorts:         Number of packets received to an unknown port.
+                    These cases are counted separately (not as InErrors).
+
+   InErrors:        Number of erroneous UDP-Lite packets. Errors include:
+                      * internal socket queue receive errors
+                      * packet too short (less than 8 bytes or stated
+                        coverage length exceeds received length)
+                      * xfrm4_policy_check() returned with error
+                      * application has specified larger min. coverage
+                        length than that of incoming packet
+                      * checksum coverage violated
+                      * bad checksum
+
+   OutDatagrams:    Total number of sent datagrams.
+
+   These statistics derive from the UDP MIB (RFC 2013).
+
+
+  VI) IPTABLES
+
+  There is packet match support for UDP-Lite as well as support for the LOG target.
+  If you copy and paste the following line into /etc/protcols,
+
+  udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]
+
+  then
+              iptables -A INPUT -p udplite -j LOG
+
+  will produce logging output to syslog. Dropping and rejecting packets also works.
+
+
+  VII) MAINTAINER ADDRESS
+
+  The UDP-Lite patch was developed at
+                    University of Aberdeen
+                    Electronics Research Group
+                    Department of Engineering
+                    Fraser Noble Building
+                    Aberdeen AB24 3UE; UK
+  The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
+  code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.
diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt
index 0cf654147634..653978dcea7f 100644
--- a/Documentation/networking/wan-router.txt
+++ b/Documentation/networking/wan-router.txt
@@ -412,7 +412,7 @@ beta-2.1.4 Jul 2000		o Dynamic interface configuration:
 
 beta3-2.1.4 Jul 2000            o X25 M_BIT Problem fix.
                                 o Added the Multi-Port PPP
-                                  Updated utilites for the Multi-Port PPP.
+                                  Updated utilities for the Multi-Port PPP.
 
 2.1.4   Aut 2000
                                 o In X25API:
@@ -444,13 +444,13 @@ beta1-2.1.5 	Nov 15 2000
                                         
                                 o Cpipemon
                                         - Added set FT1 commands to the cpipemon. Thus CSU/DSU
-                                          configuraiton can be performed using cpipemon.
+                                          configuration can be performed using cpipemon.
                                           All systems that cannot run cfgft1 GUI utility should
                                           use cpipemon to configure the on board CSU/DSU.
 
 
                                 o Keyboard Led Monitor/Debugger
-                                        - A new utilty /usr/sbin/wpkbdmon uses keyboard leds
+                                        - A new utility /usr/sbin/wpkbdmon uses keyboard leds
                                           to convey operational statistic information of the 
                                           Sangoma WANPIPE cards.
                                         NUM_LOCK    = Line State  (On=connected,    Off=disconnected)
@@ -464,7 +464,7 @@ beta1-2.1.5 	Nov 15 2000
                                         - Appropriate number of devices are dynamically loaded 
                                           based on the number of Sangoma cards found.
 
-                                          Note: The kernel configuraiton option 
+                                          Note: The kernel configuration option 
                                                 CONFIG_WANPIPE_CARDS has been taken out.
                                         
                                 o Fixed the Frame Relay and Chdlc network interfaces so they are
diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt
index 8be626f7c0b8..d7aac9dedeb4 100644
--- a/Documentation/networking/xfrm_sync.txt
+++ b/Documentation/networking/xfrm_sync.txt
@@ -47,10 +47,13 @@ aevent_id structure looks like:
 
    struct xfrm_aevent_id {
              struct xfrm_usersa_id           sa_id;
+             xfrm_address_t                  saddr;
              __u32                           flags;
+             __u32                           reqid;
    };
 
-xfrm_usersa_id in this message layout identifies the SA.
+The unique SA is identified by the combination of xfrm_usersa_id,
+reqid and saddr.
 
 flags are used to indicate different things. The possible
 flags are:
diff --git a/Documentation/pnp.txt b/Documentation/pnp.txt
index 9ff966bf76e6..28037aa1846c 100644
--- a/Documentation/pnp.txt
+++ b/Documentation/pnp.txt
@@ -184,7 +184,7 @@ static const struct pnp_id pnp_dev_table[] = {
 Please note that the character 'X' can be used as a wild card in the function
 portion (last four characters).
 ex:
-        /* Unkown PnP modems */
+        /* Unknown PnP modems */
         {       "PNPCXXX",              UNKNOWN_DEV     },
 
 Supported PnP card IDs can optionally be defined.
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt
index a66bec222b16..74311d7e0f3c 100644
--- a/Documentation/power/interface.txt
+++ b/Documentation/power/interface.txt
@@ -30,6 +30,17 @@ testing). The system will support either 'firmware' or 'platform', and
 that is known a priori. But, the user may choose 'shutdown' or
 'reboot' as alternatives. 
 
+Additionally, /sys/power/disk can be used to turn on one of the two testing
+modes of the suspend-to-disk mechanism: 'testproc' or 'test'.  If the
+suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to
+/sys/power/state will cause the kernel to disable nonboot CPUs and freeze
+tasks, wait for 5 seconds, unfreeze tasks and enable nonboot CPUs.  If it is
+in the 'test' mode, writing 'disk' to /sys/power/state will cause the kernel
+to disable nonboot CPUs and freeze tasks, shrink memory, suspend devices, wait
+for 5 seconds, resume devices, unfreeze tasks and enable nonboot CPUs.  Then,
+we are able to look in the log messages and work out, for example, which code
+is being slow and which device drivers are misbehaving.
+
 Reading from this file will display what the mode is currently set
 to. Writing to this file will accept one of
 
@@ -37,6 +48,8 @@ to. Writing to this file will accept one of
        'platform'
        'shutdown'
        'reboot'
+       'testproc'
+       'test'
 
 It will only change to 'firmware' or 'platform' if the system supports
 it. 
diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt
index 24edf25b3bb7..c750f9f2e76e 100644
--- a/Documentation/power/pci.txt
+++ b/Documentation/power/pci.txt
@@ -153,7 +153,7 @@ Description:
         events, which is implicit if it doesn't even support it in the first
         place).
 
-        Note that the PMC Register in the device's PM Capabilties has a bitmask
+        Note that the PMC Register in the device's PM Capabilities has a bitmask
         of the states it supports generating PME# from. D3hot is bit 3 and
         D3cold is bit 4. So, while a value of 4 as the state may not seem
         semantically correct, it is. 
@@ -268,7 +268,7 @@ to wake the system up. (However, it is possible that a device may support
 some non-standard way of generating a wake event on sleep.)
 
 Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's
-PM Capabilties describe what power states the device supports generating a 
+PM Capabilities describe what power states the device supports generating a 
 wake event from:
 
 +------------------+
diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.txt
new file mode 100644
index 000000000000..b05f512130ea
--- /dev/null
+++ b/Documentation/power/s2ram.txt
@@ -0,0 +1,56 @@
+                        How to get s2ram working
+                        ~~~~~~~~~~~~~~~~~~~~~~~~
+                        2006 Linus Torvalds
+                        2006 Pavel Machek
+
+1) Check suspend.sf.net, program s2ram there has long whitelist of
+   "known ok" machines, along with tricks to use on each one.
+
+2) If that does not help, try reading tricks.txt and
+   video.txt. Perhaps problem is as simple as broken module, and
+   simple module unload can fix it.
+
+3) You can use Linus' TRACE_RESUME infrastructure, described below.
+
+                      Using TRACE_RESUME
+                      ~~~~~~~~~~~~~~~~~~
+
+I've been working at making the machines I have able to STR, and almost
+always it's a driver that is buggy. Thank God for the suspend/resume
+debugging - the thing that Chuck tried to disable. That's often the _only_
+way to debug these things, and it's actually pretty powerful (but
+time-consuming - having to insert TRACE_RESUME() markers into the device
+driver that doesn't resume and recompile and reboot).
+
+Anyway, the way to debug this for people who are interested (have a
+machine that doesn't boot) is:
+
+ - enable PM_DEBUG, and PM_TRACE
+
+ - use a script like this:
+
+        #!/bin/sh
+        sync
+        echo 1 > /sys/power/pm_trace
+        echo mem > /sys/power/state
+
+   to suspend
+
+ - if it doesn't come back up (which is usually the problem), reboot by
+   holding the power button down, and look at the dmesg output for things
+   like
+
+        Magic number: 4:156:725
+        hash matches drivers/base/power/resume.c:28
+        hash matches device 0000:01:00.0
+
+   which means that the last trace event was just before trying to resume
+   device 0000:01:00.0. Then figure out what driver is controlling that
+   device (lspci and /sys/devices/pci* is your friend), and see if you can
+   fix it, disable it, or trace into its resume function.
+
+For example, the above happens to be the VGA device on my EVO, which I
+used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
+that "radeonfb" simply cannot resume that device - it tries to set the
+PLL's, and it just _hangs_. Using the regular VGA console and letting X
+resume it instead works fine.
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
index 3e5e5d3ff419..0931a330d362 100644
--- a/Documentation/power/states.txt
+++ b/Documentation/power/states.txt
@@ -62,7 +62,7 @@ setup via another operating system for it to use. Despite the
 inconvenience, this method requires minimal work by the kernel, since
 the firmware will also handle restoring memory contents on resume. 
 
-If the kernel is responsible for persistantly saving state, a mechanism 
+If the kernel is responsible for persistently saving state, a mechanism
 called 'swsusp' (Swap Suspend) is used to write memory contents to
 free swap space. swsusp has some restrictive requirements, but should
 work in most cases. Some, albeit outdated, documentation can be found
diff --git a/Documentation/power/swsusp-and-swap-files.txt b/Documentation/power/swsusp-and-swap-files.txt
new file mode 100644
index 000000000000..06f911a5f885
--- /dev/null
+++ b/Documentation/power/swsusp-and-swap-files.txt
@@ -0,0 +1,60 @@
+Using swap files with software suspend (swsusp)
+        (C) 2006 Rafael J. Wysocki <rjw@sisk.pl>
+
+The Linux kernel handles swap files almost in the same way as it handles swap
+partitions and there are only two differences between these two types of swap
+areas:
+(1) swap files need not be contiguous,
+(2) the header of a swap file is not in the first block of the partition that
+holds it.  From the swsusp's point of view (1) is not a problem, because it is
+already taken care of by the swap-handling code, but (2) has to be taken into
+consideration.
+
+In principle the location of a swap file's header may be determined with the
+help of appropriate filesystem driver.  Unfortunately, however, it requires the
+filesystem holding the swap file to be mounted, and if this filesystem is
+journaled, it cannot be mounted during resume from disk.  For this reason to
+identify a swap file swsusp uses the name of the partition that holds the file
+and the offset from the beginning of the partition at which the swap file's
+header is located.  For convenience, this offset is expressed in <PAGE_SIZE>
+units.
+
+In order to use a swap file with swsusp, you need to:
+
+1) Create the swap file and make it active, eg.
+
+# dd if=/dev/zero of=<swap_file_path> bs=1024 count=<swap_file_size_in_k>
+# mkswap <swap_file_path>
+# swapon <swap_file_path>
+
+2) Use an application that will bmap the swap file with the help of the
+FIBMAP ioctl and determine the location of the file's swap header, as the
+offset, in <PAGE_SIZE> units, from the beginning of the partition which
+holds the swap file.
+
+3) Add the following parameters to the kernel command line:
+
+resume=<swap_file_partition> resume_offset=<swap_file_offset>
+
+where <swap_file_partition> is the partition on which the swap file is located
+and <swap_file_offset> is the offset of the swap header determined by the
+application in 2) (of course, this step may be carried out automatically
+by the same application that determies the swap file's header offset using the
+FIBMAP ioctl)
+
+OR
+
+Use a userland suspend application that will set the partition and offset
+with the help of the SNAPSHOT_SET_SWAP_AREA ioctl described in
+Documentation/power/userland-swsusp.txt (this is the only method to suspend
+to a swap file allowing the resume to be initiated from an initrd or initramfs
+image).
+
+Now, swsusp will use the swap file in the same way in which it would use a swap
+partition.  In particular, the swap file has to be active (ie. be present in
+/proc/swaps) so that it can be used for suspending.
+
+Note that if the swap file used for suspending is deleted and recreated,
+the location of its header need not be the same as before.  Thus every time
+this happens the value of the "resume_offset=" kernel command line parameter
+has to be updated.
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index 9ea2208b43b5..0761ff6c57ed 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -153,7 +153,7 @@ add:
 
 If the thread is needed for writing the image to storage, you should
 instead set the PF_NOFREEZE process flag when creating the thread (and
-be very carefull).
+be very careful).
 
 
 Q: What is the difference between "platform", "shutdown" and
@@ -297,20 +297,12 @@ system is shut down or suspended. Additionally use the encrypted
 suspend image to prevent sensitive data from being stolen after
 resume.
 
-Q: Why can't we suspend to a swap file?
+Q: Can I suspend to a swap file?
 
-A: Because accessing swap file needs the filesystem mounted, and
-filesystem might do something wrong (like replaying the journal)
-during mount.
-
-There are few ways to get that fixed:
-
-1) Probably could be solved by modifying every filesystem to support
-some kind of "really read-only!" option. Patches welcome.
-
-2) suspend2 gets around that by storing absolute positions in on-disk
-image (and blocksize), with resume parameter pointing directly to
-suspend header.
+A: Generally, yes, you can.  However, it requires you to use the "resume=" and
+"resume_offset=" kernel command line parameters, so the resume from a swap file
+cannot be initiated from an initrd or initramfs image.  See
+swsusp-and-swap-files.txt for details.
 
 Q: Is there a maximum system RAM size that is supported by swsusp?
 
diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt
index 64755e9285db..000556c932e9 100644
--- a/Documentation/power/userland-swsusp.txt
+++ b/Documentation/power/userland-swsusp.txt
@@ -9,9 +9,8 @@ done it already.
 Now, to use the userland interface for software suspend you need special
 utilities that will read/write the system memory snapshot from/to the
 kernel.  Such utilities are available, for example, from
-<http://www.sisk.pl/kernel/utilities/suspend>.  You may want to have
-a look at them if you are going to develop your own suspend/resume
-utilities.
+<http://suspend.sourceforge.net>.  You may want to have a look at them if you
+are going to develop your own suspend/resume utilities.
 
 The interface consists of a character device providing the open(),
 release(), read(), and write() operations as well as several ioctl()
@@ -21,9 +20,9 @@ be read from /sys/class/misc/snapshot/dev.
 
 The device can be open either for reading or for writing.  If open for
 reading, it is considered to be in the suspend mode.  Otherwise it is
-assumed to be in the resume mode.  The device cannot be open for reading
-and writing.  It is also impossible to have the device open more than once
-at a time.
+assumed to be in the resume mode.  The device cannot be open for simultaneous
+reading and writing.  It is also impossible to have the device open more than
+once at a time.
 
 The ioctl() commands recognized by the device are:
 
@@ -69,9 +68,46 @@ SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated with
 SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument
         should specify the device's major and minor numbers in the old
         two-byte format, as returned by the stat() function in the .st_rdev
-        member of the stat structure); it is recommended to always use this
-        call, because the code to set the resume partition could be removed from
-        future kernels
+        member of the stat structure)
+
+SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE>
+        units) from the beginning of the partition at which the swap header is
+        located (the last ioctl() argument should point to a struct
+        resume_swap_area, as defined in kernel/power/power.h, containing the
+        resume device specification, as for the SNAPSHOT_SET_SWAP_FILE ioctl(),
+        and the offset); for swap partitions the offset is always 0, but it is
+        different to zero for swap files (please see
+        Documentation/swsusp-and-swap-files.txt for details).
+        The SNAPSHOT_SET_SWAP_AREA ioctl() is considered as a replacement for
+        SNAPSHOT_SET_SWAP_FILE which is regarded as obsolete.   It is
+        recommended to always use this call, because the code to set the resume
+        partition may be removed from future kernels
+
+SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
+        immediately enter the suspend-to-RAM state, so this call must always
+        be preceded by the SNAPSHOT_FREEZE call and it is also necessary
+        to use the SNAPSHOT_UNFREEZE call after the system wakes up.  This call
+        is needed to implement the suspend-to-both mechanism in which the
+        suspend image is first created, as though the system had been suspended
+        to disk, and then the system is suspended to RAM (this makes it possible
+        to resume the system from RAM if there's enough battery power or restore
+        its state on the basis of the saved suspend image otherwise)
+
+SNAPSHOT_PMOPS - enable the usage of the pmops->prepare, pmops->enter and
+        pmops->finish methods (the in-kernel swsusp knows these as the "platform
+        method") which are needed on many machines to (among others) speed up
+        the resume by letting the BIOS skip some steps or to let the system
+        recognise the correct state of the hardware after the resume (in
+        particular on many machines this ensures that unplugged AC
+        adapters get correctly detected and that kacpid does not run wild after
+        the resume).  The last ioctl() argument can take one of the three
+        values, defined in kernel/power/power.h:
+        PMOPS_PREPARE - make the kernel carry out the
+                pm_ops->prepare(PM_SUSPEND_DISK) operation
+        PMOPS_ENTER - make the kernel power off the system by calling
+                pm_ops->enter(PM_SUSPEND_DISK)
+        PMOPS_FINISH - make the kernel carry out the
+                pm_ops->finish(PM_SUSPEND_DISK) operation
 
 The device's read() operation can be used to transfer the snapshot image from
 the kernel.  It has the following limitations:
@@ -91,10 +127,12 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
 still frozen when the device is being closed).
 
 Currently it is assumed that the userland utilities reading/writing the
-snapshot image from/to the kernel will use a swap partition, called the resume
-partition, as storage space.  However, this is not really required, as they
-can use, for example, a special (blank) suspend partition or a file on a partition
-that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and mounted afterwards.
+snapshot image from/to the kernel will use a swap parition, called the resume
+partition, or a swap file as storage space (if a swap file is used, the resume
+partition is the partition that holds this file).  However, this is not really
+required, as they can use, for example, a special (blank) suspend partition or
+a file on a partition that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and
+mounted afterwards.
 
 These utilities SHOULD NOT make any assumptions regarding the ordering of
 data within the snapshot image, except for the image header that MAY be
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 27b457c09729..b3bd36668db3 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
     IBM Corp.
 (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
     Freescale Semiconductor, FSL SOC and 32-bit additions
+(c) 2006 MontaVista Software, Inc.
+    Flash chip node definition
 
    May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
 
@@ -33,13 +35,13 @@
                          - Change version 16 format to always align
                            property data to 4 bytes. Since tokens are
                            already aligned, that means no specific
-                           required alignement between property size
+                           required alignment between property size
                            and property data. The old style variable
                            alignment would make it impossible to do
                            "simple" insertion of properties using
                            memove (thanks Milton for
                            noticing). Updated kernel patch as well
-                         - Correct a few more alignement constraints
+                         - Correct a few more alignment constraints
                          - Add a chapter about the device-tree
                            compiler and the textural representation of
                            the tree that can be "compiled" by dtc.
@@ -854,7 +856,7 @@ address which can extend beyond that limit.
       console device if any. Typically, if you have serial devices on
       your board, you may want to put the full path to the one set as
       the default console in the firmware here, for the kernel to pick
-      it up as it's own default console. If you look at the funciton
+      it up as its own default console. If you look at the function
       set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
       that the kernel tries to find out the default console and has
       knowledge of various types like 8250 serial ports. You may want
@@ -1124,7 +1126,7 @@ should have the following properties:
         - interrupt-parent : contains the phandle of the interrupt
           controller which handles interrupts for this device
         - interrupts : a list of tuples representing the interrupt
-          number and the interrupt sense and level for each interupt
+          number and the interrupt sense and level for each interrupt
           for this device.
 
 This information is used by the kernel to build the interrupt table
@@ -1693,6 +1695,43 @@ platforms are moved over to use the flattened-device-tree model.
                 };
         };
 
+    g) Flash chip nodes
+
+    Flash chips (Memory Technology Devices) are often used for solid state
+    file systems on embedded devices.
+
+    Required properties:
+
+     - device_type : has to be "rom"
+     - compatible : Should specify what this ROM device is compatible with
+       (i.e. "onenand"). Currently, this is most likely to be "direct-mapped"
+       (which corresponds to the MTD physmap mapping driver).
+     - regs : Offset and length of the register set (or memory mapping) for
+       the device.
+
+    Recommended properties :
+
+     - bank-width : Width of the flash data bus in bytes. Required
+       for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
+     - partitions : Several pairs of 32-bit values where the first value is
+       partition's offset from the start of the device and the second one is
+       partition size in bytes with LSB used to signify a read only
+       partititon (so, the parition size should always be an even number).
+     - partition-names : The list of concatenated zero terminated strings
+       representing the partition names.
+
+   Example:
+
+        flash@ff000000 {
+                device_type = "rom";
+                compatible = "direct-mapped";
+                regs = <ff000000 01000000>;
+                bank-width = <4>;
+                partitions = <00000000 00f80000
+                              00f80000 00080001>;
+                partition-names = "fs\0firmware";
+        };
+
    More devices will be defined as this spec matures.
 
 
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
new file mode 100644
index 000000000000..d077d764f82b
--- /dev/null
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -0,0 +1,189 @@
+MPC52xx Device Tree Bindings
+----------------------------
+
+(c) 2006 Secret Lab Technologies Ltd
+Grant Likely <grant.likely at secretlab.ca>
+
+I - Introduction
+================
+Boards supported by the arch/powerpc architecture require device tree be
+passed by the boot loader to the kernel at boot time.  The device tree
+describes what devices are present on the board and how they are
+connected.  The device tree can either be passed as a binary blob (as
+described in Documentation/powerpc/booting-without-of.txt), or passed
+by Open Firmare (IEEE 1275) compatible firmware using an OF compatible
+client interface API.
+
+This document specifies the requirements on the device-tree for mpc52xx
+based boards.  These requirements are above and beyond the details
+specified in either the OpenFirmware spec or booting-without-of.txt
+
+All new mpc52xx-based boards are expected to match this document.  In
+cases where this document is not sufficient to support a new board port,
+this document should be updated as part of adding the new board support.
+
+II - Philosophy
+===============
+The core of this document is naming convention.  The whole point of
+defining this convention is to reduce or eliminate the number of
+special cases required to support a 52xx board.  If all 52xx boards
+follow the same convention, then generic 52xx support code will work
+rather than coding special cases for each new board.
+
+This section tries to capture the thought process behind why the naming
+convention is what it is.
+
+1. Node names
+-------------
+There is strong convention/requirements already established for children
+of the root node.  'cpus' describes the processor cores, 'memory'
+describes memory, and 'chosen' provides boot configuration.  Other nodes
+are added to describe devices attached to the processor local bus.
+Following convention already established with other system-on-chip
+processors, MPC52xx boards must have an 'soc5200' node as a child of the
+root node.
+
+The soc5200 node holds child nodes for all on chip devices.  Child nodes
+are typically named after the configured function.  ie. the FEC node is
+named 'ethernet', and a PSC in uart mode is named 'serial'.
+
+2. device_type property
+-----------------------
+similar to the node name convention above; the device_type reflects the
+configured function of a device.  ie. 'serial' for a uart and 'spi' for
+an spi controller.  However, while node names *should* reflect the
+configured function, device_type *must* match the configured function
+exactly.
+
+3. compatible property
+----------------------
+Since device_type isn't enough to match devices to drivers, there also
+needs to be a naming convention for the compatible property.  Compatible
+is an list of device descriptions sorted from specific to generic.  For
+the mpc52xx, the required format for each compatible value is
+<chip>-<device>[-<mode>].  At the minimum, the list shall contain two
+items; the first specifying the exact chip, and the second specifying
+mpc52xx for the chip.
+
+ie. ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc52xx-ethernet"
+
+The idea here is that most drivers will match to the most generic field
+in the compatible list (mpc52xx-*), but can also test the more specific
+field for enabling bug fixes or extra features.
+
+Modal devices, like PSCs, also append the configured function to the
+end of the compatible field.  ie. A PSC in i2s mode would specify
+"mpc52xx-psc-i2s", not "mpc52xx-i2s".  This convention is chosen to
+avoid naming conflicts with non-psc devices providing the same
+function.  For example, "mpc52xx-spi" and "mpc52xx-psc-spi" describe
+the mpc5200 simple spi device and a PSC spi mode respectively.
+
+If the soc device is more generic and present on other SOCs, the
+compatible property can specify the more generic device type also.
+
+ie. mscan: compatible = "mpc5200-mscan\0mpc52xx-mscan\0fsl,mscan";
+
+At the time of writing, exact chip may be either 'mpc5200' or
+'mpc5200b'.
+
+Device drivers should always try to match as generically as possible.
+
+III - Structure
+===============
+The device tree for an mpc52xx board follows the structure defined in
+booting-without-of.txt with the following additional notes:
+
+0) the root node
+----------------
+Typical root description node; see booting-without-of
+
+1) The cpus node
+----------------
+The cpus node follows the basic layout described in booting-without-of.
+The bus-frequency property holds the XLB bus frequency
+The clock-frequency property holds the core frequency
+
+2) The memory node
+------------------
+Typical memory description node; see booting-without-of.
+
+3) The soc5200 node
+-------------------
+This node describes the on chip SOC peripherals.  Every mpc52xx based
+board will have this node, and as such there is a common naming
+convention for SOC devices.
+
+Required properties:
+name                    type            description
+----                    ----            -----------
+device_type             string          must be "soc"
+ranges                  int             should be <0 baseaddr baseaddr+10000>
+reg                     int             must be <baseaddr 10000>
+
+Recommended properties:
+name                    type            description
+----                    ----            -----------
+compatible              string          should be "<chip>-soc\0mpc52xx-soc"
+                                        ie. "mpc5200b-soc\0mpc52xx-soc"
+#interrupt-cells        int             must be <3>.  If it is not defined
+                                        here then it must be defined in every
+                                        soc device node.
+bus-frequency           int             IPB bus frequency in HZ.  Clock rate
+                                        used by most of the soc devices.
+                                        Defining it here avoids needing it
+                                        added to every device node.
+
+4) soc5200 child nodes
+----------------------
+Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
+
+Note: in the tables below, '*' matches all <chip> values.  ie.
+*-pic would translate to "mpc5200-pic\0mpc52xx-pic"
+
+Required soc5200 child nodes:
+name            device_type             compatible      Description
+----            -----------             ----------      -----------
+cdm@<addr>      cdm                     *-cmd           Clock Distribution
+pic@<addr>      interrupt-controller    *-pic           need an interrupt
+                                                        controller to boot
+bestcomm@<addr> dma-controller          *-bestcomm      52xx pic also requires
+                                                        the bestcomm device
+
+Recommended soc5200 child nodes; populate as needed for your board
+name            device_type     compatible      Description
+----            -----------     ----------      -----------
+gpt@<addr>      gpt             *-gpt           General purpose timers
+rtc@<addr>      rtc             *-rtc           Real time clock
+mscan@<addr>    mscan           *-mscan         CAN bus controller
+pci@<addr>      pci             *-pci           PCI bridge
+serial@<addr>   serial          *-psc-uart      PSC in serial mode
+i2s@<addr>      i2s             *-psc-i2s       PSC in i2s mode
+ac97@<addr>     ac97            *-psc-ac97      PSC in ac97 mode
+spi@<addr>      spi             *-psc-spi       PSC in spi mode
+irda@<addr>     irda            *-psc-irda      PSC in IrDA mode
+spi@<addr>      spi             *-spi           MPC52xx spi device
+ethernet@<addr> network         *-fec           MPC52xx ethernet device
+ata@<addr>      ata             *-ata           IDE ATA interface
+i2c@<addr>      i2c             *-i2c           I2C controller
+usb@<addr>      usb-ohci-be     *-ohci,ohci-be  USB controller
+xlb@<addr>      xlb             *-xlb           XLB arbritrator
+
+IV - Extra Notes
+================
+
+1. Interrupt mapping
+--------------------
+The mpc52xx pic driver splits hardware IRQ numbers into two levels.  The
+split reflects the layout of the PIC hardware itself, which groups
+interrupts into one of three groups; CRIT, MAIN or PERP.  Also, the
+Bestcomm dma engine has it's own set of interrupt sources which are
+cascaded off of peripheral interrupt 0, which the driver interprets as a
+fourth group, SDMA.
+
+The interrupts property for device nodes using the mpc52xx pic consists
+of three cells; <L1 L2 level>
+
+    L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
+    L2 := interrupt number; directly mapped from the value in the
+          "ICTL PerStat, MainStat, CritStat Encoded Register"
+    level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
diff --git a/Documentation/robust-futex-ABI.txt b/Documentation/robust-futex-ABI.txt
index 8529a17ffaa1..535f69fab45f 100644
--- a/Documentation/robust-futex-ABI.txt
+++ b/Documentation/robust-futex-ABI.txt
@@ -170,7 +170,7 @@ any point:
  1) the 'head' pointer or an subsequent linked list pointer
     is not a valid address of a user space word
  2) the calculated location of the 'lock word' (address plus
-    'offset') is not the valud address of a 32 bit user space
+    'offset') is not the valid address of a 32 bit user space
     word
  3) if the list contains more than 1 million (subject to
     future kernel configuration changes) elements.
diff --git a/Documentation/robust-futexes.txt b/Documentation/robust-futexes.txt
index 76e8064b8c3a..0a9446a53bd1 100644
--- a/Documentation/robust-futexes.txt
+++ b/Documentation/robust-futexes.txt
@@ -181,7 +181,7 @@ for new threads, without the need of another syscall.]
 So there is virtually zero overhead for tasks not using robust futexes,
 and even for robust futex users, there is only one extra syscall per
 thread lifetime, and the cleanup operation, if it happens, is fast and
-straightforward. The kernel doesnt have any internal distinction between
+straightforward. The kernel doesn't have any internal distinction between
 robust and normal futexes.
 
 If a futex is found to be held at exit time, the kernel sets the
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 2a58f985795a..7cf1ec5bcdd3 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -1,12 +1,49 @@
 
-        Real Time Clock Driver for Linux
-        ================================
+        Real Time Clock (RTC) Drivers for Linux
+        =======================================
+
+When Linux developers talk about a "Real Time Clock", they usually mean
+something that tracks wall clock time and is battery backed so that it
+works even with system power off.  Such clocks will normally not track
+the local time zone or daylight savings time -- unless they dual boot
+with MS-Windows -- but will instead be set to Coordinated Universal Time
+(UTC, formerly "Greenwich Mean Time").
+
+The newest non-PC hardware tends to just count seconds, like the time(2)
+system call reports, but RTCs also very commonly represent time using
+the Gregorian calendar and 24 hour time, as reported by gmtime(3).
+
+Linux has two largely-compatible userspace RTC API families you may
+need to know about:
+
+    *   /dev/rtc ... is the RTC provided by PC compatible systems,
+        so it's not very portable to non-x86 systems.
+
+    *   /dev/rtc0, /dev/rtc1 ... are part of a framework that's
+        supported by a wide variety of RTC chips on all systems.
+
+Programmers need to understand that the PC/AT functionality is not
+always available, and some systems can do much more.  That is, the
+RTCs use the same API to make requests in both RTC frameworks (using
+different filenames of course), but the hardware may not offer the
+same functionality.  For example, not every RTC is hooked up to an
+IRQ, so they can't all issue alarms; and where standard PC RTCs can
+only issue an alarm up to 24 hours in the future, other hardware may
+be able to schedule one any time in the upcoming century.
+
+
+        Old PC/AT-Compatible driver:  /dev/rtc
+        --------------------------------------
 
 All PCs (even Alpha machines) have a Real Time Clock built into them.
 Usually they are built into the chipset of the computer, but some may
 actually have a Motorola MC146818 (or clone) on the board. This is the
 clock that keeps the date and time while your computer is turned off.
 
+ACPI has standardized that MC146818 functionality, and extended it in
+a few ways (enabling longer alarm periods, and wake-from-hibernate).
+That functionality is NOT exposed in the old driver.
+
 However it can also be used to generate signals from a slow 2Hz to a
 relatively fast 8192Hz, in increments of powers of two. These signals
 are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is
@@ -63,223 +100,331 @@ Rather than write 50 pages describing the ioctl() and so on, it is
 perhaps more useful to include a small test program that demonstrates
 how to use them, and demonstrates the features of the driver. This is
 probably a lot more useful to people interested in writing applications
-that will be using this driver.
+that will be using this driver.  See the code at the end of this document.
+
+(The original /dev/rtc driver was written by Paul Gortmaker.)
+
+
+        New portable "RTC Class" drivers:  /dev/rtcN
+        --------------------------------------------
+
+Because Linux supports many non-ACPI and non-PC platforms, some of which
+have more than one RTC style clock, it needed a more portable solution
+than expecting a single battery-backed MC146818 clone on every system.
+Accordingly, a new "RTC Class" framework has been defined.  It offers
+three different userspace interfaces:
+
+    *   /dev/rtcN ... much the same as the older /dev/rtc interface
+
+    *   /sys/class/rtc/rtcN ... sysfs attributes support readonly
+        access to some RTC attributes.
+
+    *   /proc/driver/rtc ... the first RTC (rtc0) may expose itself
+        using a procfs interface.  More information is (currently) shown
+        here than through sysfs.
+
+The RTC Class framework supports a wide variety of RTCs, ranging from those
+integrated into embeddable system-on-chip (SOC) processors to discrete chips
+using I2C, SPI, or some other bus to communicate with the host CPU.  There's
+even support for PC-style RTCs ... including the features exposed on newer PCs
+through ACPI.
+
+The new framework also removes the "one RTC per system" restriction.  For
+example, maybe the low-power battery-backed RTC is a discrete I2C chip, but
+a high functionality RTC is integrated into the SOC.  That system might read
+the system clock from the discrete RTC, but use the integrated one for all
+other tasks, because of its greater functionality.
+
+The ioctl() calls supported by /dev/rtc are also supported by the RTC class
+framework.  However, because the chips and systems are not standardized,
+some PC/AT functionality might not be provided.  And in the same way, some
+newer features -- including those enabled by ACPI -- are exposed by the
+RTC class framework, but can't be supported by the older driver.
+
+    *   RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading
+        time, returning the result as a Gregorian calendar date and 24 hour
+        wall clock time.  To be most useful, this time may also be updated.
+
+    *   RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC
+        is connected to an IRQ line, it can often issue an alarm IRQ up to
+        24 hours in the future.
+
+    *   RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond
+        the next 24 hours use a slightly more powerful API, which supports
+        setting the longer alarm time and enabling its IRQ using a single
+        request (using the same model as EFI firmware).
+
+    *   RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
+        also offers update IRQs whenever the "seconds" counter changes.
+        If needed, the RTC framework can emulate this mechanism.
+
+    *   RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another
+        feature often accessible with an IRQ line is a periodic IRQ, issued
+        at settable frequencies (usually 2^N Hz).
+
+In many cases, the RTC alarm can be a system wake event, used to force
+Linux out of a low power sleep state (or hibernation) back to a fully
+operational state.  For example, a system could enter a deep power saving
+state until it's time to execute some scheduled tasks.
 
-                                                Paul Gortmaker
 
 -------------------- 8< ---------------- 8< -----------------------------
 
 /*
- *      Real Time Clock Driver Test/Example Program
+ *      Real Time Clock Driver Test/Example Program
  *
- *      Compile with:
- *              gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
+ *      Compile with:
+ *                   gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
  *
- *      Copyright (C) 1996, Paul Gortmaker.
+ *      Copyright (C) 1996, Paul Gortmaker.
  *
- *      Released under the GNU General Public License, version 2,
- *      included herein by reference.
+ *      Released under the GNU General Public License, version 2,
+ *      included herein by reference.
  *
  */
 
 #include <stdio.h>
-#include <stdlib.h>
 #include <linux/rtc.h>
 #include <sys/ioctl.h>
 #include <sys/time.h>
 #include <sys/types.h>
 #include <fcntl.h>
 #include <unistd.h>
+#include <stdlib.h>
 #include <errno.h>
 
-int main(void) {
-
-int i, fd, retval, irqcount = 0;
-unsigned long tmp, data;
-struct rtc_time rtc_tm;
 
-fd = open ("/dev/rtc", O_RDONLY);
+/*
+ * This expects the new RTC class driver framework, working with
+ * clocks that will often not be clones of what the PC-AT had.
+ * Use the command line to specify another RTC if you need one.
+ */
+static const char default_rtc[] = "/dev/rtc0";
+
+
+int main(int argc, char **argv)
+{
+        int i, fd, retval, irqcount = 0;
+        unsigned long tmp, data;
+        struct rtc_time rtc_tm;
+        const char *rtc = default_rtc;
+
+        switch (argc) {
+        case 2:
+                rtc = argv[1];
+                /* FALLTHROUGH */
+        case 1:
+                break;
+        default:
+                fprintf(stderr, "usage:  rtctest [rtcdev]\n");
+                return 1;
+        }
 
-if (fd ==  -1) {
-        perror("/dev/rtc");
-        exit(errno);
-}
+        fd = open(rtc, O_RDONLY);
 
-fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
+        if (fd ==  -1) {
+                perror(rtc);
+                exit(errno);
+        }
 
-/* Turn on update interrupts (one per second) */
-retval = ioctl(fd, RTC_UIE_ON, 0);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
+        fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
 
-fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
-fflush(stderr);
-for (i=1; i<6; i++) {
-        /* This read will block */
-        retval = read(fd, &data, sizeof(unsigned long));
+        /* Turn on update interrupts (one per second) */
+        retval = ioctl(fd, RTC_UIE_ON, 0);
         if (retval == -1) {
-                perror("read");
+                if (errno == ENOTTY) {
+                        fprintf(stderr,
+                                "\n...Update IRQs not supported.\n");
+                        goto test_READ;
+                }
+                perror("ioctl");
                 exit(errno);
         }
-        fprintf(stderr, " %d",i);
+
+        fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
+                        rtc);
         fflush(stderr);
-        irqcount++;
-}
+        for (i=1; i<6; i++) {
+                /* This read will block */
+                retval = read(fd, &data, sizeof(unsigned long));
+                if (retval == -1) {
+                        perror("read");
+                        exit(errno);
+                }
+                fprintf(stderr, " %d",i);
+                fflush(stderr);
+                irqcount++;
+        }
 
-fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
-fflush(stderr);
-for (i=1; i<6; i++) {
-        struct timeval tv = {5, 0};     /* 5 second timeout on select */
-        fd_set readfds;
+        fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
+        fflush(stderr);
+        for (i=1; i<6; i++) {
+                struct timeval tv = {5, 0};     /* 5 second timeout on select */
+                fd_set readfds;
+
+                FD_ZERO(&readfds);
+                FD_SET(fd, &readfds);
+                /* The select will wait until an RTC interrupt happens. */
+                retval = select(fd+1, &readfds, NULL, NULL, &tv);
+                if (retval == -1) {
+                        perror("select");
+                        exit(errno);
+                }
+                /* This read won't block unlike the select-less case above. */
+                retval = read(fd, &data, sizeof(unsigned long));
+                if (retval == -1) {
+                        perror("read");
+                        exit(errno);
+                }
+                fprintf(stderr, " %d",i);
+                fflush(stderr);
+                irqcount++;
+        }
 
-        FD_ZERO(&readfds);
-        FD_SET(fd, &readfds);
-        /* The select will wait until an RTC interrupt happens. */
-        retval = select(fd+1, &readfds, NULL, NULL, &tv);
+        /* Turn off update interrupts */
+        retval = ioctl(fd, RTC_UIE_OFF, 0);
         if (retval == -1) {
-                perror("select");
+                perror("ioctl");
                 exit(errno);
         }
-        /* This read won't block unlike the select-less case above. */
-        retval = read(fd, &data, sizeof(unsigned long));
+
+test_READ:
+        /* Read the RTC time/date */
+        retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
         if (retval == -1) {
-                perror("read");
+                perror("ioctl");
                 exit(errno);
         }
-        fprintf(stderr, " %d",i);
-        fflush(stderr);
-        irqcount++;
-}
-
-/* Turn off update interrupts */
-retval = ioctl(fd, RTC_UIE_OFF, 0);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
-
-/* Read the RTC time/date */
-retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
-
-fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
-        rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
-        rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
-
-/* Set the alarm to 5 sec in the future, and check for rollover */
-rtc_tm.tm_sec += 5;
-if (rtc_tm.tm_sec >= 60) {
-        rtc_tm.tm_sec %= 60;
-        rtc_tm.tm_min++;
-}
-if  (rtc_tm.tm_min == 60) {
-        rtc_tm.tm_min = 0;
-        rtc_tm.tm_hour++;
-}
-if  (rtc_tm.tm_hour == 24)
-        rtc_tm.tm_hour = 0;
-
-retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
-
-/* Read the current alarm settings */
-retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
-
-fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
-        rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
 
-/* Enable alarm interrupts */
-retval = ioctl(fd, RTC_AIE_ON, 0);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
+        fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
+                rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
+                rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
 
-fprintf(stderr, "Waiting 5 seconds for alarm...");
-fflush(stderr);
-/* This blocks until the alarm ring causes an interrupt */
-retval = read(fd, &data, sizeof(unsigned long));
-if (retval == -1) {
-        perror("read");
-        exit(errno);
-}
-irqcount++;
-fprintf(stderr, " okay. Alarm rang.\n");
-
-/* Disable alarm interrupts */
-retval = ioctl(fd, RTC_AIE_OFF, 0);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
+        /* Set the alarm to 5 sec in the future, and check for rollover */
+        rtc_tm.tm_sec += 5;
+        if (rtc_tm.tm_sec >= 60) {
+                rtc_tm.tm_sec %= 60;
+                rtc_tm.tm_min++;
+        }
+        if  (rtc_tm.tm_min == 60) {
+                rtc_tm.tm_min = 0;
+                rtc_tm.tm_hour++;
+        }
+        if  (rtc_tm.tm_hour == 24)
+                rtc_tm.tm_hour = 0;
 
-/* Read periodic IRQ rate */
-retval = ioctl(fd, RTC_IRQP_READ, &tmp);
-if (retval == -1) {
-        perror("ioctl");
-        exit(errno);
-}
-fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);
+        retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
+        if (retval == -1) {
+                if (errno == ENOTTY) {
+                        fprintf(stderr,
+                                "\n...Alarm IRQs not supported.\n");
+                        goto test_PIE;
+                }
+                perror("ioctl");
+                exit(errno);
+        }
 
-fprintf(stderr, "Counting 20 interrupts at:");
-fflush(stderr);
+        /* Read the current alarm settings */
+        retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
+        if (retval == -1) {
+                perror("ioctl");
+                exit(errno);
+        }
 
-/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
-for (tmp=2; tmp<=64; tmp*=2) {
+        fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
+                rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
 
-        retval = ioctl(fd, RTC_IRQP_SET, tmp);
+        /* Enable alarm interrupts */
+        retval = ioctl(fd, RTC_AIE_ON, 0);
         if (retval == -1) {
                 perror("ioctl");
                 exit(errno);
         }
 
-        fprintf(stderr, "\n%ldHz:\t", tmp);
+        fprintf(stderr, "Waiting 5 seconds for alarm...");
         fflush(stderr);
+        /* This blocks until the alarm ring causes an interrupt */
+        retval = read(fd, &data, sizeof(unsigned long));
+        if (retval == -1) {
+                perror("read");
+                exit(errno);
+        }
+        irqcount++;
+        fprintf(stderr, " okay. Alarm rang.\n");
 
-        /* Enable periodic interrupts */
-        retval = ioctl(fd, RTC_PIE_ON, 0);
+        /* Disable alarm interrupts */
+        retval = ioctl(fd, RTC_AIE_OFF, 0);
         if (retval == -1) {
                 perror("ioctl");
                 exit(errno);
         }
 
-        for (i=1; i<21; i++) {
-                /* This blocks */
-                retval = read(fd, &data, sizeof(unsigned long));
+test_PIE:
+        /* Read periodic IRQ rate */
+        retval = ioctl(fd, RTC_IRQP_READ, &tmp);
+        if (retval == -1) {
+                /* not all RTCs support periodic IRQs */
+                if (errno == ENOTTY) {
+                        fprintf(stderr, "\nNo periodic IRQ support\n");
+                        return 0;
+                }
+                perror("ioctl");
+                exit(errno);
+        }
+        fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);
+
+        fprintf(stderr, "Counting 20 interrupts at:");
+        fflush(stderr);
+
+        /* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
+        for (tmp=2; tmp<=64; tmp*=2) {
+
+                retval = ioctl(fd, RTC_IRQP_SET, tmp);
                 if (retval == -1) {
-                        perror("read");
-                        exit(errno);
+                        /* not all RTCs can change their periodic IRQ rate */
+                        if (errno == ENOTTY) {
+                                fprintf(stderr,
+                                        "\n...Periodic IRQ rate is fixed\n");
+                                goto done;
+                        }
+                        perror("ioctl");
+                        exit(errno);
                 }
-                fprintf(stderr, " %d",i);
+
+                fprintf(stderr, "\n%ldHz:\t", tmp);
                 fflush(stderr);
-                irqcount++;
-        }
 
-        /* Disable periodic interrupts */
-        retval = ioctl(fd, RTC_PIE_OFF, 0);
-        if (retval == -1) {
-                perror("ioctl");
-                exit(errno);
+                /* Enable periodic interrupts */
+                retval = ioctl(fd, RTC_PIE_ON, 0);
+                if (retval == -1) {
+                        perror("ioctl");
+                        exit(errno);
+                }
+
+                for (i=1; i<21; i++) {
+                        /* This blocks */
+                        retval = read(fd, &data, sizeof(unsigned long));
+                        if (retval == -1) {
+                                       perror("read");
+                                       exit(errno);
+                        }
+                        fprintf(stderr, " %d",i);
+                        fflush(stderr);
+                        irqcount++;
+                }
+
+                /* Disable periodic interrupts */
+                retval = ioctl(fd, RTC_PIE_OFF, 0);
+                if (retval == -1) {
+                        perror("ioctl");
+                        exit(errno);
+                }
         }
-}
 
-fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
-fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
-                                                                 irqcount);
+done:
+        fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
 
-close(fd);
-return 0;
+        close(fd);
 
-} /* end main */
+        return 0;
+}
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index 59d1166d41ee..22f82f21bc60 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -66,7 +66,7 @@ Command line parameters
 
   When a device is un-ignored, device recognition and sensing is performed and 
   the device driver will be notified if possible, so the device will become
-  available to the system.
+  available to the system. Note that un-ignoring is performed asynchronously.
 
   You can also add ranges of devices to be ignored by piping to 
   /proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
@@ -74,7 +74,7 @@ Command line parameters
 
   Note: While already known devices can be added to the list of devices to be
         ignored, there will be no effect on then. However, if such a device
-        disappears and then reappeares, it will then be ignored.
+        disappears and then reappears, it will then be ignored.
 
   For example,
         "echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
@@ -82,7 +82,7 @@ Command line parameters
   devices.
 
   The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
-  compatibilty, by the device number in hexadecimal (0xabcd or abcd).
+  compatibility, by the device number in hexadecimal (0xabcd or abcd).
 
 
 * /proc/s390dbf/cio_*/ (S/390 debug feature)
diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt
index 4dd25ee549e9..3f9ddbc23b27 100644
--- a/Documentation/s390/Debugging390.txt
+++ b/Documentation/s390/Debugging390.txt
@@ -7,7 +7,7 @@
 
 Overview of Document:
 =====================
-This document is intended to give an good overview of how to debug 
+This document is intended to give a good overview of how to debug
 Linux for s/390 & z/Architecture. It isn't intended as a complete reference & not a
 tutorial on the fundamentals of C & assembly. It doesn't go into
 390 IO in any detail. It is intended to complement the documents in the
@@ -300,7 +300,7 @@ On z/Architecture our page indexes are now 2k in size
 but only mess with 2 segment indices each time we mess with
 a PMD.
 
-3) As z/Architecture supports upto a massive 5-level page table lookup we 
+3) As z/Architecture supports up to a massive 5-level page table lookup we
 can only use 3 currently on Linux ( as this is all the generic kernel
 currently supports ) however this may change in future
 this allows us to access ( according to my sums )
@@ -502,7 +502,7 @@ Notes:
 ------
 1) The only requirement is that registers which are used
 by the callee are saved, e.g. the compiler is perfectly
-capible of using r11 for purposes other than a frame a
+capable of using r11 for purposes other than a frame a
 frame pointer if a frame pointer is not needed.
 2) In functions with variable arguments e.g. printf the calling procedure 
 is identical to one without variable arguments & the same number of 
@@ -846,7 +846,7 @@ of time searching for debugging info. The following self explanatory line should
 instead if the code isn't compiled -g, as it is much faster:
 objdump --disassemble-all --syms vmlinux > vmlinux.lst  
 
-As hard drive space is valuble most of us use the following approach.
+As hard drive space is valuable most of us use the following approach.
 1) Look at the emitted psw on the console to find the crash address in the kernel.
 2) Look at the file System.map ( in the linux directory ) produced when building 
 the kernel to find the closest address less than the current PSW to find the
@@ -902,7 +902,7 @@ A. It is a tool for intercepting calls to the kernel & logging them
 to a file & on the screen.
 
 Q. What use is it ?
-A. You can used it to find out what files a particular program opens.
+A. You can use it to find out what files a particular program opens.
 
 
 
@@ -911,7 +911,7 @@ Example 1
 If you wanted to know does ping work but didn't have the source 
 strace ping -c 1 127.0.0.1  
 & then look at the man pages for each of the syscalls below,
-( In fact this is sometimes easier than looking at some spagetti
+( In fact this is sometimes easier than looking at some spaghetti
 source which conditionally compiles for several architectures ).
 Not everything that it throws out needs to make sense immediately.
 
@@ -1037,7 +1037,7 @@ e.g. man strace, man alarm, man socket.
 
 Performance Debugging
 =====================
-gcc is capible of compiling in profiling code just add the -p option
+gcc is capable of compiling in profiling code just add the -p option
 to the CFLAGS, this obviously affects program size & performance.
 This can be used by the gprof gnu profiling tool or the
 gcov the gnu code coverage tool ( code coverage is a means of testing
@@ -1419,7 +1419,7 @@ On a SMP guest issue a command to all CPUs try prefixing the command with cpu al
 To issue a command to a particular cpu try cpu <cpu number> e.g.
 CPU 01 TR I R 2000.3000
 If you are running on a guest with several cpus & you have a IO related problem
-& cannot follow the flow of code but you know it isnt smp related.
+& cannot follow the flow of code but you know it isn't smp related.
 from the bash prompt issue
 shutdown -h now or halt.
 do a Q CPUS to find out how many cpus you have
@@ -1602,7 +1602,7 @@ V000FFFD0  00010400 80010802 8001085A 000FFFA0
 our 3rd return address is 8001085A
 
 as the 04B52002 looks suspiciously like rubbish it is fair to assume that the kernel entry routines
-for the sake of optimisation dont set up a backchain.
+for the sake of optimisation don't set up a backchain.
 
 now look at System.map to see if the addresses make any sense.
 
@@ -1638,11 +1638,11 @@ more useful information.
 
 Unlike other bus architectures modern 390 systems do their IO using mostly
 fibre optics & devices such as tapes & disks can be shared between several mainframes,
-also S390 can support upto 65536 devices while a high end PC based system might be choking 
+also S390 can support up to 65536 devices while a high end PC based system might be choking
 with around 64. Here is some of the common IO terminology
 
 Subchannel:
-This is the logical number most IO commands use to talk to an IO device there can be upto
+This is the logical number most IO commands use to talk to an IO device there can be up to
 0x10000 (65536) of these in a configuration typically there is a few hundred. Under VM
 for simplicity they are allocated contiguously, however on the native hardware they are not
 they typically stay consistent between boots provided no new hardware is inserted or removed.
@@ -1651,7 +1651,7 @@ HALT SUBCHANNEL,MODIFY SUBCHANNEL,RESUME SUBCHANNEL,START SUBCHANNEL,STORE SUBCH
 TEST SUBCHANNEL ) we use this as the ID of the device we wish to talk to, the most
 important of these instructions are START SUBCHANNEL ( to start IO ), TEST SUBCHANNEL ( to check
 whether the IO completed successfully ), & HALT SUBCHANNEL ( to kill IO ), a subchannel
-can have up to 8 channel paths to a device this offers redunancy if one is not available.
+can have up to 8 channel paths to a device this offers redundancy if one is not available.
 
 
 Device Number:
@@ -1659,7 +1659,7 @@ This number remains static & Is closely tied to the hardware, there are 65536 of
 also they are made up of a CHPID ( Channel Path ID, the most significant 8 bits ) 
 & another lsb 8 bits. These remain static even if more devices are inserted or removed
 from the hardware, there is a 1 to 1 mapping between Subchannels & Device Numbers provided
-devices arent inserted or removed.
+devices aren't inserted or removed.
 
 Channel Control Words:
 CCWS are linked lists of instructions initially pointed to by an operation request block (ORB),
@@ -1674,7 +1674,7 @@ concurrently, you check how the IO went on by issuing a TEST SUBCHANNEL at each
 from which you receive an Interruption response block (IRB). If you get channel & device end 
 status in the IRB without channel checks etc. your IO probably went okay. If you didn't you
 probably need a doctor to examine the IRB & extended status word etc.
-If an error occurs, more sophistocated control units have a facitity known as
+If an error occurs, more sophisticated control units have a facility known as
 concurrent sense this means that if an error occurs Extended sense information will
 be presented in the Extended status word in the IRB if not you have to issue a
 subsequent SENSE CCW command after the test subchannel. 
@@ -1749,7 +1749,7 @@ Interface (OEMI).
 This byte wide Parallel channel path/bus has parity & data on the "Bus" cable 
 & control lines on the "Tag" cable. These can operate in byte multiplex mode for
 sharing between several slow devices or burst mode & monopolize the channel for the
-whole burst. Upto 256 devices can be addressed  on one of these cables. These cables are
+whole burst. Up to 256 devices can be addressed  on one of these cables. These cables are
 about one inch in diameter. The maximum unextended length supported by these cables is
 125 Meters but this can be extended up to 2km with a fibre optic channel extended 
 such as a 3044. The maximum burst speed supported is 4.5 megabytes per second however
@@ -1759,7 +1759,7 @@ One of these paths can be daisy chained to up to 8 control units.
 
 ESCON if fibre optic it is also called FICON 
 Was introduced by IBM in 1990. Has 2 fibre optic cables & uses either leds or lasers
-for communication at a signaling rate of upto 200 megabits/sec. As 10bits are transferred
+for communication at a signaling rate of up to 200 megabits/sec. As 10bits are transferred
 for every 8 bits info this drops to 160 megabits/sec & to 18.6 Megabytes/sec once
 control info & CRC are added. ESCON only operates in burst mode.
  
@@ -1767,7 +1767,7 @@ ESCONs typical max cable length is 3km for the led version & 20km for the laser
 known as XDF ( extended distance facility ). This can be further extended by using an
 ESCON director which triples the above mentioned ranges. Unlike Bus & Tag as ESCON is
 serial it uses a packet switching architecture the standard Bus & Tag control protocol
-is however present within the packets. Upto 256 devices can be attached to each control 
+is however present within the packets. Up to 256 devices can be attached to each control
 unit that uses one of these interfaces.
 
 Common 390 Devices include:
@@ -2050,7 +2050,7 @@ list test.c:1,10
 
 directory:
 Adds directories to be searched for source if gdb cannot find the source.
-(note it is a bit sensititive about slashes) 
+(note it is a bit sensitive about slashes)
 e.g. To add the root of the filesystem to the searchpath do
 directory //
 
@@ -2152,7 +2152,7 @@ program as if it just crashed on your system, it is usually called core & create
 current working directory.
 This is very useful in that a customer can mail a core dump to a technical support department
 & the technical support department can reconstruct what happened.
-Provided the have an identical copy of this program with debugging symbols compiled in & 
+Provided they have an identical copy of this program with debugging symbols compiled in &
 the source base of this build is available.
 In short it is far more useful than something like a crash log could ever hope to be.
 
diff --git a/Documentation/s390/cds.txt b/Documentation/s390/cds.txt
index d80e5733827d..05a2b4f7e38f 100644
--- a/Documentation/s390/cds.txt
+++ b/Documentation/s390/cds.txt
@@ -98,7 +98,7 @@ The following chapters describe the I/O related interface routines the
 Linux/390 common device support (CDS) provides to allow for device specific
 driver implementations on the IBM ESA/390 hardware platform. Those interfaces
 intend to provide the functionality required by every device driver
-implementaion to allow to drive a specific hardware device on the ESA/390
+implementation to allow to drive a specific hardware device on the ESA/390
 platform. Some of the interface routines are specific to Linux/390 and some
 of them can be found on other Linux platforms implementations too.
 Miscellaneous function prototypes, data declarations, and macro definitions
@@ -114,7 +114,7 @@ the ESA/390 architecture has implemented a so called channel subsystem, that
 provides a unified view of the devices physically attached to the systems.
 Though the ESA/390 hardware platform knows about a huge variety of different
 peripheral attachments like disk devices (aka. DASDs), tapes, communication
-controllers, etc. they can all by accessed by a well defined access method and
+controllers, etc. they can all be accessed by a well defined access method and
 they are presenting I/O completion a unified way : I/O interruptions. Every
 single device is uniquely identified to the system by a so called subchannel,
 where the ESA/390 architecture allows for 64k devices be attached.
@@ -174,14 +174,10 @@ read_dev_chars() - Read Device Characteristics
 
 This routine returns the characteristics for the device specified.
 
-The function is meant to be called with an irq handler in place; that is,
+The function is meant to be called with the device already enabled; that is,
 at earliest during set_online() processing.
 
-While the request is processed synchronously, the device interrupt
-handler is called for final ending status. In case of error situations the
-interrupt handler may recover appropriately. The device irq handler can
-recognize the corresponding interrupts by the interruption parameter be
-0x00524443. The ccw_device must not be locked prior to calling read_dev_chars().
+The ccw_device must not be locked prior to calling read_dev_chars().
 
 The function may be called enabled or disabled.
 
@@ -342,7 +338,7 @@ DOIO_REPORT_ALL          - report all interrupt conditions
 The ccw_device_start() function returns :
 
       0 - successful completion or request successfully initiated
--EBUSY  - The device is currently processing a previous I/O request, or ther is
+-EBUSY  - The device is currently processing a previous I/O request, or there is
           a status pending at the device.
 -ENODEV - cdev is invalid, the device is not operational or the ccw_device is
           not online.
@@ -365,7 +361,7 @@ first:
 -EIO:       the common I/O layer terminated the request due to an error state
 
 If the concurrent sense flag in the extended status word in the irb is set, the
-field irb->scsw.count describes the numer of device specific sense bytes
+field irb->scsw.count describes the number of device specific sense bytes
 available in the extended control word irb->scsw.ecw[0]. No device sensing by
 the device driver itself is required.
 
@@ -410,30 +406,11 @@ individual flag meanings.
 
 Usage Notes :
 
-Prior to call ccw_device_start() the device driver must assure disabled state,
-i.e. the I/O mask value in the PSW must be disabled. This can be accomplished
-by calling local_save_flags( flags). The current PSW flags are preserved and
-can be restored by local_irq_restore( flags) at a later time.
-
-If the device driver violates this rule while running in a uni-processor
-environment an interrupt might be presented prior to the ccw_device_start()
-routine returning to the device driver main path. In this case we will end in a
-deadlock situation as the interrupt handler will try to obtain the irq
-lock the device driver still owns (see below) !
-
-The driver must assure to hold the device specific lock. This can be
-accomplished by
-
-(i)  spin_lock(get_ccwdev_lock(cdev)), or
-(ii) spin_lock_irqsave(get_ccwdev_lock(cdev), flags)
-
-Option (i) should be used if the calling routine is running disabled for
-I/O interrupts (see above) already. Option (ii) obtains the device gate und
-puts the CPU into I/O disabled state by preserving the current PSW flags.
+ccw_device_start() must be called disabled and with the ccw device lock held.
 
 The device driver is allowed to issue the next ccw_device_start() call from
 within its interrupt handler already. It is not required to schedule a
-bottom-half, unless an non deterministically long running error recovery procedure
+bottom-half, unless a non deterministically long running error recovery procedure
 or similar needs to be scheduled. During I/O processing the Linux/390 generic
 I/O device driver support has already obtained the IRQ lock, i.e. the handler
 must not try to obtain it again when calling ccw_device_start() or we end in a
@@ -454,7 +431,7 @@ information prior to device-end the device driver urgently relies on. In this
 case all I/O interruptions are presented to the device driver until final
 status is recognized.
 
-If a device is able to recover from asynchronosly presented I/O errors, it can
+If a device is able to recover from asynchronously presented I/O errors, it can
 perform overlapping I/O using the DOIO_EARLY_NOTIFICATION flag. While some
 devices always report channel-end and device-end together, with a single
 interrupt, others present primary status (channel-end) when the channel is
@@ -488,7 +465,7 @@ int ccw_device_resume(struct ccw_device *cdev);
 
 cdev - ccw_device the resume operation is requested for
 
-The resume_IO() function returns:
+The ccw_device_resume() function returns:
 
         0  - suspended channel program is resumed
 -EBUSY     - status pending
@@ -507,6 +484,8 @@ a long-running channel program or the device might require to initially issue
 a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
 command is provided.
 
+ccw_device_halt() must be called disabled and with the ccw device lock held.
+
 int ccw_device_halt(struct ccw_device *cdev,
                     unsigned long intparm);
 
@@ -517,7 +496,7 @@ intparm : interruption parameter; value is only used if no I/O
 
 The ccw_device_halt() function returns :
 
-      0 - successful completion or request successfully initiated
+      0 - request successfully initiated
 -EBUSY  - the device is currently busy, or status pending.
 -ENODEV - cdev invalid.
 -EINVAL - The device is not operational or the ccw device is not online.
@@ -533,6 +512,23 @@ can then perform an appropriate action. Prior to interrupt of an outstanding
 read to a network device (with or without PCI flag) a ccw_device_halt()
 is required to end the pending operation.
 
+ccw_device_clear() - Terminage I/O Request Processing
+
+In order to terminate all I/O processing at the subchannel, the clear subchannel
+(CSCH) command is used. It can be issued via ccw_device_clear().
+
+ccw_device_clear() must be called disabled and with the ccw device lock held.
+
+int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm);
+
+cdev:    ccw_device the clear operation is requested for
+intparm: interruption parameter (see ccw_device_halt())
+
+The ccw_device_clear() function returns:
+
+      0 - request successfully initiated
+-ENODEV - cdev invalid
+-EINVAL - The device is not operational or the ccw device is not online.
 
 Miscellaneous Support Routines
 
diff --git a/Documentation/s390/crypto/crypto-API.txt b/Documentation/s390/crypto/crypto-API.txt
index 29dee792c887..71ae6ca9f2c2 100644
--- a/Documentation/s390/crypto/crypto-API.txt
+++ b/Documentation/s390/crypto/crypto-API.txt
@@ -17,8 +17,8 @@ arch/s390/crypto directory.
 2. Probing for availability of MSA
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 It should be possible to use Kernels with the z990 crypto implementations both
-on machines with MSA available an on those without MSA (pre z990 or z990
-without MSA). Therefore a simple probing mechanisms has been implemented:
+on machines with MSA available and on those without MSA (pre z990 or z990
+without MSA). Therefore a simple probing mechanism has been implemented:
 In the init function of each crypto module the availability of MSA and of the
 respective crypto algorithm in particular will be tested. If the algorithm is
 available the module will load and register its algorithm with the crypto API.
@@ -26,7 +26,7 @@ available the module will load and register its algorithm with the crypto API.
 If the respective crypto algorithm is not available, the init function will
 return -ENOSYS. In that case a fallback to the standard software implementation
 of the crypto algorithm must be taken ( -> the standard crypto modules are
-also build when compiling the kernel).
+also built when compiling the kernel).
 
 
 3. Ensuring z990 crypto module preference
@@ -75,8 +75,8 @@ name of the respective module is given in square brackets.
 
 - SHA1 Digest Algorithm [sha1 -> sha1_z990]
 - DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
-- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
-- Tripple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
+- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
+- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
 
 In order to load, for example, the sha1_z990 module when the sha1 algorithm is
 requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
diff --git a/Documentation/s390/driver-model.txt b/Documentation/s390/driver-model.txt
index 62c082387aea..e938c442277d 100644
--- a/Documentation/s390/driver-model.txt
+++ b/Documentation/s390/driver-model.txt
@@ -18,11 +18,18 @@ devices/
            - 0.0.0002/
            - 0.1.0000/0.1.1234/
            ...
+           - defunct/
 
 In this example, device 0815 is accessed via subchannel 0 in subchannel set 0,
 device 4711 via subchannel 1 in subchannel set 0, and subchannel 2 is a non-I/O
 subchannel. Device 1234 is accessed via subchannel 0 in subchannel set 1.
 
+The subchannel named 'defunct' does not represent any real subchannel on the
+system; it is a pseudo subchannel where disconnnected ccw devices are moved to
+if they are displaced by another ccw device becoming operational on their
+former subchannel. The ccw devices will be moved again to a proper subchannel
+if they become operational again on that subchannel.
+
 You should address a ccw device via its bus id (e.g. 0.0.4711); the device can
 be found under bus/ccw/devices/.
 
@@ -239,6 +246,9 @@ status - Can be 'online' or 'offline'.
 
 type - The physical type of the channel path.
 
+shared - Whether the channel path is shared.
+
+cmg - The channel measurement group.
 
 3. System devices
 -----------------
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index 000230cd26db..0eb7c58916de 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -36,7 +36,7 @@ switches to the next debug area. This is done in order to be sure
 that the records which describe the origin of the exception are not
 overwritten when a wrap around for the current area occurs.
 
-The debug areas itselve are also ordered in form of a ring buffer. 
+The debug areas themselves are also ordered in form of a ring buffer.
 When an exception is thrown in the last debug area, the following debug 
 entries are then written again in the very first area.
 
@@ -55,7 +55,7 @@ The debug logs can be inspected in a live system through entries in
 the debugfs-filesystem. Under the toplevel directory "s390dbf" there is
 a directory for each registered component, which is named like the
 corresponding component. The debugfs normally should be mounted to
-/sys/kernel/debug therefore the debug feature can be accessed unter
+/sys/kernel/debug therefore the debug feature can be accessed under
 /sys/kernel/debug/s390dbf.
 
 The content of the directories are files which represent different views
@@ -87,11 +87,11 @@ There are currently 2 possible triggers, which stop the debug feature
 globally. The first possibility is to use the "debug_active" sysctl. If
 set to 1 the debug feature is running. If "debug_active" is set to 0 the
 debug feature is turned off.
-The second trigger which stops the debug feature is an kernel oops.
+The second trigger which stops the debug feature is a kernel oops.
 That prevents the debug feature from overwriting debug information that
 happened before the oops. After an oops you can reactivate the debug feature
 by piping 1 to /proc/sys/s390dbf/debug_active. Nevertheless, its not
-suggested to use an oopsed kernel in an production environment.
+suggested to use an oopsed kernel in a production environment.
 If you want to disallow the deactivation of the debug feature, you can use
 the "debug_stoppable" sysctl. If you set "debug_stoppable" to 0 the debug
 feature cannot be stopped. If the debug feature is already stopped, it
diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt
index 904d49e90ef2..6aa9a891f3d0 100644
--- a/Documentation/scsi/aic79xx.txt
+++ b/Documentation/scsi/aic79xx.txt
@@ -127,7 +127,7 @@ The following information is available in this file:
         - Correct a reference to free'ed memory during controller
           shutdown.
         - Reset the bus on an SE->LVD change.  This is required
-          to reset our transcievers.
+          to reset our transceivers.
 
    1.3.5 (March 24th, 2003)
         - Fix a few register window mode bugs.
@@ -169,7 +169,7 @@ The following information is available in this file:
    1.3.0 (January 21st, 2003)
         - Full regression testing for all U320 products completed.
         - Added abort and target/lun reset error recovery handler and
-          interrupt coalessing.
+          interrupt coalescing.
 
    1.2.0 (November 14th, 2002)
         - Added support for Domain Validation
diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt
index c92f4473193b..05667e7308d4 100644
--- a/Documentation/scsi/aic7xxx_old.txt
+++ b/Documentation/scsi/aic7xxx_old.txt
@@ -256,7 +256,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
               En/Disable High Byte LVD Termination
 
         The upper 2 bits that deal with LVD termination only apply to Ultra2
-        controllers.  Futhermore, due to the current Ultra2 controller
+        controllers.  Furthermore, due to the current Ultra2 controller
         designs, these bits are tied together such that setting either bit
         enables both low and high byte LVD termination.  It is not possible
         to only set high or low byte LVD termination in this manner.  This is
@@ -436,7 +436,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
     the commas to periods, insmod won't interpret this as more than one
     string and write junk into our binary image.  I consider it a bug in
     the insmod program that even if you wrap your string in quotes (quotes
-    that pass the shell mind you and that insmod sees) it still treates
+    that pass the shell mind you and that insmod sees) it still treats
     a comma inside of those quotes as starting a new variable, resulting
     in memory scribbles if you don't switch the commas to periods.
 
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
index 35f6b8ed2295..9707941704e3 100644
--- a/Documentation/scsi/ibmmca.txt
+++ b/Documentation/scsi/ibmmca.txt
@@ -461,7 +461,7 @@
       This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which 
       allows data to be written from the system to the device. It is a
       necessary step to be allowed to set blocksize of SCSI-tape-drives and 
-      the tape-speed, whithout confusing the SCSI-Subsystem.
+      the tape-speed, without confusing the SCSI-Subsystem.
    2) The recognition of a tape is included in the check_devices routine.
       This is done by checking for TYPE_TAPE, that is already defined in
       the kernel-scsi-environment. The markup of a tape is done in the 
@@ -710,8 +710,8 @@
       of troubles with some controllers and after I wanted to apply some
       extensions, it jumped out in the same situation, on my w/cache, as like 
       on D. Weinehalls' Model 56, having integrated SCSI. This gave me the 
-      descissive hint to move the code-part out and declare it global. Now,
-      it seems to work by far much better an more stable. Let us see, what
+      decisive hint to move the code-part out and declare it global. Now
+      it seems to work far better and more stable. Let us see what
       the world thinks of it...
    3) By the way, only Sony DAT-drives seem to show density code 0x13. A
       test with a HP drive gave right results, so the problem is vendor-
@@ -822,10 +822,10 @@
    A long period of collecting bugreports from all corners of the world
    now lead to the following corrections to the code:
    1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this 
-      was, that it is possible to disbale Fast-SCSI for the external bus.
-      The feature-control command, where this crash appeared regularly tried
+      was that it is possible to disable Fast-SCSI for the external bus.
+      The feature-control command, where this crash appeared regularly, tried
       to set the maximum speed of 10MHz synchronous transfer speed and that
-      reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now,
+      reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
       the feature-command probes down from maximum speed until the adapter 
       stops to complain, which is at the same time the maximum possible
       speed selected in the reference program. So, F/W external can run at
@@ -920,7 +920,7 @@
       completed in such a way, that they are now completely conform to the
       demands in the technical description of IBM. Main candidates were the
       DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
-      be tranferred by bypassing the internal command buffer of the adapter
+      be transferred by bypassing the internal command buffer of the adapter
       or else the response can be a random result. GET_POS_INFO would be more
       safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
       is not allowed by the technical references of IBM. (Sorry, folks, the
diff --git a/Documentation/scsi/in2000.txt b/Documentation/scsi/in2000.txt
index 80f104042645..c3e2a90475d2 100644
--- a/Documentation/scsi/in2000.txt
+++ b/Documentation/scsi/in2000.txt
@@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98
 UPDATE NEWS: version 1.31 - 6 Jul 97
 
    Fixed a bug that caused incorrect SCSI status bytes to be
-   returned from commands sent to LUN's greater than 0. This
+   returned from commands sent to LUNs greater than 0. This
    means that CDROM changers work now! Fixed a bug in the
    handling of command-line arguments when loaded as a module.
    Also put all the header data in in2000.h where it belongs.
diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt
index 9e2078b2a615..aa54f54c4a50 100644
--- a/Documentation/scsi/libsas.txt
+++ b/Documentation/scsi/libsas.txt
@@ -393,7 +393,7 @@ struct sas_task {
         task_proto -- _one_ of enum sas_proto
         scatter -- pointer to scatter gather list array
         num_scatter -- number of elements in scatter
-        total_xfer_len -- total number of bytes expected to be transfered
+        total_xfer_len -- total number of bytes expected to be transferred
         data_dir -- PCI_DMA_...
         task_done -- callback when the task has finished execution
 };
diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt
index 58ad8db333d9..caf10b155185 100644
--- a/Documentation/scsi/ncr53c8xx.txt
+++ b/Documentation/scsi/ncr53c8xx.txt
@@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server:
 
           ftp://ftp.symbios.com/
 
-Usefull SCSI tools written by Eric Youngdale are available at tsx-11:
+Useful SCSI tools written by Eric Youngdale are available at tsx-11:
 
           ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
           ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt
index d74bbd29eb3a..032399b16a53 100644
--- a/Documentation/scsi/scsi-changer.txt
+++ b/Documentation/scsi/scsi-changer.txt
@@ -88,7 +88,7 @@ If the module finds the changer, it prints some messages about the
 device [ try "dmesg" if you don't see anything ] and should show up in
 /proc/devices. If not....  some changers use ID ? / LUN 0 for the
 device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
-look for LUN's other than 0 as default, becauce there are to many
+look for LUNs other than 0 as default, because there are too many
 broken devices. So you can try:
 
   1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
@@ -107,7 +107,7 @@ because the kernel will translate the error codes into human-readable
 strings then.
 
 You can display these messages with the dmesg command (or check the
-logfiles).  If you email me some question becauce of a problem with the
+logfiles).  If you email me some question because of a problem with the
 driver, please include these messages.
 
 
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt
index b964eef2f62f..7acbebb17fa6 100644
--- a/Documentation/scsi/scsi_eh.txt
+++ b/Documentation/scsi/scsi_eh.txt
@@ -75,7 +75,7 @@ with the command.
 
  - otherwise
         scsi_eh_scmd_add(scmd, 0) is invoked for the command.  See
-        [1-3] for details of this funciton.
+        [1-3] for details of this function.
 
 
 [1-2-2] Completing a scmd w/ timeout
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt
index 75a535a975c3..6f70f2b9327e 100644
--- a/Documentation/scsi/scsi_mid_low_api.txt
+++ b/Documentation/scsi/scsi_mid_low_api.txt
@@ -375,7 +375,6 @@ Summary:
    scsi_add_device - creates new scsi device (lu) instance
    scsi_add_host - perform sysfs registration and set up transport class
    scsi_adjust_queue_depth - change the queue depth on a SCSI device
-   scsi_assign_lock - replace default host_lock with given lock
    scsi_bios_ptable - return copy of block device's partition table
    scsi_block_requests - prevent further commands being queued to given host
    scsi_deactivate_tcq - turn off tag command queueing
@@ -489,20 +488,6 @@ void scsi_adjust_queue_depth(struct scsi_device * sdev, int tagged,
 
 
 /**
- * scsi_assign_lock - replace default host_lock with given lock
- * @shost: a pointer to a scsi host instance
- * @lock: pointer to lock to replace host_lock for this host
- *
- *      Returns nothing
- *
- *      Might block: no
- *
- *      Defined in: include/scsi/scsi_host.h .
- **/
-void scsi_assign_lock(struct Scsi_Host *shost, spinlock_t *lock)
-
-
-/**
  * scsi_bios_ptable - return copy of block device's partition table
  * @dev:        pointer to block device
  *
@@ -1366,17 +1351,11 @@ Locks
 Each struct Scsi_Host instance has a spin_lock called struct 
 Scsi_Host::default_lock which is initialized in scsi_host_alloc() [found in 
 hosts.c]. Within the same function the struct Scsi_Host::host_lock pointer
-is initialized to point at default_lock with the scsi_assign_lock() function.
-Thereafter lock and unlock operations performed by the mid level use the
-struct Scsi_Host::host_lock pointer.
-
-LLDs can override the use of struct Scsi_Host::default_lock by
-using scsi_assign_lock(). The earliest opportunity to do this would
-be in the detect() function after it has invoked scsi_register(). It
-could be replaced by a coarser grain lock (e.g. per driver) or a
-lock of equal granularity (i.e. per host). Using finer grain locks 
-(e.g. per SCSI device) may be possible by juggling locks in
-queuecommand().
+is initialized to point at default_lock.  Thereafter lock and unlock
+operations performed by the mid level use the struct Scsi_Host::host_lock
+pointer.  Previously drivers could override the host_lock pointer but
+this is not allowed anymore.
+
 
 Autosense
 =========
diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt
index 5ff65b184265..3c12422f7f41 100644
--- a/Documentation/scsi/st.txt
+++ b/Documentation/scsi/st.txt
@@ -261,7 +261,7 @@ pairs are separated with a comma (no spaces allowed). A colon can be
 used instead of the equal mark. The definition is prepended by the
 string st=. Here is an example:
 
-        st=buffer_kbs:64,write_threhold_kbs:60
+        st=buffer_kbs:64,write_threshold_kbs:60
 
 The following syntax used by the old kernel versions is also supported:
 
diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt
index 26c8a08ca3ea..2c1745a9df00 100644
--- a/Documentation/scsi/sym53c8xx_2.txt
+++ b/Documentation/scsi/sym53c8xx_2.txt
@@ -609,7 +609,7 @@ appropriate mailing lists or news-groups.  Send me a copy in order to
 be sure I will receive it.  Obviously, a bug in the driver code is
 possible.
 
-  My cyrrent email address: Gerard Roudier <groudier@free.fr>
+  My current email address: Gerard Roudier <groudier@free.fr>
 
 Allowing disconnections is important if you use several devices on
 your SCSI bus but often causes problems with buggy devices.
diff --git a/Documentation/sharedsubtree.txt b/Documentation/sharedsubtree.txt
index 2d8f403eb6eb..ccf1cebe744f 100644
--- a/Documentation/sharedsubtree.txt
+++ b/Documentation/sharedsubtree.txt
@@ -942,13 +942,13 @@ replicas continue to be exactly same.
         ->mnt_slave
         ->mnt_master
 
-        ->mnt_share links togather all the mount to/from which this vfsmount
+        ->mnt_share links together all the mount to/from which this vfsmount
                 send/receives propagation events.
 
         ->mnt_slave_list links all the mounts to which this vfsmount propagates
                 to.
 
-        ->mnt_slave links togather all the slaves that its master vfsmount
+        ->mnt_slave links together all the slaves that its master vfsmount
                 propagates to.
 
         ->mnt_master points to the master vfsmount from which this vfsmount
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 138673a907f5..9fef210ab50a 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -753,7 +753,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
     position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
     single_cmd  - Use single immediate commands to communicate with
                 codecs (for debugging only)
-    disable_msi - Disable Message Signaled Interrupt (MSI)
+    enable_msi  - Enable Message Signaled Interrupt (MSI) (default = off)
 
     This module supports one card and autoprobe.
 
@@ -955,7 +955,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
                   dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
                   phase88, mediastation
     omni        - Omni I/O support for MidiMan M-Audio Delta44/66
-    cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
+    cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transceiver)
                      in msec resolution, default value is 500 (0.5 sec)
 
     This module supports multiple cards and autoprobe. Note: The consumer part
diff --git a/Documentation/sound/alsa/Audigy-mixer.txt b/Documentation/sound/alsa/Audigy-mixer.txt
index 5132fd95e074..7f10dc6ff28c 100644
--- a/Documentation/sound/alsa/Audigy-mixer.txt
+++ b/Documentation/sound/alsa/Audigy-mixer.txt
@@ -6,7 +6,7 @@ This is based on SB-Live-mixer.txt.
 
 The EMU10K2 chips have a DSP part which can be programmed to support 
 various ways of sample processing, which is described here.
-(This acticle does not deal with the overall functionality of the 
+(This article does not deal with the overall functionality of the 
 EMU10K2 chips. See the manuals section for further details.)
 
 The ALSA driver programs this portion of chip by default code
diff --git a/Documentation/sound/alsa/SB-Live-mixer.txt b/Documentation/sound/alsa/SB-Live-mixer.txt
index 651adaf60473..f5639d40521d 100644
--- a/Documentation/sound/alsa/SB-Live-mixer.txt
+++ b/Documentation/sound/alsa/SB-Live-mixer.txt
@@ -5,7 +5,7 @@
 
 The EMU10K1 chips have a DSP part which can be programmed to support
 various ways of sample processing, which is described here.
-(This acticle does not deal with the overall functionality of the 
+(This article does not deal with the overall functionality of the 
 EMU10K1 chips. See the manuals section for further details.)
 
 The ALSA driver programs this portion of chip by default code
diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx
index a1e0ee20f595..f9717fe9bd85 100644
--- a/Documentation/spi/pxa2xx
+++ b/Documentation/spi/pxa2xx
@@ -102,7 +102,7 @@ struct pxa2xx_spi_chip {
         u8 tx_threshold;
         u8 rx_threshold;
         u8 dma_burst_size;
-        u32 timeout_microsecs;
+        u32 timeout;
         u8 enable_loopback;
         void (*cs_control)(u32 command);
 };
@@ -121,7 +121,7 @@ the PXA2xx "Developer Manual" sections on the DMA controller and SSP Controllers
 to determine the correct value. An SSP configured for byte-wide transfers would
 use a value of 8.
 
-The "pxa2xx_spi_chip.timeout_microsecs" fields is used to efficiently handle
+The "pxa2xx_spi_chip.timeout" fields is used to efficiently handle
 trailing bytes in the SSP receiver fifo.  The correct value for this field is
 dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific
 slave device.  Please note that the PXA2xx SSP 1 does not support trailing byte
@@ -162,18 +162,18 @@ static void cs8405a_cs_control(u32 command)
 }
 
 static struct pxa2xx_spi_chip cs8415a_chip_info = {
-        .tx_threshold = 12, /* SSP hardward FIFO threshold */
-        .rx_threshold = 4, /* SSP hardward FIFO threshold */
+        .tx_threshold = 8, /* SSP hardward FIFO threshold */
+        .rx_threshold = 8, /* SSP hardward FIFO threshold */
         .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
-        .timeout_microsecs = 64, /* Wait at least 64usec to handle trailing */
+        .timeout = 235, /* See Intel documentation */
         .cs_control = cs8415a_cs_control, /* Use external chip select */
 };
 
 static struct pxa2xx_spi_chip cs8405a_chip_info = {
-        .tx_threshold = 12, /* SSP hardward FIFO threshold */
-        .rx_threshold = 4, /* SSP hardward FIFO threshold */
+        .tx_threshold = 8, /* SSP hardward FIFO threshold */
+        .rx_threshold = 8, /* SSP hardward FIFO threshold */
         .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */
-        .timeout_microsecs = 64, /* Wait at least 64usec to handle trailing */
+        .timeout = 235, /* See Intel documentation */
         .cs_control = cs8405a_cs_control, /* Use external chip select */
 };
 
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
index f39c9d714db3..a2afca3b2bab 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -62,9 +62,6 @@ consider the following facts about the Linux kernel:
       - different structures can contain different fields
       - Some functions may not be implemented at all, (i.e. some locks
         compile away to nothing for non-SMP builds.)
-      - Parameter passing of variables from function to function can be
-        done in different ways (the CONFIG_REGPARM option controls
-        this.)
       - Memory within the kernel can be aligned in different ways,
         depending on the build options.
   - Linux runs on a wide range of different processor architectures.
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index 02a481225b0d..c815c5206e84 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -50,7 +50,7 @@ Review cycle:
    Contact the kernel security team for more details on this procedure.
 
 
-Review committe:
+Review committee:
 
  - This is made up of a number of kernel developers who have volunteered for
    this task, and a few that haven't.
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 5c3a51905969..aa986a35e994 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are
         readable by root only. This allows the end user to remove
         such a dump but not access it directly. For security reasons
         core dumps in this mode will not overwrite one another or
-        other files. This mode is appropriate when adminstrators are
+        other files. This mode is appropriate when administrators are
         attempting to debug problems in a normal environment.
 
 ==============================================================
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 0bc7f1e3c9e6..5922e84d9133 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -27,6 +27,7 @@ show up in /proc/sys/kernel:
 - hotplug
 - java-appletviewer           [ binfmt_java, obsolete ]
 - java-interpreter            [ binfmt_java, obsolete ]
+- kstack_depth_to_print       [ X86 only ]
 - l2cr                        [ PPC only ]
 - modprobe                    ==> Documentation/kmod.txt
 - msgmax
@@ -170,6 +171,13 @@ This flag controls the L2 cache of G3 processor boards. If
 
 ==============================================================
 
+kstack_depth_to_print: (X86 only)
+
+Controls the number of words to print when dumping the raw
+kernel stack.
+
+==============================================================
+
 osrelease, ostype & version:
 
 # cat osrelease
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 20d0d797f539..e96a341eb7e4 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -129,7 +129,7 @@ the high water marks for each per cpu page list.
 
 zone_reclaim_mode:
 
-Zone_reclaim_mode allows to set more or less agressive approaches to
+Zone_reclaim_mode allows someone to set more or less aggressive approaches to
 reclaim memory when a zone runs out of memory. If it is set to zero then no
 zone reclaim occurs. Allocations will be satisfied from other zones / nodes
 in the system.
diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/uml/UserModeLinux-HOWTO.txt
index b60590eca18f..628013f944c4 100644
--- a/Documentation/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/uml/UserModeLinux-HOWTO.txt
@@ -1477,7 +1477,7 @@
 
 
 
-  Making it world-writeable looks bad, but it seems not to be
+  Making it world-writable looks bad, but it seems not to be
   exploitable as a security hole.  However, it does allow anyone to cre-
   ate useless tap devices (useless because they can't configure them),
   which is a DOS attack.  A somewhat more secure alternative would to be
diff --git a/Documentation/usb/hiddev.txt b/Documentation/usb/hiddev.txt
index 6a790754e963..6e8c9f1d2f22 100644
--- a/Documentation/usb/hiddev.txt
+++ b/Documentation/usb/hiddev.txt
@@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big
 examples for this are power devices (especially uninterruptable power
 supplies) and monitor control on higher end monitors.
 
-To support these disparite requirements, the Linux USB system provides
+To support these disparate requirements, the Linux USB system provides
 HID events to two separate interfaces:
 * the input subsystem, which converts HID events into normal input
 device interfaces (such as keyboard, mouse and joystick) and a
diff --git a/Documentation/usb/rio.txt b/Documentation/usb/rio.txt
index ab21db454694..aee715af7db7 100644
--- a/Documentation/usb/rio.txt
+++ b/Documentation/usb/rio.txt
@@ -24,10 +24,10 @@ are in no way responsible for any damage that may occur, no matter how
 inconsequential.
 
 It seems that the Rio has a problem when sending .mp3 with low batteries.
-I suggest when the batteries are low and want to transfer stuff that you
+I suggest when the batteries are low and you want to transfer stuff that you
 replace it with a fresh one. In my case, what happened is I lost two 16kb
 blocks (they are no longer usable to store information to it). But I don't
-know if thats normal or not. It could simply be a problem with the flash 
+know if that's normal or not; it could simply be a problem with the flash 
 memory.
 
 In an extreme case, I left my Rio playing overnight and the batteries wore 
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 8dc2bacc8f1f..d61f6e7865de 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -175,7 +175,7 @@ Keyspan USA-series Serial Adapters
   
   Current status:
     The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and
-    have been pretty throughly tested at various baud rates with 8-N-1
+    have been pretty thoroughly tested at various baud rates with 8-N-1
     character settings.  Other character lengths and parity setups are
     presently untested.
 
@@ -253,7 +253,7 @@ Cypress M8 CY4601 Family Serial Driver
         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
+        it for transferring 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
@@ -297,7 +297,7 @@ Belkin USB Serial Adapter F5U103
       Parity       N,E,O,M,S
       Handshake    None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
       Break        Set and clear
-      Line contrl  Input/Output query and control **
+      Line control Input/Output query and control **
 
       *  Hardware input flow control is only enabled for firmware
          levels above 2.06.  Read source code comments describing Belkin
@@ -309,7 +309,7 @@ Belkin USB Serial Adapter F5U103
          automatic hardware flow control.
 
   TO DO List:
-    -- Add true modem contol line query capability.  Currently tracks the
+    -- Add true modem control line query capability.  Currently tracks the
        states reported by the interrupt and the states requested.
     -- Add error reporting back to application for UART error conditions.
     -- Add support for flush ioctls.
@@ -428,12 +428,6 @@ Options supported:
   See http://www.uuhaus.de/linux/palmconnect.html for up-to-date
   information on this driver.
 
-AIRcable USB Dongle Bluetooth driver
-  If there is the cdc_acm driver loaded in the system, you will find that the
-  cdc_acm claims the device before AIRcable can. This is simply corrected
-  by unloading both modules and then loading the aircable module before
-  cdc_acm module
-
 Generic Serial driver
 
   If your device is not one of the above listed devices, compatible with
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index 8755b3e7b09e..62e32b49cec9 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -43,7 +43,7 @@
  42 -> digitalnow DNTV Live! DVB-T Pro                     [1822:0025,1822:0019]
  43 -> KWorld/VStream XPert DVB-T with cx22702             [17de:08a1,12ab:2300]
  44 -> DViCO FusionHDTV DVB-T Dual Digital                 [18ac:db50,18ac:db54]
- 45 -> KWorld HardwareMpegTV XPert                         [17de:0840]
+ 45 -> KWorld HardwareMpegTV XPert                         [17de:0840,1421:0305]
  46 -> DViCO FusionHDTV DVB-T Hybrid                       [18ac:db40,18ac:db44]
  47 -> pcHDTV HD5500 HDTV                                  [7063:5500]
  48 -> Kworld MCE 200 Deluxe                               [17de:0841]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 53ce6a39083c..f6201cc37ec5 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -76,7 +76,7 @@
  75 -> AVerMedia AVerTVHD MCE A180              [1461:1044]
  76 -> SKNet MonsterTV Mobile                   [1131:4ee9]
  77 -> Pinnacle PCTV 40i/50i/110i (saa7133)     [11bd:002e]
- 78 -> ASUSTeK P7131 Dual                       [1043:4862]
+ 78 -> ASUSTeK P7131 Dual                       [1043:4862,1043:4876]
  79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)
  80 -> ASUS Digimatrix TV                       [1043:0210]
  81 -> Philips Tiger reference design           [1131:2018]
@@ -99,3 +99,8 @@
  98 -> Proteus Pro 2309                         [0919:2003]
  99 -> AVerMedia TV Hybrid A16AR                [1461:2c00]
 100 -> Asus Europa2 OEM                         [1043:4860]
+101 -> Pinnacle PCTV 310i                       [11bd:002f]
+102 -> Avermedia AVerTV Studio 507              [1461:9715]
+103 -> Compro Videomate DVB-T200A
+104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid     [0070:6701]
+105 -> Terratec Cinergy HT PCMCIA               [153b:1172]
diff --git a/Documentation/video4linux/cafe_ccic b/Documentation/video4linux/cafe_ccic
new file mode 100644
index 000000000000..88821022a5de
--- /dev/null
+++ b/Documentation/video4linux/cafe_ccic
@@ -0,0 +1,54 @@
+"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera
+controller.  This is the controller found in first-generation OLPC systems,
+and this driver was written with support from the OLPC project.
+
+Current status: the core driver works.  It can generate data in YUV422,
+RGB565, and RGB444 formats.  (Anybody looking at the code will see RGB32 as
+well, but that is a debugging aid which will be removed shortly).  VGA and
+QVGA modes work; CIF is there but the colors remain funky.  Only the OV7670
+sensor is known to work with this controller at this time.
+
+To try it out: either of these commands will work:
+
+     mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound
+     mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound
+
+The "xawtv" utility also works; gqcam does not, for unknown reasons.
+
+There are a few load-time options, most of which can be changed after
+loading via sysfs as well:
+
+ - alloc_bufs_at_load:  Normally, the driver will not allocate any DMA
+   buffers until the time comes to transfer data.  If this option is set,
+   then worst-case-sized buffers will be allocated at module load time.
+   This option nails down the memory for the life of the module, but
+   perhaps decreases the chances of an allocation failure later on.
+
+ - dma_buf_size: The size of DMA buffers to allocate.  Note that this
+   option is only consulted for load-time allocation; when buffers are
+   allocated at run time, they will be sized appropriately for the current
+   camera settings.
+
+ - n_dma_bufs: The controller can cycle through either two or three DMA
+   buffers.  Normally, the driver tries to use three buffers; on faster
+   systems, however, it will work well with only two.
+
+ - min_buffers: The minimum number of streaming I/O buffers that the driver
+   will consent to work with.  Default is one, but, on slower systems,
+   better behavior with mplayer can be achieved by setting to a higher
+   value (like six).
+
+ - max_buffers: The maximum number of streaming I/O buffers; default is
+   ten.  That number was carefully picked out of a hat and should not be
+   assumed to actually mean much of anything.
+
+ - flip: If this boolean parameter is set, the sensor will be instructed to
+   invert the video image.  Whether it makes sense is determined by how
+   your particular camera is mounted.
+
+Work is ongoing with this driver, stay tuned.
+
+jon
+
+Jonathan Corbet
+corbet@lwn.net
diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt
deleted file mode 100644
index 1a1c2d03a5c8..000000000000
--- a/Documentation/video4linux/zr36120.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-Driver for Trust Computer Products Framegrabber, version 0.6.1
------- --- ----- -------- -------- ------------  ------- - - -
-
-- ZORAN ------------------------------------------------------
- Author: Pauline Middelink <middelin@polyware.nl>
-   Date: 18 September 1999
-Version: 0.6.1
-
-- Description ------------------------------------------------
-
-Video4Linux compatible driver for an unknown brand framegrabber
-(Sold in the Netherlands by TRUST Computer Products) and various
-other zoran zr36120 based framegrabbers.
-
-The card contains a ZR36120 Multimedia PCI Interface and a Philips
-SAA7110 Onechip Frontend videodecoder. There is also an DSP of
-which I have forgotten the number, since i will never get that thing
-to work without specs from the vendor itself.
-
-The SAA711x are capable of processing 6 different video inputs,
-CVBS1..6 and Y1+C1, Y2+C2, Y3+C3. All in 50/60Hz, NTSC, PAL or
-SECAM and delivering a YUV datastream.  On my card the input
-'CVBS-0' corresponds to channel CVBS2 and 'S-Video' to Y2+C2.
-
-I have some reports of other cards working with the mentioned
-chip sets. For a list of other working cards please have a look
-at the cards named in the tvcards struct in the beginning of
-zr36120.c
-
-After some testing, I discovered that the carddesigner messed up
-on the I2C interface. The Zoran chip includes 2 lines SDA and SCL
-which (s)he connected reversely. So we have to clock on the SDA
-and r/w data on the SCL pin. Life is fun... Each cardtype now has
-a bit which signifies if you have a card with the same deficiency.
-
-Oh, for the completeness of this story I must mention that my
-card delivers the VSYNC pulse of the SAA chip to GIRQ1, not
-GIRQ0 as some other cards have. This is also incorporated in
-the driver be clearing/setting the 'useirq1' bit in the tvcard
-description.
-
-Another problems of continuous capturing data with a Zoran chip
-is something nasty inside the chip. It effectively halves the
-fps we ought to get... Here is the scenario: capturing frames
-to memory is done in the so-called snapshot mode. In this mode
-the Zoran stops after capturing a frame worth of data and wait
-till the application set GRAB bit to indicate readiness for the
-next frame. After detecting a set bit, the chip neatly waits
-till the start of a frame, captures it and it goes back to off.
-Smart ppl will notice the problem here. Its the waiting on the
-_next_ frame each time we set the GRAB bit... Oh well, 12,5 fps
-is still plenty fast for me.
--- update 28/7/1999 --
-Don't believe a word I just said... Proof is the output
-of `streamer -t 300 -r 25 -f avi15 -o /dev/null`
-        ++--+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+- 25/25
-        +-s+-+-+-+-+-+-+-+-+-+-+-+-+-s+-+-+-+-+-+-+-+-+-+-+-
-        syncer: done
-        writer: done
-(note the /dev/null is prudent here, my system is not able to
- grab /and/ write 25 fps to a file... gifts welcome :) )
-The technical reasoning follows: The zoran completed the last
-frame, the VSYNC goes low, and GRAB is cleared. The interrupt
-routine starts to work since its VSYNC driven, and again
-activates the GRAB bit. A few ms later the VSYNC (re-)rises and
-the zoran starts to work on a new and freshly broadcasted frame....
-
-For pointers I used the specs of both chips. Below are the URLs:
-  http://www.zoran.com/ftp/download/devices/pci/ZR36120/36120data.pdf
-  http://www-us.semiconductor.philips.com/acrobat/datasheets/SAA_7110_A_1.pdf
-Some alternatives for the Philips SAA 7110 datasheet are:
-  http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/7/SAA7110.shtml
-  http://www.datasheetarchive.com/search.php?search=SAA7110&sType=part
-
-The documentation has very little on absolute numbers or timings
-needed for the various modes/resolutions, but there are other
-programs you can borrow those from.
-
------- Install --------------------------------------------
-Read the file called TODO.  Note its long list of limitations.
-
-Build a kernel with VIDEO4LINUX enabled. Activate the
-BT848 driver; we need this because we have need for the
-other modules (i2c and videodev) it enables.
-
-To install this software, extract it into a suitable directory.
-Examine the makefile and change anything you don't like.  Type "make".
-
-After making the modules check if you have the much needed
-/dev/video devices. If not, execute the following 4 lines:
-        mknod /dev/video c 81 0
-        mknod /dev/video1 c 81 1
-        mknod /dev/video2 c 81 2
-        mknod /dev/video3 c 81 3
-        mknod /dev/video4 c 81 4
-
-After making/checking the devices do:
-        modprobe i2c
-        modprobe videodev
-        modprobe saa7110        (optional)
-        modprobe saa7111        (optional)
-        modprobe tuner          (optional)
-        insmod zoran cardtype=<n>
-
-<n> is the cardtype of the card you have. The cardnumber can
-be found in the source of zr36120. Look for tvcards. If your
-card is not there, please try if any other card gives some
-response, and mail me if you got a working tvcard addition.
-
-PS. <TVCard editors behold!)
-    Don't forget to set video_input to the number of inputs
-    you defined in the video_mux part of the tvcard definition.
-    It's a common error to add a channel but not incrementing
-    video_input and getting angry with me/v4l/linux/linus :(
-
-You are now ready to test the framegrabber with your favorite
-video4linux compatible tool
-
------- Application ----------------------------------------
-
-This device works with all Video4Linux compatible applications,
-given the limitations in the TODO file.
-
------- API ------------------------------------------------
-
-This uses the V4L interface as of kernel release 2.1.116, and in
-fact has not been tested on any lower version.  There are a couple
-of minor differences due to the fact that the amount of data returned
-with each frame varies, and no doubt there are discrepancies due to my
-misunderstanding of the API.  I intend to convert this driver to the
-new V4L2 API when it has stabilized more.
-
------- Current state --------------------------------------
-
-The driver is capable of overlaying a video image in screen, and
-even capable of grabbing frames. It uses the BIGPHYSAREA patch
-to allocate lots of large memory blocks when tis patch is
-found in the kernel, but it doesn't need it.
-The consequence is that, when loading the driver as a module,
-the module may tell you it's out of memory, but 'free' says
-otherwise. The reason is simple; the modules wants its memory
-contiguous, not fragmented, and after a long uptime there
-probably isn't a fragment of memory large enough...
-
-The driver uses a double buffering scheme, which should really
-be an n-way buffer, depending on the size of allocated framebuffer
-and the requested grab-size/format.
-This current version also fixes a dead-lock situation during irq
-time, which really, really froze my system... :)
-
-Good luck.
-  Pauline
diff --git a/Documentation/watchdog/src/watchdog-simple.c b/Documentation/watchdog/src/watchdog-simple.c
index 85cf17c48669..47801bc7e742 100644
--- a/Documentation/watchdog/src/watchdog-simple.c
+++ b/Documentation/watchdog/src/watchdog-simple.c
@@ -1,4 +1,6 @@
+#include <stdio.h>
 #include <stdlib.h>
+#include <unistd.h>
 #include <fcntl.h>
 
 int main(int argc, const char *argv[]) {
diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt
index 7e8ae83e9847..8d16f6f3c4ec 100644
--- a/Documentation/watchdog/watchdog-api.txt
+++ b/Documentation/watchdog/watchdog-api.txt
@@ -214,7 +214,7 @@ returned value is the temperature in degrees fahrenheit.
 
 Finally the SETOPTIONS ioctl can be used to control some aspects of
 the cards operation; right now the pcwd driver is the only one
-supporting thiss ioctl.
+supporting this ioctl.
 
     int options = 0;
     ioctl(fd, WDIOC_SETOPTIONS, options);
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index f3c57f43ba64..dbdcaf68e3ea 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -52,10 +52,6 @@ APICs
                  apicmaintimer. Useful when your PIT timer is totally
                  broken.
 
-   disable_8254_timer / enable_8254_timer
-                 Enable interrupt 0 timer routing over the 8254 in addition to over
-                 the IO-APIC. The kernel tries to set a sensible default.
-
 Early Console
 
    syntax: earlyprintk=vga
@@ -183,7 +179,7 @@ PCI
 IOMMU
 
  iommu=[size][,noagp][,off][,force][,noforce][,leak][,memaper[=order]][,merge]
-         [,forcesac][,fullflush][,nomerge][,noaperture]
+         [,forcesac][,fullflush][,nomerge][,noaperture][,calgary]
    size  set size of iommu (in bytes)
    noagp don't initialize the AGP driver and use full aperture.
    off   don't use the IOMMU
@@ -204,6 +200,7 @@ IOMMU
             buffering.
    nodac    Forbid DMA >4GB
    panic    Always panic when IOMMU overflows
+   calgary  Use the Calgary IOMMU if it is available
 
   swiotlb=pages[,force]