159 files changed, 6762 insertions, 3110 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index fc8e7c7d182f..1977fab38656 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -25,8 +25,6 @@ DMA-API.txt
         - DMA API, pci_ API & extensions for non-consistent memory machines.
 DMA-ISA-LPC.txt
         - How to do DMA with ISA (and LPC) devices.
-DMA-mapping.txt
-        - info for PCI drivers using DMA portably across all platforms.
 DocBook/
         - directory with DocBook templates etc. for kernel documentation.
 HOWTO
@@ -43,8 +41,6 @@ ManagementStyle
         - how to (attempt to) manage kernel hackers.
 MSI-HOWTO.txt
         - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
-PCIEBUS-HOWTO.txt
-        - a guide describing the PCI Express Port Bus driver.
 RCU/
         - directory with info on RCU (read-copy update).
 README.DAC960
@@ -167,10 +163,8 @@ highuid.txt
         - notes on the change from 16 bit to 32 bit user/group IDs.
 hpet.txt
         - High Precision Event Timer Driver for Linux.
-hrtimer/
-        - info on the timer_stats debugging facility for timer (ab)use.
-hrtimers/
-        - info on the hrtimers subsystem for high-resolution kernel timers.
+timers/
+        - info on the timer related topics
 hw_random.txt
         - info on Linux support for random number generator in i8xx chipsets.
 hwmon/
@@ -271,8 +265,6 @@ netlabel/
         - directory with information on the NetLabel subsystem.
 networking/
         - directory with info on various aspects of networking with Linux.
-nfsroot.txt
-        - short guide on setting up a diskless box with NFS root filesystem.
 nmi_watchdog.txt
         - info on NMI watchdog for SMP systems.
 nommu-mmap.txt
@@ -289,12 +281,6 @@ parport.txt
         - how to use the parallel-port driver.
 parport-lowlevel.txt
         - description and usage of the low level parallel port functions.
-pci-error-recovery.txt
-        - info on PCI error recovery.
-pci.txt
-        - info on the PCI subsystem for device driver authors.
-pcieaer-howto.txt
-        - the PCI Express Advanced Error Reporting Driver Guide HOWTO.
 pcmcia/
         - info on the Linux PCMCIA driver.
 pi-futex.txt
@@ -321,8 +307,6 @@ robust-futexes.txt
         - a description of what robust futexes are.
 rocket.txt
         - info on the Comtrol RocketPort multiport serial driver.
-rpc-cache.txt
-        - introduction to the caching mechanisms in the sunrpc layer.
 rt-mutex-design.txt
         - description of the RealTime mutex implementation design.
 rt-mutex.txt
@@ -345,8 +329,6 @@ sgi-visws.txt
         - short blurb on the SGI Visual Workstations.
 sh/
         - directory with info on porting Linux to a new architecture.
-smart-config.txt
-        - description of the Smart Config makefile feature.
 sound/
         - directory with info on sound card support.
 sparc/
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb
new file mode 100644
index 000000000000..9c49d8e6c0cc
--- /dev/null
+++ b/Documentation/ABI/obsolete/o2cb
@@ -0,0 +1,11 @@
+What:           /sys/o2cb symlink
+Date:           Dec 2005
+KernelVersion:  2.6.16
+Contact:        ocfs2-devel@oss.oracle.com
+Description:    This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will
+                be removed when new versions of ocfs2-tools which know to look
+                in /sys/fs/o2cb are sufficiently prevalent. Don't code new
+                software to look here, it should try /sys/fs/o2cb instead.
+                See Documentation/ABI/stable/o2cb for more information on usage.
+Users:          ocfs2-tools. It's sufficient to mail proposed changes to
+                ocfs2-devel@oss.oracle.com.
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb
new file mode 100644
index 000000000000..5eb1545e0b8d
--- /dev/null
+++ b/Documentation/ABI/stable/o2cb
@@ -0,0 +1,10 @@
+What:           /sys/fs/o2cb/ (was /sys/o2cb)
+Date:           Dec 2005
+KernelVersion:  2.6.16
+Contact:        ocfs2-devel@oss.oracle.com
+Description:    Ocfs2-tools looks at 'interface-revision' for versioning
+                information. Each logmask/ file controls a set of debug prints
+                and can be written into with the strings "allow", "deny", or
+                "off". Reading the file returns the current state.
+Users:          ocfs2-tools. It's sufficient to mail proposed changes to
+                ocfs2-devel@oss.oracle.com.
diff --git a/Documentation/ABI/stable/sysfs-class-ubi b/Documentation/ABI/stable/sysfs-class-ubi
new file mode 100644
index 000000000000..18d471d9faea
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-class-ubi
@@ -0,0 +1,212 @@
+What:           /sys/class/ubi/
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                The ubi/ class sub-directory belongs to the UBI subsystem and
+                provides general UBI information, per-UBI device information
+                and per-UBI volume information.
+
+What:           /sys/class/ubi/version
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                This file contains version of the latest supported UBI on-media
+                format. Currently it is 1, and there is no plan to change this.
+                However, if in the future UBI needs on-flash format changes
+                which cannot be done in a compatible manner, a new format
+                version will be added. So this is a mechanism for possible
+                future backward-compatible (but forward-incompatible)
+                improvements.
+
+What:           /sys/class/ubiX/
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                The /sys/class/ubi0, /sys/class/ubi1, etc directories describe
+                UBI devices (UBI device 0, 1, etc). They contain general UBI
+                device information and per UBI volume information (each UBI
+                device may have many UBI volumes)
+
+What:           /sys/class/ubi/ubiX/avail_eraseblocks
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Amount of available logical eraseblock. For example, one may
+                create a new UBI volume which has this amount of logical
+                eraseblocks.
+
+What:           /sys/class/ubi/ubiX/bad_peb_count
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Count of bad physical eraseblocks on the underlying MTD device.
+
+What:           /sys/class/ubi/ubiX/bgt_enabled
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Contains ASCII "0\n" if the UBI background thread is disabled,
+                and ASCII "1\n" if it is enabled.
+
+What:           /sys/class/ubi/ubiX/dev
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Major and minor numbers of the character device corresponding
+                to this UBI device (in <major>:<minor> format).
+
+What:           /sys/class/ubi/ubiX/eraseblock_size
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Maximum logical eraseblock size this UBI device may provide. UBI
+                volumes may have smaller logical eraseblock size because of their
+                alignment.
+
+What:           /sys/class/ubi/ubiX/max_ec
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Maximum physical eraseblock erase counter value.
+
+What:           /sys/class/ubi/ubiX/max_vol_count
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Maximum number of volumes which this UBI device may have.
+
+What:           /sys/class/ubi/ubiX/min_io_size
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Minimum input/output unit size. All the I/O may only be done
+                in fractions of the contained number.
+
+What:           /sys/class/ubi/ubiX/mtd_num
+Date:           January 2008
+KernelVersion:  2.6.25
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Number of the underlying MTD device.
+
+What:           /sys/class/ubi/ubiX/reserved_for_bad
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Number of physical eraseblocks reserved for bad block handling.
+
+What:           /sys/class/ubi/ubiX/total_eraseblocks
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Total number of good (not marked as bad) physical eraseblocks on
+                the underlying MTD device.
+
+What:           /sys/class/ubi/ubiX/volumes_count
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Count of volumes on this UBI device.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                The /sys/class/ubi/ubiX/ubiX_0/, /sys/class/ubi/ubiX/ubiX_1/,
+                etc directories describe UBI volumes on UBI device X (volumes
+                0, 1, etc).
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/alignment
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Volume alignment - the value the logical eraseblock size of
+                this volume has to be aligned on. For example, 2048 means that
+                logical eraseblock size is multiple of 2048. In other words,
+                volume logical eraseblock size is UBI device logical eraseblock
+                size aligned to the alignment value.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/corrupted
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Contains ASCII "0\n" if the UBI volume is OK, and ASCII "1\n"
+                if it is corrupted (e.g., due to an interrupted volume update).
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/data_bytes
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                The amount of data this volume contains. This value makes sense
+                only for static volumes, and for dynamic volume it equivalent
+                to the total volume size in bytes.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/dev
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Major and minor numbers of the character device corresponding
+                to this UBI volume (in <major>:<minor> format).
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/name
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Volume name.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/reserved_ebs
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Count of physical eraseblock reserved for this volume.
+                Equivalent to the volume size in logical eraseblocks.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/type
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Volume type. Contains ASCII "dynamic\n" for dynamic volumes and
+                "static\n" for static volumes.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/upd_marker
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Contains ASCII "0\n" if the update marker is not set for this
+                volume, and "1\n" if it is set. The update marker is set when
+                volume update starts, and cleaned when it ends. So the presence
+                of the update marker indicates that the volume is being updated
+                at the moment of the update was interrupted. The later may be
+                checked using the "corrupted" sysfs file.
+
+What:           /sys/class/ubi/ubiX/ubiX_Y/usable_eb_size
+Date:           July 2006
+KernelVersion:  2.6.22
+Contact:        Artem Bityutskiy <dedekind@infradead.org>
+Description:
+                Logical eraseblock size of this volume. Equivalent to logical
+                eraseblock size of the device aligned on the volume alignment
+                value.
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
new file mode 100644
index 000000000000..ceddcff4082a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -0,0 +1,11 @@
+What:           /sys/bus/pci/devices/.../vpd
+Date:           February 2008
+Contact:        Ben Hutchings <bhutchings@solarflare.com>
+Description:
+                A file named vpd in a device directory will be a
+                binary file containing the Vital Product Data for the
+                device.  It should follow the VPD format defined in
+                PCI Specification 2.1 or 2.2, but users should consider
+                that some devices may have malformatted data.  If the
+                underlying VPD has a writable section then the
+                corresponding section of this file will be writable.
diff --git a/Documentation/ABI/testing/sysfs-class-bdi b/Documentation/ABI/testing/sysfs-class-bdi
new file mode 100644
index 000000000000..5f500977b42f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-bdi
@@ -0,0 +1,50 @@
+What:           /sys/class/bdi/<bdi>/
+Date:           January 2008
+Contact:        Peter Zijlstra <a.p.zijlstra@chello.nl>
+Description:
+
+Provide a place in sysfs for the backing_dev_info object.  This allows
+setting and retrieving various BDI specific variables.
+
+The <bdi> identifier can be either of the following:
+
+MAJOR:MINOR
+
+        Device number for block devices, or value of st_dev on
+        non-block filesystems which provide their own BDI, such as NFS
+        and FUSE.
+
+MAJOR:MINOR-fuseblk
+
+        Value of st_dev on fuseblk filesystems.
+
+default
+
+        The default backing dev, used for non-block device backed
+        filesystems which do not provide their own BDI.
+
+Files under /sys/class/bdi/<bdi>/
+---------------------------------
+
+read_ahead_kb (read-write)
+
+        Size of the read-ahead window in kilobytes
+
+min_ratio (read-write)
+
+        Under normal circumstances each device is given a part of the
+        total write-back cache that relates to its current average
+        writeout speed in relation to the other devices.
+
+        The 'min_ratio' parameter allows assigning a minimum
+        percentage of the write-back cache to a particular device.
+        For example, this is useful for providing a minimum QoS.
+
+max_ratio (read-write)
+
+        Allows limiting a particular device to use not more than the
+        given percentage of the write-back cache.  This is useful in
+        situations where we want to avoid one device taking all or
+        most of the write-back cache.  For example in case of an NFS
+        mount that is prone to get stuck, or a FUSE mount which cannot
+        be trusted to play fair.
diff --git a/Documentation/ABI/testing/sysfs-ibft b/Documentation/ABI/testing/sysfs-ibft
new file mode 100644
index 000000000000..c2b7d1154bec
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ibft
@@ -0,0 +1,23 @@
+What:           /sys/firmware/ibft/initiator
+Date:           November 2007
+Contact:        Konrad Rzeszutek <ketuzsezr@darnok.org>
+Description:    The /sys/firmware/ibft/initiator directory will contain
+                files that expose the iSCSI Boot Firmware Table initiator data.
+                Usually this contains the Initiator name.
+
+What:           /sys/firmware/ibft/targetX
+Date:           November 2007
+Contact:        Konrad Rzeszutek <ketuzsezr@darnok.org>
+Description:    The /sys/firmware/ibft/targetX directory will contain
+                files that expose the iSCSI Boot Firmware Table target data.
+                Usually this contains the target's IP address, boot LUN,
+                target name, and what NIC it is associated with. It can also
+                contain the CHAP name (and password), the reverse CHAP
+                name (and password)
+
+What:           /sys/firmware/ibft/ethernetX
+Date:           November 2007
+Contact:        Konrad Rzeszutek <ketuzsezr@darnok.org>
+Description:    The /sys/firmware/ibft/ethernetX directory will contain
+                files that expose the iSCSI Boot Firmware Table NIC data.
+                This can this can the IP address, MAC, and gateway of the NIC.
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2
new file mode 100644
index 000000000000..b7cc516a8a8a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ocfs2
@@ -0,0 +1,89 @@
+What:           /sys/fs/ocfs2/
+Date:           April 2008
+Contact:        ocfs2-devel@oss.oracle.com
+Description:
+                The /sys/fs/ocfs2 directory contains knobs used by the
+                ocfs2-tools to interact with the filesystem.
+
+What:           /sys/fs/ocfs2/max_locking_protocol
+Date:           April 2008
+Contact:        ocfs2-devel@oss.oracle.com
+Description:
+                The /sys/fs/ocfs2/max_locking_protocol file displays version
+                of ocfs2 locking supported by the filesystem.  This version
+                covers how ocfs2 uses distributed locking between cluster
+                nodes.
+
+                The protocol version has a major and minor number.  Two
+                cluster nodes can interoperate if they have an identical
+                major number and an overlapping minor number - thus,
+                a node with version 1.10 can interoperate with a node
+                sporting version 1.8, as long as both use the 1.8 protocol.
+
+                Reading from this file returns a single line, the major
+                number and minor number joined by a period, eg "1.10".
+
+                This file is read-only.  The value is compiled into the
+                driver.
+
+What:           /sys/fs/ocfs2/loaded_cluster_plugins
+Date:           April 2008
+Contact:        ocfs2-devel@oss.oracle.com
+Description:
+                The /sys/fs/ocfs2/loaded_cluster_plugins file describes
+                the available plugins to support ocfs2 cluster operation.
+                A cluster plugin is required to use ocfs2 in a cluster.
+                There are currently two available plugins:
+
+                * 'o2cb' - The classic o2cb cluster stack that ocfs2 has
+                        used since its inception.
+                * 'user' - A plugin supporting userspace cluster software
+                        in conjunction with fs/dlm.
+
+                Reading from this file returns the names of all loaded
+                plugins, one per line.
+
+                This file is read-only.  Its contents may change as
+                plugins are loaded or removed.
+
+What:           /sys/fs/ocfs2/active_cluster_plugin
+Date:           April 2008
+Contact:        ocfs2-devel@oss.oracle.com
+Description:
+                The /sys/fs/ocfs2/active_cluster_plugin displays which
+                cluster plugin is currently in use by the filesystem.
+                The active plugin will appear in the loaded_cluster_plugins
+                file as well.  Only one plugin can be used at a time.
+
+                Reading from this file returns the name of the active plugin
+                on a single line.
+
+                This file is read-only.  Which plugin is active depends on
+                the cluster stack in use.  The contents may change
+                when all filesystems are unmounted and the cluster stack
+                is changed.
+
+What:           /sys/fs/ocfs2/cluster_stack
+Date:           April 2008
+Contact:        ocfs2-devel@oss.oracle.com
+Description:
+                The /sys/fs/ocfs2/cluster_stack file contains the name
+                of current ocfs2 cluster stack.  This value is set by
+                userspace tools when bringing the cluster stack online.
+
+                Cluster stack names are 4 characters in length.
+
+                When the 'o2cb' cluster stack is used, the 'o2cb' cluster
+                plugin is active.  All other cluster stacks use the 'user'
+                cluster plugin.
+
+                Reading from this file returns the name of the current
+                cluster stack on a single line.
+
+                Writing a new stack name to this file changes the current
+                cluster stack unless there are mounted ocfs2 filesystems.
+                If there are mounted filesystems, attempts to change the
+                stack return an error.
+
+Users:
+        ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index b939ebb62871..80d150458c80 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -145,7 +145,7 @@ Part Ic - DMA addressing limitations
 int
 dma_supported(struct device *dev, u64 mask)
 int
-pci_dma_supported(struct device *dev, u64 mask)
+pci_dma_supported(struct pci_dev *hwdev, u64 mask)
 
 Checks to see if the device can support DMA to the memory described by
 mask.
@@ -189,7 +189,7 @@ dma_addr_t
 dma_map_single(struct device *dev, void *cpu_addr, size_t size,
                       enum dma_data_direction direction)
 dma_addr_t
-pci_map_single(struct device *dev, void *cpu_addr, size_t size,
+pci_map_single(struct pci_dev *hwdev, void *cpu_addr, size_t size,
                       int direction)
 
 Maps a piece of processor virtual memory so it can be accessed by the
@@ -395,6 +395,71 @@ Notes:  You must do this:
 
 See also dma_map_single().
 
+dma_addr_t
+dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,
+                     enum dma_data_direction dir,
+                     struct dma_attrs *attrs)
+
+void
+dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,
+                       size_t size, enum dma_data_direction dir,
+                       struct dma_attrs *attrs)
+
+int
+dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
+                 int nents, enum dma_data_direction dir,
+                 struct dma_attrs *attrs)
+
+void
+dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,
+                   int nents, enum dma_data_direction dir,
+                   struct dma_attrs *attrs)
+
+The four functions above are just like the counterpart functions
+without the _attrs suffixes, except that they pass an optional
+struct dma_attrs*.
+
+struct dma_attrs encapsulates a set of "dma attributes". For the
+definition of struct dma_attrs see linux/dma-attrs.h.
+
+The interpretation of dma attributes is architecture-specific, and
+each attribute should be documented in Documentation/DMA-attributes.txt.
+
+If struct dma_attrs* is NULL, the semantics of each of these
+functions is identical to those of the corresponding function
+without the _attrs suffix. As a result dma_map_single_attrs()
+can generally replace dma_map_single(), etc.
+
+As an example of the use of the *_attrs functions, here's how
+you could pass an attribute DMA_ATTR_FOO when mapping memory
+for DMA:
+
+#include <linux/dma-attrs.h>
+/* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and
+ * documented in Documentation/DMA-attributes.txt */
+...
+
+        DEFINE_DMA_ATTRS(attrs);
+        dma_set_attr(DMA_ATTR_FOO, &attrs);
+        ....
+        n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, &attr);
+        ....
+
+Architectures that care about DMA_ATTR_FOO would check for its
+presence in their implementations of the mapping and unmapping
+routines, e.g.:
+
+void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
+                             size_t size, enum dma_data_direction dir,
+                             struct dma_attrs *attrs)
+{
+        ....
+        int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);
+        ....
+        if (foo)
+                /* twizzle the frobnozzle */
+        ....
+
 
 Part II - Advanced dma_ usage
 -----------------------------
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
new file mode 100644
index 000000000000..6d772f84b477
--- /dev/null
+++ b/Documentation/DMA-attributes.txt
@@ -0,0 +1,24 @@
+                        DMA attributes
+                        ==============
+
+This document describes the semantics of the DMA attributes that are
+defined in linux/dma-attrs.h.
+
+DMA_ATTR_WRITE_BARRIER
+----------------------
+
+DMA_ATTR_WRITE_BARRIER is a (write) barrier attribute for DMA.  DMA
+to a memory region with the DMA_ATTR_WRITE_BARRIER attribute forces
+all pending DMA writes to complete, and thus provides a mechanism to
+strictly order DMA from a device across all intervening busses and
+bridges.  This barrier is not specific to a particular type of
+interconnect, it applies to the system as a whole, and so its
+implementation must account for the idiosyncracies of the system all
+the way from the DMA device to memory.
+
+As an example of a situation where DMA_ATTR_WRITE_BARRIER would be
+useful, suppose that a device does a DMA write to indicate that data is
+ready and available in memory.  The DMA of the "completion indication"
+could race with data DMA.  Mapping the memory used for completion
+indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
+
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index d84f89dbf921..b463ecd0c7ce 100644
--- a/Documentation/DMA-mapping.txt
+++ b/Documentation/DMA-mapping.txt
@@ -315,11 +315,11 @@ you should do:
 
         dma_addr_t dma_handle;
 
-        cpu_addr = pci_alloc_consistent(dev, size, &dma_handle);
+        cpu_addr = pci_alloc_consistent(pdev, size, &dma_handle);
 
-where dev is a struct pci_dev *. You should pass NULL for PCI like buses
-where devices don't have struct pci_dev (like ISA, EISA).  This may be
-called in interrupt context. 
+where pdev is a struct pci_dev *. This may be called in interrupt context.
+You should use dma_alloc_coherent (see DMA-API.txt) for buses
+where devices don't have struct pci_dev (like ISA, EISA).
 
 This argument is needed because the DMA translations may be bus
 specific (and often is private to the bus which the device is attached
@@ -332,7 +332,7 @@ __get_free_pages (but takes size instead of a page order).  If your
 driver needs regions sized smaller than a page, you may prefer using
 the pci_pool interface, described below.
 
-The consistent DMA mapping interfaces, for non-NULL dev, will by
+The consistent DMA mapping interfaces, for non-NULL pdev, will by
 default return a DMA address which is SAC (Single Address Cycle)
 addressable.  Even if the device indicates (via PCI dma mask) that it
 may address the upper 32-bits and thus perform DAC cycles, consistent
@@ -354,9 +354,9 @@ buffer you receive will not cross a 64K boundary.
 
 To unmap and free such a DMA region, you call:
 
-        pci_free_consistent(dev, size, cpu_addr, dma_handle);
+        pci_free_consistent(pdev, size, cpu_addr, dma_handle);
 
-where dev, size are the same as in the above call and cpu_addr and
+where pdev, size are the same as in the above call and cpu_addr and
 dma_handle are the values pci_alloc_consistent returned to you.
 This function may not be called in interrupt context.
 
@@ -371,9 +371,9 @@ Create a pci_pool like this:
 
         struct pci_pool *pool;
 
-        pool = pci_pool_create(name, dev, size, align, alloc);
+        pool = pci_pool_create(name, pdev, size, align, alloc);
 
-The "name" is for diagnostics (like a kmem_cache name); dev and size
+The "name" is for diagnostics (like a kmem_cache name); pdev and size
 are as above.  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 crossing restrictions,
@@ -472,11 +472,11 @@ To map a single region, you do:
         void *addr = buffer->ptr;
         size_t size = buffer->len;
 
-        dma_handle = pci_map_single(dev, addr, size, direction);
+        dma_handle = pci_map_single(pdev, addr, size, direction);
 
 and to unmap it:
 
-        pci_unmap_single(dev, dma_handle, size, direction);
+        pci_unmap_single(pdev, dma_handle, size, direction);
 
 You should call pci_unmap_single when the DMA activity is finished, e.g.
 from the interrupt which told you that the DMA transfer is done.
@@ -493,17 +493,17 @@ Specifically:
         unsigned long offset = buffer->offset;
         size_t size = buffer->len;
 
-        dma_handle = pci_map_page(dev, page, offset, size, direction);
+        dma_handle = pci_map_page(pdev, page, offset, size, direction);
 
         ...
 
-        pci_unmap_page(dev, dma_handle, size, direction);
+        pci_unmap_page(pdev, dma_handle, size, direction);
 
 Here, "offset" means byte offset within the given page.
 
 With scatterlists, you map a region gathered from several regions by:
 
-        int i, count = pci_map_sg(dev, sglist, nents, direction);
+        int i, count = pci_map_sg(pdev, sglist, nents, direction);
         struct scatterlist *sg;
 
         for_each_sg(sglist, sg, count, i) {
@@ -527,7 +527,7 @@ accessed sg->address and sg->length as shown above.
 
 To unmap a scatterlist, just call:
 
-        pci_unmap_sg(dev, sglist, nents, direction);
+        pci_unmap_sg(pdev, sglist, nents, direction);
 
 Again, make sure DMA activity has already finished.
 
@@ -550,11 +550,11 @@ correct copy of the DMA buffer.
 So, firstly, just map it with pci_map_{single,sg}, and after each DMA
 transfer call either:
 
-        pci_dma_sync_single_for_cpu(dev, dma_handle, size, direction);
+        pci_dma_sync_single_for_cpu(pdev, dma_handle, size, direction);
 
 or:
 
-        pci_dma_sync_sg_for_cpu(dev, sglist, nents, direction);
+        pci_dma_sync_sg_for_cpu(pdev, sglist, nents, direction);
 
 as appropriate.
 
@@ -562,7 +562,7 @@ Then, if you wish to let the device get at the DMA area again,
 finish accessing the data with the cpu, and then before actually
 giving the buffer to the hardware call either:
 
-        pci_dma_sync_single_for_device(dev, dma_handle, size, direction);
+        pci_dma_sync_single_for_device(pdev, dma_handle, size, direction);
 
 or:
 
@@ -739,7 +739,7 @@ failure can be determined by:
 
         dma_addr_t dma_handle;
 
-        dma_handle = pci_map_single(dev, addr, size, direction);
+        dma_handle = pci_map_single(pdev, addr, size, direction);
         if (pci_dma_mapping_error(dma_handle)) {
                 /*
                  * reduce current DMA mapping usage,
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 300e1707893f..0eb0d027eb32 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -9,9 +9,10 @@
 DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
             kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
             procfs-guide.xml writing_usb_driver.xml networking.xml \
-            kernel-api.xml filesystems.xml lsm.xml usb.xml \
+            kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
             gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-            genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
+            genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
+            mac80211.xml debugobjects.xml
 
 ###
 # The build process is as follows (targets):
@@ -186,8 +187,11 @@ quiet_cmd_fig2png = FIG2PNG $@
 
 ###
 # Rule to convert a .c file to inline XML documentation
+       gen_xml = :
+ quiet_gen_xml = echo '  GEN     $@'
+silent_gen_xml = :
 %.xml: %.c
-        @echo '  GEN     $@'
+        @$($(quiet)gen_xml)
         @(                            \
            echo "<programlisting>";   \
            expand --tabs=8 < $< |     \
diff --git a/Documentation/DocBook/debugobjects.tmpl b/Documentation/DocBook/debugobjects.tmpl
new file mode 100644
index 000000000000..7f5f218015fe
--- /dev/null
+++ b/Documentation/DocBook/debugobjects.tmpl
@@ -0,0 +1,391 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!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="debug-objects-guide">
+ <bookinfo>
+  <title>Debug objects life time</title>
+
+  <authorgroup>
+   <author>
+    <firstname>Thomas</firstname>
+    <surname>Gleixner</surname>
+    <affiliation>
+     <address>
+      <email>tglx@linutronix.de</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <copyright>
+   <year>2008</year>
+   <holder>Thomas Gleixner</holder>
+  </copyright>
+
+  <legalnotice>
+   <para>
+     This documentation is free software; you can redistribute
+     it and/or modify it under the terms of the GNU General Public
+     License version 2 as published by the Free Software Foundation.
+   </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.
+   </para>
+  </legalnotice>
+ </bookinfo>
+
+<toc></toc>
+
+  <chapter id="intro">
+    <title>Introduction</title>
+    <para>
+      debugobjects is a generic infrastructure to track the life time
+      of kernel objects and validate the operations on those.
+    </para>
+    <para>
+      debugobjects is useful to check for the following error patterns:
+        <itemizedlist>
+          <listitem><para>Activation of uninitialized objects</para></listitem>
+          <listitem><para>Initialization of active objects</para></listitem>
+          <listitem><para>Usage of freed/destroyed objects</para></listitem>
+        </itemizedlist>
+    </para>
+    <para>
+      debugobjects is not changing the data structure of the real
+      object so it can be compiled in with a minimal runtime impact
+      and enabled on demand with a kernel command line option.
+    </para>
+  </chapter>
+
+  <chapter id="howto">
+    <title>Howto use debugobjects</title>
+    <para>
+      A kernel subsystem needs to provide a data structure which
+      describes the object type and add calls into the debug code at
+      appropriate places. The data structure to describe the object
+      type needs at minimum the name of the object type. Optional
+      functions can and should be provided to fixup detected problems
+      so the kernel can continue to work and the debug information can
+      be retrieved from a live system instead of hard core debugging
+      with serial consoles and stack trace transcripts from the
+      monitor.
+    </para>
+    <para>
+      The debug calls provided by debugobjects are:
+      <itemizedlist>
+        <listitem><para>debug_object_init</para></listitem>
+        <listitem><para>debug_object_init_on_stack</para></listitem>
+        <listitem><para>debug_object_activate</para></listitem>
+        <listitem><para>debug_object_deactivate</para></listitem>
+        <listitem><para>debug_object_destroy</para></listitem>
+        <listitem><para>debug_object_free</para></listitem>
+      </itemizedlist>
+      Each of these functions takes the address of the real object and
+      a pointer to the object type specific debug description
+      structure.
+    </para>
+    <para>
+      Each detected error is reported in the statistics and a limited
+      number of errors are printk'ed including a full stack trace.
+    </para>
+    <para>
+      The statistics are available via debugfs/debug_objects/stats.
+      They provide information about the number of warnings and the
+      number of successful fixups along with information about the
+      usage of the internal tracking objects and the state of the
+      internal tracking objects pool.
+    </para>
+  </chapter>
+  <chapter id="debugfunctions">
+    <title>Debug functions</title>
+    <sect1 id="prototypes">
+      <title>Debug object function reference</title>
+!Elib/debugobjects.c
+    </sect1>
+    <sect1 id="debug_object_init">
+      <title>debug_object_init</title>
+      <para>
+        This function is called whenever the initialization function
+        of a real object is called.
+      </para>
+      <para>
+        When the real object is already tracked by debugobjects it is
+        checked, whether the object can be initialized.  Initializing
+        is not allowed for active and destroyed objects. When
+        debugobjects detects an error, then it calls the fixup_init
+        function of the object type description structure if provided
+        by the caller. The fixup function can correct the problem
+        before the real initialization of the object happens. E.g. it
+        can deactivate an active object in order to prevent damage to
+        the subsystem.
+      </para>
+      <para>
+        When the real object is not yet tracked by debugobjects,
+        debugobjects allocates a tracker object for the real object
+        and sets the tracker object state to ODEBUG_STATE_INIT. It
+        verifies that the object is not on the callers stack. If it is
+        on the callers stack then a limited number of warnings
+        including a full stack trace is printk'ed. The calling code
+        must use debug_object_init_on_stack() and remove the object
+        before leaving the function which allocated it. See next
+        section.
+      </para>
+    </sect1>
+
+    <sect1 id="debug_object_init_on_stack">
+      <title>debug_object_init_on_stack</title>
+      <para>
+        This function is called whenever the initialization function
+        of a real object which resides on the stack is called.
+      </para>
+      <para>
+        When the real object is already tracked by debugobjects it is
+        checked, whether the object can be initialized. Initializing
+        is not allowed for active and destroyed objects. When
+        debugobjects detects an error, then it calls the fixup_init
+        function of the object type description structure if provided
+        by the caller. The fixup function can correct the problem
+        before the real initialization of the object happens. E.g. it
+        can deactivate an active object in order to prevent damage to
+        the subsystem.
+      </para>
+      <para>
+        When the real object is not yet tracked by debugobjects
+        debugobjects allocates a tracker object for the real object
+        and sets the tracker object state to ODEBUG_STATE_INIT. It
+        verifies that the object is on the callers stack.
+      </para>
+      <para>
+        An object which is on the stack must be removed from the
+        tracker by calling debug_object_free() before the function
+        which allocates the object returns. Otherwise we keep track of
+        stale objects.
+      </para>
+    </sect1>
+
+    <sect1 id="debug_object_activate">
+      <title>debug_object_activate</title>
+      <para>
+        This function is called whenever the activation function of a
+        real object is called.
+      </para>
+      <para>
+        When the real object is already tracked by debugobjects it is
+        checked, whether the object can be activated.  Activating is
+        not allowed for active and destroyed objects. When
+        debugobjects detects an error, then it calls the
+        fixup_activate function of the object type description
+        structure if provided by the caller. The fixup function can
+        correct the problem before the real activation of the object
+        happens. E.g. it can deactivate an active object in order to
+        prevent damage to the subsystem.
+      </para>
+      <para>
+        When the real object is not yet tracked by debugobjects then
+        the fixup_activate function is called if available. This is
+        necessary to allow the legitimate activation of statically
+        allocated and initialized objects. The fixup function checks
+        whether the object is valid and calls the debug_objects_init()
+        function to initialize the tracking of this object.
+      </para>
+      <para>
+        When the activation is legitimate, then the state of the
+        associated tracker object is set to ODEBUG_STATE_ACTIVE.
+      </para>
+    </sect1>
+
+    <sect1 id="debug_object_deactivate">
+      <title>debug_object_deactivate</title>
+      <para>
+        This function is called whenever the deactivation function of
+        a real object is called.
+      </para>
+      <para>
+        When the real object is tracked by debugobjects it is checked,
+        whether the object can be deactivated. Deactivating is not
+        allowed for untracked or destroyed objects.
+      </para>
+      <para>
+        When the deactivation is legitimate, then the state of the
+        associated tracker object is set to ODEBUG_STATE_INACTIVE.
+      </para>
+    </sect1>
+
+    <sect1 id="debug_object_destroy">
+      <title>debug_object_destroy</title>
+      <para>
+        This function is called to mark an object destroyed. This is
+        useful to prevent the usage of invalid objects, which are
+        still available in memory: either statically allocated objects
+        or objects which are freed later.
+      </para>
+      <para>
+        When the real object is tracked by debugobjects it is checked,
+        whether the object can be destroyed. Destruction is not
+        allowed for active and destroyed objects. When debugobjects
+        detects an error, then it calls the fixup_destroy function of
+        the object type description structure if provided by the
+        caller. The fixup function can correct the problem before the
+        real destruction of the object happens. E.g. it can deactivate
+        an active object in order to prevent damage to the subsystem.
+      </para>
+      <para>
+        When the destruction is legitimate, then the state of the
+        associated tracker object is set to ODEBUG_STATE_DESTROYED.
+      </para>
+    </sect1>
+
+    <sect1 id="debug_object_free">
+      <title>debug_object_free</title>
+      <para>
+        This function is called before an object is freed.
+      </para>
+      <para>
+        When the real object is tracked by debugobjects it is checked,
+        whether the object can be freed. Free is not allowed for
+        active objects. When debugobjects detects an error, then it
+        calls the fixup_free function of the object type description
+        structure if provided by the caller. The fixup function can
+        correct the problem before the real free of the object
+        happens. E.g. it can deactivate an active object in order to
+        prevent damage to the subsystem.
+      </para>
+      <para>
+        Note that debug_object_free removes the object from the
+        tracker. Later usage of the object is detected by the other
+        debug checks.
+      </para>
+    </sect1>
+  </chapter>
+  <chapter id="fixupfunctions">
+    <title>Fixup functions</title>
+    <sect1 id="debug_obj_descr">
+      <title>Debug object type description structure</title>
+!Iinclude/linux/debugobjects.h
+    </sect1>
+    <sect1 id="fixup_init">
+      <title>fixup_init</title>
+      <para>
+        This function is called from the debug code whenever a problem
+        in debug_object_init is detected. The function takes the
+        address of the object and the state which is currently
+        recorded in the tracker.
+      </para>
+      <para>
+        Called from debug_object_init when the object state is:
+        <itemizedlist>
+          <listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
+        </itemizedlist>
+      </para>
+      <para>
+        The function returns 1 when the fixup was successful,
+        otherwise 0. The return value is used to update the
+        statistics.
+      </para>
+      <para>
+        Note, that the function needs to call the debug_object_init()
+        function again, after the damage has been repaired in order to
+        keep the state consistent.
+      </para>
+    </sect1>
+
+    <sect1 id="fixup_activate">
+      <title>fixup_activate</title>
+      <para>
+        This function is called from the debug code whenever a problem
+        in debug_object_activate is detected.
+      </para>
+      <para>
+        Called from debug_object_activate when the object state is:
+        <itemizedlist>
+          <listitem><para>ODEBUG_STATE_NOTAVAILABLE</para></listitem>
+          <listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
+        </itemizedlist>
+      </para>
+      <para>
+        The function returns 1 when the fixup was successful,
+        otherwise 0. The return value is used to update the
+        statistics.
+      </para>
+      <para>
+        Note that the function needs to call the debug_object_activate()
+        function again after the damage has been repaired in order to
+        keep the state consistent.
+      </para>
+      <para>
+        The activation of statically initialized objects is a special
+        case. When debug_object_activate() has no tracked object for
+        this object address then fixup_activate() is called with
+        object state ODEBUG_STATE_NOTAVAILABLE. The fixup function
+        needs to check whether this is a legitimate case of a
+        statically initialized object or not. In case it is it calls
+        debug_object_init() and debug_object_activate() to make the
+        object known to the tracker and marked active. In this case
+        the function should return 0 because this is not a real fixup.
+      </para>
+    </sect1>
+
+    <sect1 id="fixup_destroy">
+      <title>fixup_destroy</title>
+      <para>
+        This function is called from the debug code whenever a problem
+        in debug_object_destroy is detected.
+      </para>
+      <para>
+        Called from debug_object_destroy when the object state is:
+        <itemizedlist>
+          <listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
+        </itemizedlist>
+      </para>
+      <para>
+        The function returns 1 when the fixup was successful,
+        otherwise 0. The return value is used to update the
+        statistics.
+      </para>
+    </sect1>
+    <sect1 id="fixup_free">
+      <title>fixup_free</title>
+      <para>
+        This function is called from the debug code whenever a problem
+        in debug_object_free is detected. Further it can be called
+        from the debug checks in kfree/vfree, when an active object is
+        detected from the debug_check_no_obj_freed() sanity checks.
+      </para>
+      <para>
+        Called from debug_object_free() or debug_check_no_obj_freed()
+        when the object state is:
+        <itemizedlist>
+          <listitem><para>ODEBUG_STATE_ACTIVE</para></listitem>
+        </itemizedlist>
+      </para>
+      <para>
+        The function returns 1 when the fixup was successful,
+        otherwise 0. The return value is used to update the
+        statistics.
+      </para>
+    </sect1>
+  </chapter>
+  <chapter id="bugs">
+    <title>Known Bugs And Assumptions</title>
+    <para>
+        None (knock on wood).
+    </para>
+  </chapter>
+</book>
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index dc0f30c3e571..b7b1482f6e04 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -119,7 +119,7 @@ X!Ilib/string.c
 !Elib/string.c
      </sect1>
      <sect1><title>Bit Operations</title>
-!Iinclude/asm-x86/bitops_32.h
+!Iinclude/asm-x86/bitops.h
      </sect1>
   </chapter>
 
@@ -297,11 +297,6 @@ X!Earch/x86/kernel/mca_32.c
 !Ikernel/acct.c
   </chapter>
 
-  <chapter id="pmfuncs">
-     <title>Power Management</title>
-!Ekernel/power/pm.c
-  </chapter>
-
   <chapter id="devdrivers">
      <title>Device drivers infrastructure</title>
      <sect1><title>Device Drivers Base</title>
@@ -650,4 +645,58 @@ X!Idrivers/video/console/fonts.c
 !Edrivers/i2c/i2c-core.c
   </chapter>
 
+  <chapter id="clk">
+     <title>Clock Framework</title>
+
+     <para>
+        The clock framework defines programming interfaces to support
+        software management of the system clock tree.
+        This framework is widely used with System-On-Chip (SOC) platforms
+        to support power management and various devices which may need
+        custom clock rates.
+        Note that these "clocks" don't relate to timekeeping or real
+        time clocks (RTCs), each of which have separate frameworks.
+        These <structname>struct clk</structname> instances may be used
+        to manage for example a 96 MHz signal that is used to shift bits
+        into and out of peripherals or busses, or otherwise trigger
+        synchronous state machine transitions in system hardware.
+     </para>
+
+     <para>
+        Power management is supported by explicit software clock gating:
+        unused clocks are disabled, so the system doesn't waste power
+        changing the state of transistors that aren't in active use.
+        On some systems this may be backed by hardware clock gating,
+        where clocks are gated without being disabled in software.
+        Sections of chips that are powered but not clocked may be able
+        to retain their last state.
+        This low power state is often called a <emphasis>retention
+        mode</emphasis>.
+        This mode still incurs leakage currents, especially with finer
+        circuit geometries, but for CMOS circuits power is mostly used
+        by clocked state changes.
+     </para>
+
+     <para>
+        Power-aware drivers only enable their clocks when the device
+        they manage is in active use.  Also, system sleep states often
+        differ according to which clock domains are active:  while a
+        "standby" state may allow wakeup from several active domains, a
+        "mem" (suspend-to-RAM) state may require a more wholesale shutdown
+        of clocks derived from higher speed PLLs and oscillators, limiting
+        the number of possible wakeup event sources.  A driver's suspend
+        method may need to be aware of system-specific clock constraints
+        on the target sleep state.
+     </para>
+
+     <para>
+        Some platforms support programmable clock generators.  These
+        can be used by external chips of various kinds, such as other
+        CPUs, multimedia codecs, and devices with strict requirements
+        for interface clocking.
+     </para>
+
+!Iinclude/linux/clk.h
+  </chapter>
+
 </book>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 2e9d6b41f034..2510763295d0 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -241,7 +241,7 @@
    </para>
    <para>
      The third type is a semaphore
-     (<filename class="headerfile">include/asm/semaphore.h</filename>): it
+     (<filename class="headerfile">include/linux/semaphore.h</filename>): it
      can have more than one holder at any time (the number decided at
      initialization time), although it is most commonly used as a
      single-holder lock (a mutex).  If you can't get a semaphore, your
@@ -290,7 +290,7 @@
      <para>
        If you have a data structure which is only ever accessed from
        user context, then you can use a simple semaphore
-       (<filename>linux/asm/semaphore.h</filename>) to protect it.  This 
+       (<filename>linux/linux/semaphore.h</filename>) to protect it.  This
        is the most trivial case: you initialize the semaphore to the number 
        of resources available (usually 1), and call
        <function>down_interruptible()</function> to grab the semaphore, and 
@@ -703,6 +703,31 @@
 </sect1>
 </chapter>
 
+<chapter id="trylock-functions">
+ <title>The trylock Functions</title>
+  <para>
+   There are functions that try to acquire a lock only once and immediately
+   return a value telling about success or failure to acquire the lock.
+   They can be used if you need no access to the data protected with the lock
+   when some other thread is holding the lock. You should acquire the lock
+   later if you then need access to the data protected with the lock.
+  </para>
+
+  <para>
+    <function>spin_trylock()</function> does not spin but returns non-zero if
+    it acquires the spinlock on the first try or 0 if not. This function can
+    be used in all contexts like <function>spin_lock</function>: you must have
+    disabled the contexts that might interrupt you and acquire the spin lock.
+  </para>
+
+  <para>
+    <function>mutex_trylock()</function> does not suspend your task
+    but returns non-zero if it could lock the mutex on the first try
+    or 0 if not. This function cannot be safely used in hardware or software
+    interrupt contexts despite not sleeping.
+  </para>
+</chapter>
+
   <chapter id="Examples">
    <title>Common Examples</title>
     <para>
@@ -854,7 +879,7 @@ The change is shown below, in standard patch format: the
  };
 
 -static DEFINE_MUTEX(cache_lock);
-+static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
++static DEFINE_SPINLOCK(cache_lock);
  static LIST_HEAD(cache);
  static unsigned int cache_num = 0;
  #define MAX_CACHE_SIZE 10
@@ -1238,7 +1263,7 @@ Here is the "lock-per-object" implementation:
 -        int popularity;
  };
 
- static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
+ static DEFINE_SPINLOCK(cache_lock);
 @@ -77,6 +84,7 @@
          obj-&gt;id = id;
          obj-&gt;popularity = 0;
@@ -1656,7 +1681,7 @@ the amount of locking which needs to be done.
  #include &lt;linux/slab.h&gt;
  #include &lt;linux/string.h&gt;
 +#include &lt;linux/rcupdate.h&gt;
- #include &lt;asm/semaphore.h&gt;
+ #include &lt;linux/semaphore.h&gt;
  #include &lt;asm/errno.h&gt;
 
  struct object
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
new file mode 100644
index 000000000000..e8acd1f03456
--- /dev/null
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -0,0 +1,441 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!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="kgdbOnLinux">
+ <bookinfo>
+  <title>Using kgdb and the kgdb Internals</title>
+
+  <authorgroup>
+   <author>
+    <firstname>Jason</firstname>
+    <surname>Wessel</surname>
+    <affiliation>
+     <address>
+      <email>jason.wessel@windriver.com</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <authorgroup>
+   <author>
+    <firstname>Tom</firstname>
+    <surname>Rini</surname>
+    <affiliation>
+     <address>
+      <email>trini@kernel.crashing.org</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <authorgroup>
+   <author>
+    <firstname>Amit S.</firstname>
+    <surname>Kale</surname>
+    <affiliation>
+     <address>
+      <email>amitkale@linsyssoft.com</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <copyright>
+   <year>2008</year>
+   <holder>Wind River Systems, Inc.</holder>
+  </copyright>
+  <copyright>
+   <year>2004-2005</year>
+   <holder>MontaVista Software, Inc.</holder>
+  </copyright>
+  <copyright>
+   <year>2004</year>
+   <holder>Amit S. Kale</holder>
+  </copyright>
+
+  <legalnotice>
+   <para>
+   This file is licensed under the terms of the GNU General Public License
+   version 2. This program is licensed "as is" without any warranty of any
+   kind, whether express or implied.
+   </para>
+
+  </legalnotice>
+ </bookinfo>
+
+<toc></toc>
+  <chapter id="Introduction">
+    <title>Introduction</title>
+    <para>
+    kgdb is a source level debugger for linux kernel. It is used along
+    with gdb to debug a linux kernel.  The expectation is that gdb can
+    be used to "break in" to the kernel to inspect memory, variables
+    and look through call stack information similar to what an
+    application developer would use gdb for.  It is possible to place
+    breakpoints in kernel code and perform some limited execution
+    stepping.
+    </para>
+    <para>
+    Two machines are required for using kgdb. One of these machines is a
+    development machine and the other is a test machine.  The kernel
+    to be debugged runs on the test machine. The development machine
+    runs an instance of gdb against the vmlinux file which contains
+    the symbols (not boot image such as bzImage, zImage, uImage...).
+    In gdb the developer specifies the connection parameters and
+    connects to kgdb.  The type of connection a developer makes with
+    gdb depends on the availability of kgdb I/O modules compiled as
+    builtin's or kernel modules in the test machine's kernel.
+    </para>
+  </chapter>
+  <chapter id="CompilingAKernel">
+    <title>Compiling a kernel</title>
+    <para>
+    To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
+    "Prompt for development and/or incomplete code/drivers"
+    (CONFIG_EXPERIMENTAL) in  "General setup", then under the
+    "Kernel debugging" select "KGDB: kernel debugging with remote gdb".
+    </para>
+    <para>
+    Next you should choose one of more I/O drivers to interconnect debugging
+    host and debugged target.  Early boot debugging requires a KGDB
+    I/O driver that supports early debugging and the driver must be
+    built into the kernel directly. Kgdb I/O driver configuration
+    takes place via kernel or module parameters, see following
+    chapter.
+    </para>
+    <para>
+    The kgdb test compile options are described in the kgdb test suite chapter.
+    </para>
+
+  </chapter>
+  <chapter id="EnableKGDB">
+   <title>Enable kgdb for debugging</title>
+   <para>
+   In order to use kgdb you must activate it by passing configuration
+   information to one of the kgdb I/O drivers.  If you do not pass any
+   configuration information kgdb will not do anything at all.  Kgdb
+   will only actively hook up to the kernel trap hooks if a kgdb I/O
+   driver is loaded and configured.  If you unconfigure a kgdb I/O
+   driver, kgdb will unregister all the kernel hook points.
+   </para>
+   <para>
+   All drivers can be reconfigured at run time, if
+   <symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol>
+   are enabled, by echo'ing a new config string to
+   <constant>/sys/module/&lt;driver&gt;/parameter/&lt;option&gt;</constant>.
+   The driver can be unconfigured by passing an empty string.  You cannot
+   change the configuration while the debugger is attached.  Make sure
+   to detach the debugger with the <constant>detach</constant> command
+   prior to trying unconfigure a kgdb I/O driver.
+   </para>
+   <sect1 id="kgdbwait">
+   <title>Kernel parameter: kgdbwait</title>
+   <para>
+   The Kernel command line option <constant>kgdbwait</constant> makes
+   kgdb wait for a debugger connection during booting of a kernel.  You
+   can only use this option you compiled a kgdb I/O driver into the
+   kernel and you specified the I/O driver configuration as a kernel
+   command line option.  The kgdbwait parameter should always follow the
+   configuration parameter for the kgdb I/O driver in the kernel
+   command line else the I/O driver will not be configured prior to
+   asking the kernel to use it to wait.
+   </para>
+   <para>
+   The kernel will stop and wait as early as the I/O driver and
+   architecture will allow when you use this option.  If you build the
+   kgdb I/O driver as a kernel module kgdbwait will not do anything.
+   </para>
+   </sect1>
+  <sect1 id="kgdboc">
+  <title>Kernel parameter: kgdboc</title>
+  <para>
+  The kgdboc driver was originally an abbreviation meant to stand for
+  "kgdb over console".  Kgdboc is designed to work with a single
+  serial port. It was meant to cover the circumstance
+  where you wanted to use a serial console as your primary console as
+  well as using it to perform kernel debugging.  Of course you can
+  also use kgdboc without assigning a console to the same port.
+  </para>
+  <sect2 id="UsingKgdboc">
+  <title>Using kgdboc</title>
+  <para>
+  You can configure kgdboc via sysfs or a module or kernel boot line
+  parameter depending on if you build with CONFIG_KGDBOC as a module
+  or built-in.
+  <orderedlist>
+  <listitem><para>From the module load or build-in</para>
+  <para><constant>kgdboc=&lt;tty-device&gt;,[baud]</constant></para>
+  <para>
+  The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant>
+  </para>
+  </listitem>
+  <listitem><para>From sysfs</para>
+  <para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para>
+  </listitem>
+  </orderedlist>
+  </para>
+  <para>
+  NOTE: Kgdboc does not support interrupting the target via the
+  gdb remote protocol.  You must manually send a sysrq-g unless you
+  have a proxy that splits console output to a terminal problem and
+  has a separate port for the debugger to connect to that sends the
+  sysrq-g for you.
+  </para>
+  <para>When using kgdboc with no debugger proxy, you can end up
+  connecting the debugger for one of two entry points.  If an
+  exception occurs after you have loaded kgdboc a message should print
+  on the console stating it is waiting for the debugger.  In case you
+  disconnect your terminal program and then connect the debugger in
+  its place.  If you want to interrupt the target system and forcibly
+  enter a debug session you have to issue a Sysrq sequence and then
+  type the letter <constant>g</constant>.  Then you disconnect the
+  terminal session and connect gdb.  Your options if you don't like
+  this are to hack gdb to send the sysrq-g for you as well as on the
+  initial connect, or to use a debugger proxy that allows an
+  unmodified gdb to do the debugging.
+  </para>
+  </sect2>
+  </sect1>
+  <sect1 id="kgdbcon">
+  <title>Kernel parameter: kgdbcon</title>
+  <para>
+  Kgdb supports using the gdb serial protocol to send console messages
+  to the debugger when the debugger is connected and running.  There
+  are two ways to activate this feature.
+  <orderedlist>
+  <listitem><para>Activate with the kernel command line option:</para>
+  <para><constant>kgdbcon</constant></para>
+  </listitem>
+  <listitem><para>Use sysfs before configuring an io driver</para>
+  <para>
+  <constant>echo 1 &gt; /sys/module/kgdb/parameters/kgdb_use_con</constant>
+  </para>
+  <para>
+  NOTE: If you do this after you configure the kgdb I/O driver, the
+  setting will not take effect until the next point the I/O is
+  reconfigured.
+  </para>
+  </listitem>
+  </orderedlist>
+  </para>
+  <para>
+  IMPORTANT NOTE: Using this option with kgdb over the console
+  (kgdboc) is not supported.
+  </para>
+  </sect1>
+  </chapter>
+  <chapter id="ConnectingGDB">
+  <title>Connecting gdb</title>
+    <para>
+    If you are using kgdboc, you need to have used kgdbwait as a boot
+    argument, issued a sysrq-g, or the system you are going to debug
+    has already taken an exception and is waiting for the debugger to
+    attach before you can connect gdb.
+    </para>
+    <para>
+    If you are not using different kgdb I/O driver other than kgdboc,
+    you should be able to connect and the target will automatically
+    respond.
+    </para>
+    <para>
+    Example (using a serial port):
+    </para>
+    <programlisting>
+    % gdb ./vmlinux
+    (gdb) set remotebaud 115200
+    (gdb) target remote /dev/ttyS0
+    </programlisting>
+    <para>
+    Example (kgdb to a terminal server on tcp port 2012):
+    </para>
+    <programlisting>
+    % gdb ./vmlinux
+    (gdb) target remote 192.168.2.2:2012
+    </programlisting>
+    <para>
+    Once connected, you can debug a kernel the way you would debug an
+    application program.
+    </para>
+    <para>
+    If you are having problems connecting or something is going
+    seriously wrong while debugging, it will most often be the case
+    that you want to enable gdb to be verbose about its target
+    communications.  You do this prior to issuing the <constant>target
+    remote</constant> command by typing in: <constant>set remote debug 1</constant>
+    </para>
+  </chapter>
+  <chapter id="KGDBTestSuite">
+    <title>kgdb Test Suite</title>
+    <para>
+    When kgdb is enabled in the kernel config you can also elect to
+    enable the config parameter KGDB_TESTS.  Turning this on will
+    enable a special kgdb I/O module which is designed to test the
+    kgdb internal functions.
+    </para>
+    <para>
+    The kgdb tests are mainly intended for developers to test the kgdb
+    internals as well as a tool for developing a new kgdb architecture
+    specific implementation.  These tests are not really for end users
+    of the Linux kernel.  The primary source of documentation would be
+    to look in the drivers/misc/kgdbts.c file.
+    </para>
+    <para>
+    The kgdb test suite can also be configured at compile time to run
+    the core set of tests by setting the kernel config parameter
+    KGDB_TESTS_ON_BOOT.  This particular option is aimed at automated
+    regression testing and does not require modifying the kernel boot
+    config arguments.  If this is turned on, the kgdb test suite can
+    be disabled by specifying "kgdbts=" as a kernel boot argument.
+    </para>
+  </chapter>
+  <chapter id="CommonBackEndReq">
+  <title>KGDB Internals</title>
+  <sect1 id="kgdbArchitecture">
+    <title>Architecture Specifics</title>
+      <para>
+      Kgdb is organized into three basic components:
+      <orderedlist>
+      <listitem><para>kgdb core</para>
+      <para>
+      The kgdb core is found in kernel/kgdb.c.  It contains:
+      <itemizedlist>
+      <listitem><para>All the logic to implement the gdb serial protocol</para></listitem>
+      <listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem>
+      <listitem><para>The API to talk to the kgdb I/O drivers</para></listitem>
+      <listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem>
+      <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
+      <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
+      </itemizedlist>
+      </para>
+      </listitem>
+      <listitem><para>kgdb arch specific implementation</para>
+      <para>
+      This implementation is generally found in arch/*/kernel/kgdb.c.
+      As an example, arch/x86/kernel/kgdb.c contains the specifics to
+      implement HW breakpoint as well as the initialization to
+      dynamically register and unregister for the trap handlers on
+      this architecture.  The arch specific portion implements:
+      <itemizedlist>
+      <listitem><para>contains an arch specific trap catcher which
+      invokes kgdb_handle_exception() to start kgdb about doing its
+      work</para></listitem>
+      <listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem>
+      <listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
+      <listitem><para>Any special exception handling and cleanup</para></listitem>
+      <listitem><para>NMI exception handling and cleanup</para></listitem>
+      <listitem><para>(optional)HW breakpoints</para></listitem>
+      </itemizedlist>
+      </para>
+      </listitem>
+      <listitem><para>kgdb I/O driver</para>
+      <para>
+      Each kgdb I/O driver has to provide an implemenation for the following:
+      <itemizedlist>
+      <listitem><para>configuration via builtin or module</para></listitem>
+      <listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem>
+      <listitem><para>read and write character interface</para></listitem>
+      <listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem>
+      <listitem><para>(optional) Early debug methodology</para></listitem>
+      </itemizedlist>
+      Any given kgdb I/O driver has to operate very closely with the
+      hardware and must do it in such a way that does not enable
+      interrupts or change other parts of the system context without
+      completely restoring them. The kgdb core will repeatedly "poll"
+      a kgdb I/O driver for characters when it needs input.  The I/O
+      driver is expected to return immediately if there is no data
+      available.  Doing so allows for the future possibility to touch
+      watch dog hardware in such a way as to have a target system not
+      reset when these are enabled.
+      </para>
+      </listitem>
+      </orderedlist>
+      </para>
+      <para>
+      If you are intent on adding kgdb architecture specific support
+      for a new architecture, the architecture should define
+      <constant>HAVE_ARCH_KGDB</constant> in the architecture specific
+      Kconfig file.  This will enable kgdb for the architecture, and
+      at that point you must create an architecture specific kgdb
+      implementation.
+      </para>
+      <para>
+      There are a few flags which must be set on every architecture in
+      their &lt;asm/kgdb.h&gt; file.  These are:
+      <itemizedlist>
+        <listitem>
+          <para>
+          NUMREGBYTES: The size in bytes of all of the registers, so
+          that we can ensure they will all fit into a packet.
+          </para>
+          <para>
+          BUFMAX: The size in bytes of the buffer GDB will read into.
+          This must be larger than NUMREGBYTES.
+          </para>
+          <para>
+          CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
+          flush_cache_range or flush_icache_range.  On some architectures,
+          these functions may not be safe to call on SMP since we keep other
+          CPUs in a holding pattern.
+          </para>
+        </listitem>
+      </itemizedlist>
+      </para>
+      <para>
+      There are also the following functions for the common backend,
+      found in kernel/kgdb.c, that must be supplied by the
+      architecture-specific backend unless marked as (optional), in
+      which case a default function maybe used if the architecture
+      does not need to provide a specific implementation.
+      </para>
+!Iinclude/linux/kgdb.h
+  </sect1>
+  <sect1 id="kgdbocDesign">
+  <title>kgdboc internals</title>
+  <para>
+  The kgdboc driver is actually a very thin driver that relies on the
+  underlying low level to the hardware driver having "polling hooks"
+  which the to which the tty driver is attached.  In the initial
+  implementation of kgdboc it the serial_core was changed to expose a
+  low level uart hook for doing polled mode reading and writing of a
+  single character while in an atomic context.  When kgdb makes an I/O
+  request to the debugger, kgdboc invokes a call back in the serial
+  core which in turn uses the call back in the uart driver.  It is
+  certainly possible to extend kgdboc to work with non-uart based
+  consoles in the future.
+  </para>
+  <para>
+  When using kgdboc with a uart, the uart driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
+#ifdef CONFIG_CONSOLE_POLL
+        .poll_get_char = serial8250_get_poll_char,
+        .poll_put_char = serial8250_put_poll_char,
+#endif
+  </programlisting>
+  Any implementation specifics around creating a polling driver use the
+  <constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above.
+  Keep in mind that polling hooks have to be implemented in such a way
+  that they can be called from an atomic context and have to restore
+  the state of the uart chip on return such that the system can return
+  to normal when the debugger detaches.  You need to be very careful
+  with any kind of lock you consider, because failing here is most
+  going to mean pressing the reset button.
+  </para>
+  </sect1>
+  </chapter>
+  <chapter id="credits">
+     <title>Credits</title>
+        <para>
+                The following people have contributed to this document:
+                <orderedlist>
+                        <listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem>
+                        <listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem>
+                </orderedlist>
+                In March 2008 this document was completely rewritten by:
+                <itemizedlist>
+                <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem>
+                </itemizedlist>
+        </para>
+  </chapter>
+</book>
+
diff --git a/Documentation/DocBook/mac80211.tmpl b/Documentation/DocBook/mac80211.tmpl
new file mode 100644
index 000000000000..b651e0a4b1c0
--- /dev/null
+++ b/Documentation/DocBook/mac80211.tmpl
@@ -0,0 +1,335 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!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="mac80211-developers-guide">
+  <bookinfo>
+    <title>The mac80211 subsystem for kernel developers</title>
+
+    <authorgroup>
+      <author>
+        <firstname>Johannes</firstname>
+        <surname>Berg</surname>
+        <affiliation>
+          <address><email>johannes@sipsolutions.net</email></address>
+        </affiliation>
+      </author>
+    </authorgroup>
+
+    <copyright>
+      <year>2007</year>
+      <year>2008</year>
+      <holder>Johannes Berg</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        This documentation is free software; you can redistribute
+        it and/or modify it under the terms of the GNU General Public
+        License version 2 as published by the Free Software Foundation.
+      </para>
+
+      <para>
+        This documentation 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 documentation; 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.
+      </para>
+    </legalnotice>
+
+    <abstract>
+!Pinclude/net/mac80211.h Introduction
+!Pinclude/net/mac80211.h Warning
+    </abstract>
+  </bookinfo>
+
+  <toc></toc>
+
+<!--
+Generally, this document shall be ordered by increasing complexity.
+It is important to note that readers should be able to read only
+the first few sections to get a working driver and only advanced
+usage should require reading the full document.
+-->
+
+  <part>
+    <title>The basic mac80211 driver interface</title>
+    <partintro>
+      <para>
+        You should read and understand the information contained
+        within this part of the book while implementing a driver.
+        In some chapters, advanced usage is noted, that may be
+        skipped at first.
+      </para>
+      <para>
+        This part of the book only covers station and monitor mode
+        functionality, additional information required to implement
+        the other modes is covered in the second part of the book.
+      </para>
+    </partintro>
+
+    <chapter id="basics">
+      <title>Basic hardware handling</title>
+      <para>TBD</para>
+      <para>
+        This chapter shall contain information on getting a hw
+        struct allocated and registered with mac80211.
+      </para>
+      <para>
+        Since it is required to allocate rates/modes before registering
+        a hw struct, this chapter shall also contain information on setting
+        up the rate/mode structs.
+      </para>
+      <para>
+        Additionally, some discussion about the callbacks and
+        the general programming model should be in here, including
+        the definition of ieee80211_ops which will be referred to
+        a lot.
+      </para>
+      <para>
+        Finally, a discussion of hardware capabilities should be done
+        with references to other parts of the book.
+      </para>
+<!-- intentionally multiple !F lines to get proper order -->
+!Finclude/net/mac80211.h ieee80211_hw
+!Finclude/net/mac80211.h ieee80211_hw_flags
+!Finclude/net/mac80211.h SET_IEEE80211_DEV
+!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
+!Finclude/net/mac80211.h ieee80211_ops
+!Finclude/net/mac80211.h ieee80211_alloc_hw
+!Finclude/net/mac80211.h ieee80211_register_hw
+!Finclude/net/mac80211.h ieee80211_get_tx_led_name
+!Finclude/net/mac80211.h ieee80211_get_rx_led_name
+!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
+!Finclude/net/mac80211.h ieee80211_get_radio_led_name
+!Finclude/net/mac80211.h ieee80211_unregister_hw
+!Finclude/net/mac80211.h ieee80211_free_hw
+    </chapter>
+
+    <chapter id="phy-handling">
+      <title>PHY configuration</title>
+      <para>TBD</para>
+      <para>
+        This chapter should describe PHY handling including
+        start/stop callbacks and the various structures used.
+      </para>
+!Finclude/net/mac80211.h ieee80211_conf
+!Finclude/net/mac80211.h ieee80211_conf_flags
+    </chapter>
+
+    <chapter id="iface-handling">
+      <title>Virtual interfaces</title>
+      <para>TBD</para>
+      <para>
+        This chapter should describe virtual interface basics
+        that are relevant to the driver (VLANs, MGMT etc are not.)
+        It should explain the use of the add_iface/remove_iface
+        callbacks as well as the interface configuration callbacks.
+      </para>
+      <para>Things related to AP mode should be discussed there.</para>
+      <para>
+        Things related to supporting multiple interfaces should be
+        in the appropriate chapter, a BIG FAT note should be here about
+        this though and the recommendation to allow only a single
+        interface in STA mode at first!
+      </para>
+!Finclude/net/mac80211.h ieee80211_if_types
+!Finclude/net/mac80211.h ieee80211_if_init_conf
+!Finclude/net/mac80211.h ieee80211_if_conf
+    </chapter>
+
+    <chapter id="rx-tx">
+      <title>Receive and transmit processing</title>
+      <sect1>
+        <title>what should be here</title>
+        <para>TBD</para>
+        <para>
+          This should describe the receive and transmit
+          paths in mac80211/the drivers as well as
+          transmit status handling.
+        </para>
+      </sect1>
+      <sect1>
+        <title>Frame format</title>
+!Pinclude/net/mac80211.h Frame format
+      </sect1>
+      <sect1>
+        <title>Alignment issues</title>
+        <para>TBD</para>
+      </sect1>
+      <sect1>
+        <title>Calling into mac80211 from interrupts</title>
+!Pinclude/net/mac80211.h Calling mac80211 from interrupts
+      </sect1>
+      <sect1>
+        <title>functions/definitions</title>
+!Finclude/net/mac80211.h ieee80211_rx_status
+!Finclude/net/mac80211.h mac80211_rx_flags
+!Finclude/net/mac80211.h ieee80211_tx_control
+!Finclude/net/mac80211.h ieee80211_tx_status_flags
+!Finclude/net/mac80211.h ieee80211_rx
+!Finclude/net/mac80211.h ieee80211_rx_irqsafe
+!Finclude/net/mac80211.h ieee80211_tx_status
+!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
+!Finclude/net/mac80211.h ieee80211_rts_get
+!Finclude/net/mac80211.h ieee80211_rts_duration
+!Finclude/net/mac80211.h ieee80211_ctstoself_get
+!Finclude/net/mac80211.h ieee80211_ctstoself_duration
+!Finclude/net/mac80211.h ieee80211_generic_frame_duration
+!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
+!Finclude/net/mac80211.h ieee80211_get_hdrlen
+!Finclude/net/mac80211.h ieee80211_wake_queue
+!Finclude/net/mac80211.h ieee80211_stop_queue
+!Finclude/net/mac80211.h ieee80211_start_queues
+!Finclude/net/mac80211.h ieee80211_stop_queues
+!Finclude/net/mac80211.h ieee80211_wake_queues
+      </sect1>
+    </chapter>
+
+    <chapter id="filters">
+      <title>Frame filtering</title>
+!Pinclude/net/mac80211.h Frame filtering
+!Finclude/net/mac80211.h ieee80211_filter_flags
+    </chapter>
+  </part>
+
+  <part id="advanced">
+    <title>Advanced driver interface</title>
+    <partintro>
+      <para>
+       Information contained within this part of the book is
+       of interest only for advanced interaction of mac80211
+       with drivers to exploit more hardware capabilities and
+       improve performance.
+      </para>
+    </partintro>
+
+    <chapter id="hardware-crypto-offload">
+      <title>Hardware crypto acceleration</title>
+!Pinclude/net/mac80211.h Hardware crypto acceleration
+<!-- intentionally multiple !F lines to get proper order -->
+!Finclude/net/mac80211.h set_key_cmd
+!Finclude/net/mac80211.h ieee80211_key_conf
+!Finclude/net/mac80211.h ieee80211_key_alg
+!Finclude/net/mac80211.h ieee80211_key_flags
+    </chapter>
+
+    <chapter id="qos">
+      <title>Multiple queues and QoS support</title>
+      <para>TBD</para>
+!Finclude/net/mac80211.h ieee80211_tx_queue_params
+!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
+!Finclude/net/mac80211.h ieee80211_tx_queue
+    </chapter>
+
+    <chapter id="AP">
+      <title>Access point mode support</title>
+      <para>TBD</para>
+      <para>Some parts of the if_conf should be discussed here instead</para>
+      <para>
+        Insert notes about VLAN interfaces with hw crypto here or
+        in the hw crypto chapter.
+      </para>
+!Finclude/net/mac80211.h ieee80211_get_buffered_bc
+!Finclude/net/mac80211.h ieee80211_beacon_get
+    </chapter>
+
+    <chapter id="multi-iface">
+      <title>Supporting multiple virtual interfaces</title>
+      <para>TBD</para>
+      <para>
+        Note: WDS with identical MAC address should almost always be OK
+      </para>
+      <para>
+        Insert notes about having multiple virtual interfaces with
+        different MAC addresses here, note which configurations are
+        supported by mac80211, add notes about supporting hw crypto
+        with it.
+      </para>
+    </chapter>
+
+    <chapter id="hardware-scan-offload">
+      <title>Hardware scan offload</title>
+      <para>TBD</para>
+!Finclude/net/mac80211.h ieee80211_scan_completed
+    </chapter>
+  </part>
+
+  <part id="rate-control">
+    <title>Rate control interface</title>
+    <partintro>
+      <para>TBD</para>
+      <para>
+       This part of the book describes the rate control algorithm
+       interface and how it relates to mac80211 and drivers.
+      </para>
+    </partintro>
+    <chapter id="dummy">
+      <title>dummy chapter</title>
+      <para>TBD</para>
+    </chapter>
+  </part>
+
+  <part id="internal">
+    <title>Internals</title>
+    <partintro>
+      <para>TBD</para>
+      <para>
+       This part of the book describes mac80211 internals.
+      </para>
+    </partintro>
+
+    <chapter id="key-handling">
+      <title>Key handling</title>
+      <sect1>
+        <title>Key handling basics</title>
+!Pnet/mac80211/key.c Key handling basics
+      </sect1>
+      <sect1>
+        <title>MORE TBD</title>
+        <para>TBD</para>
+      </sect1>
+    </chapter>
+
+    <chapter id="rx-processing">
+      <title>Receive processing</title>
+      <para>TBD</para>
+    </chapter>
+
+    <chapter id="tx-processing">
+      <title>Transmit processing</title>
+      <para>TBD</para>
+    </chapter>
+
+    <chapter id="sta-info">
+      <title>Station info handling</title>
+      <sect1>
+        <title>Programming information</title>
+!Fnet/mac80211/sta_info.h sta_info
+!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
+      </sect1>
+      <sect1>
+        <title>STA information lifetime rules</title>
+!Pnet/mac80211/sta_info.c STA information lifetime rules
+      </sect1>
+    </chapter>
+
+    <chapter id="synchronisation">
+      <title>Synchronisation</title>
+      <para>TBD</para>
+      <para>Locking, lots of RCU</para>
+    </chapter>
+  </part>
+</book>
diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl
index b9e143e28c64..54eb26b57372 100644
--- a/Documentation/DocBook/rapidio.tmpl
+++ b/Documentation/DocBook/rapidio.tmpl
@@ -133,7 +133,6 @@
 !Idrivers/rapidio/rio-sysfs.c
      </sect1>
      <sect1 id="PPC32_support"><title>PPC32 support</title>
-!Iarch/powerpc/kernel/rio.c
 !Earch/powerpc/sysdev/fsl_rio.c
 !Iarch/powerpc/sysdev/fsl_rio.c
      </sect1>
diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index d4188d4ff535..eeff19ca831b 100644
--- a/Documentation/DocBook/writing_usb_driver.tmpl
+++ b/Documentation/DocBook/writing_usb_driver.tmpl
@@ -100,8 +100,8 @@
       useful documents, at the USB home page (see Resources). An excellent
       introduction to the Linux USB subsystem can be found at the USB Working
       Devices List (see Resources). It explains how the Linux USB subsystem is
-      structured and introduces the reader to the concept of USB urbs, which
-      are essential to USB drivers.
+      structured and introduces the reader to the concept of USB urbs
+      (USB Request Blocks), which are essential to USB drivers.
   </para>
   <para>
       The first thing a Linux USB driver needs to do is register itself with
@@ -162,8 +162,8 @@ static int __init usb_skel_init(void)
 module_init(usb_skel_init);
   </programlisting>
   <para>
-      When the driver is unloaded from the system, it needs to unregister
-      itself with the USB subsystem. This is done with the usb_unregister
+      When the driver is unloaded from the system, it needs to deregister
+      itself with the USB subsystem. This is done with the usb_deregister
       function:
   </para>
   <programlisting>
@@ -232,7 +232,7 @@ static int skel_probe(struct usb_interface *interface,
      were passed to the USB subsystem will be called from a user program trying
      to talk to the device. The first function called will be open, as the
      program tries to open the device for I/O. We increment our private usage
-     count and save off a pointer to our internal structure in the file
+     count and save a pointer to our internal structure in the file
      structure. This is done so that future calls to file operations will
      enable the driver to determine which device the user is addressing.  All
      of this is done with the following code:
@@ -252,8 +252,8 @@ file->private_data = dev;
      send to the device based on the size of the write urb it has created (this
      size depends on the size of the bulk out end point that the device has).
      Then it copies the data from user space to kernel space, points the urb to
-     the data and submits the urb to the USB subsystem.  This can be shown in
-     he following code:
+     the data and submits the urb to the USB subsystem.  This can be seen in
+     the following code:
   </para>
   <programlisting>
 /* we can only write as much as 1 urb will hold */
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 54835610b3d6..0291ade44c17 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -249,9 +249,11 @@ process is as follows:
     release a new -rc kernel every week.
   - Process continues until the kernel is considered "ready", the
     process should last around 6 weeks.
-  - A list of known regressions present in each -rc release is
-    tracked at the following URI:
-    http://kernelnewbies.org/known_regressions
+  - Known regressions in each release are periodically posted to the 
+    linux-kernel mailing list.  The goal is to reduce the length of 
+    that list to zero before declaring the kernel to be "ready," but, in
+    the real world, a small number of regressions often remain at 
+    release time.
 
 It is worth mentioning what Andrew Morton wrote on the linux-kernel
 mailing list about kernel releases:
@@ -261,7 +263,7 @@ mailing list about kernel releases:
 
 2.6.x.y -stable kernel tree
 ---------------------------
-Kernels with 4 digit versions are -stable kernels. They contain
+Kernels with 4-part versions are -stable kernels. They contain
 relatively small and critical fixes for security problems or significant
 regressions discovered in a given 2.6.x kernel.
 
@@ -273,7 +275,10 @@ If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
 kernel is the current stable kernel.
 
 2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
-released almost every other week.
+released as needs dictate.  The normal release period is approximately 
+two weeks, but it can be longer if there are no pressing problems.  A
+security-related problem, instead, can cause a release to happen almost
+instantly.
 
 The file Documentation/stable_kernel_rules.txt in the kernel tree
 documents what kinds of changes are acceptable for the -stable tree, and
@@ -298,7 +303,9 @@ a while Andrew or the subsystem maintainer pushes it on to Linus for
 inclusion in mainline.
 
 It is heavily encouraged that all new patches get tested in the -mm tree
-before they are sent to Linus for inclusion in the main kernel tree.
+before they are sent to Linus for inclusion in the main kernel tree.  Code
+which does not make an appearance in -mm before the opening of the merge
+window will prove hard to merge into the mainline.
 
 These kernels are not appropriate for use on systems that are supposed
 to be stable and they are more risky to run than any of the other
@@ -354,11 +361,12 @@ Here is a list of some of the different kernel trees available:
     - SCSI, James Bottomley <James.Bottomley@SteelEye.com>
         git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
 
+    - x86, Ingo Molnar <mingo@elte.hu>
+        git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
+
   quilt trees:
-    - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
+    - USB, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
         kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
-    - x86-64, partly i386, Andi Kleen <ak@suse.de>
-        ftp.firstfloor.org:/pub/ak/x86_64/quilt/
 
   Other kernel trees can be found listed at http://git.kernel.org/ and in
   the MAINTAINERS file.
@@ -392,8 +400,8 @@ 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
+        http://lists.linux-foundation.org/mailman/listinfo/bugme-new
+        http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
 
 
 
diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
new file mode 100644
index 000000000000..49f43946c6b6
--- /dev/null
+++ b/Documentation/PCI/00-INDEX
@@ -0,0 +1,12 @@
+00-INDEX
+        - this file
+PCI-DMA-mapping.txt
+        - info for PCI drivers using DMA portably across all platforms
+PCIEBUS-HOWTO.txt
+        - a guide describing the PCI Express Port Bus driver
+pci-error-recovery.txt
+        - info on PCI error recovery
+pci.txt
+        - info on the PCI subsystem for device driver authors
+pcieaer-howto.txt
+        - the PCI Express Advanced Error Reporting Driver Guide HOWTO
diff --git a/Documentation/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt
index c93f42a74d7e..9a07e38631b0 100644
--- a/Documentation/PCIEBUS-HOWTO.txt
+++ b/Documentation/PCI/PCIEBUS-HOWTO.txt
@@ -56,9 +56,9 @@ advantages of using the PCI Express Port Bus driver are listed below:
 
         - Allow service drivers implemented in an independent
           staged approach.
-        
+
         - Allow one service driver to run on multiple PCI-PCI Bridge
-          Port devices. 
+          Port devices.
 
         - Manage and distribute resources of a PCI-PCI Bridge Port
           device to requested service drivers.
@@ -82,7 +82,7 @@ Model requires some minimal changes on existing service drivers that
 imposes no impact on the functionality of existing service drivers.
 
 A service driver is required to use the two APIs shown below to
-register its service with the PCI Express Port Bus driver (see 
+register its service with the PCI Express Port Bus driver (see
 section 5.2.1 & 5.2.2). It is important that a service driver
 initializes the pcie_port_service_driver data structure, included in
 header file /include/linux/pcieport_if.h, before calling these APIs.
@@ -137,7 +137,7 @@ driver.
 static int __init aerdrv_service_init(void)
 {
         int retval = 0;
-        
+
         retval = pcie_port_service_register(&root_aerdrv);
         if (!retval) {
                 /*
@@ -147,7 +147,7 @@ static int __init aerdrv_service_init(void)
         return retval;
 }
 
-static void __exit aerdrv_service_exit(void) 
+static void __exit aerdrv_service_exit(void)
 {
         pcie_port_service_unregister(&root_aerdrv);
 }
@@ -175,7 +175,7 @@ same physical Root Port. Both service drivers call pci_enable_msi to
 request MSI based interrupts. A service driver may not know whether
 any other service drivers have run on this Root Port. If either one
 of them calls pci_disable_msi, it puts the other service driver
-in a wrong interrupt mode. 
+in a wrong interrupt mode.
 
 To avoid this situation all service drivers are not permitted to
 switch interrupt mode on its device. The PCI Express Port Bus driver
diff --git a/Documentation/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt
index 6650af432523..6650af432523 100644
--- a/Documentation/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
diff --git a/Documentation/pci.txt b/Documentation/PCI/pci.txt
index d2c2e6e2b224..8d4dc6250c58 100644
--- a/Documentation/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -119,7 +119,7 @@ initialization with a pointer to a structure describing the driver
                         the power state of a device before reboot.
                         e.g. drivers/net/e100.c.
 
-        err_handler     See Documentation/pci-error-recovery.txt
+        err_handler     See Documentation/PCI/pci-error-recovery.txt
 
 
 The ID table is an array of struct pci_device_id entries ending with an
diff --git a/Documentation/pcieaer-howto.txt b/Documentation/PCI/pcieaer-howto.txt
index d5da86170106..16c251230c82 100644
--- a/Documentation/pcieaer-howto.txt
+++ b/Documentation/PCI/pcieaer-howto.txt
@@ -13,7 +13,7 @@ Reporting (AER) driver and provides information on how to use it, as
 well as how to enable the drivers of endpoint devices to conform with
 PCI Express AER driver.
 
-1.2 Copyright © Intel Corporation 2006.
+1.2 Copyright © Intel Corporation 2006.
 
 1.3 What is the PCI Express AER Driver?
 
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 08a1ed1cb5d8..118ca6e9404f 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -183,7 +183,7 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS
 copy the maintainer when you change their code.
 
 For small patches you may want to CC the Trivial Patch Monkey
-trivial@kernel.org managed by Adrian Bunk; which collects "trivial"
+trivial@kernel.org managed by Jesper Juhl; which collects "trivial"
 patches. Trivial patches must qualify for one of the following rules:
  Spelling fixes in documentation
  Spelling fixes which could break grep(1)
@@ -196,7 +196,7 @@ patches. Trivial patches must qualify for one of the following rules:
  since people copy, as long as it's trivial)
  Any fix by the author/maintainer of the file (ie. patch monkey
  in re-transmission mode)
-URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
+URL: <http://www.kernel.org/pub/linux/kernel/people/juhl/trivial/>
 
 
 
@@ -327,8 +327,54 @@ Some people also put extra tags at the end.  They'll just be ignored for
 now, but you can do this to mark internal company procedures or just
 point out some special detail about the sign-off. 
 
+If you are a subsystem or branch maintainer, sometimes you need to slightly
+modify patches you receive in order to merge them, because the code is not
+exactly the same in your tree and the submitters'. If you stick strictly to
+rule (c), you should ask the submitter to rediff, but this is a totally
+counter-productive waste of time and energy. Rule (b) allows you to adjust
+the code, but then it is very impolite to change one submitter's code and
+make him endorse your bugs. To solve this problem, it is recommended that
+you add a line between the last Signed-off-by header and yours, indicating
+the nature of your changes. While there is nothing mandatory about this, it
+seems like prepending the description with your mail and/or name, all
+enclosed in square brackets, is noticeable enough to make it obvious that
+you are responsible for last-minute changes. Example :
 
-13) When to use Acked-by:
+        Signed-off-by: Random J Developer <random@developer.example.org>
+        [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
+        Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
+
+This practise is particularly helpful if you maintain a stable branch and
+want at the same time to credit the author, track changes, merge the fix,
+and protect the submitter from complaints. Note that under no circumstances
+can you change the author's identity (the From header), as it is the one
+which appears in the changelog.
+
+Special note to back-porters: It seems to be a common and useful practise
+to insert an indication of the origin of a patch at the top of the commit
+message (just after the subject line) to facilitate tracking. For instance,
+here's what we see in 2.6-stable :
+
+    Date:   Tue May 13 19:10:30 2008 +0000
+
+        SCSI: libiscsi regression in 2.6.25: fix nop timer handling
+
+        commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
+
+And here's what appears in 2.4 :
+
+    Date:   Tue May 13 22:12:27 2008 +0200
+
+        wireless, airo: waitbusy() won't delay
+
+        [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
+
+Whatever the format, this information provides a valuable help to people
+tracking your trees, and to people trying to trouble-shoot bugs in your
+tree.
+
+
+13) When to use Acked-by: and Cc:
 
 The Signed-off-by: tag indicates that the signer was involved in the
 development of the patch, or that he/she was in the patch's delivery path.
@@ -349,11 +395,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch.
 For example, if a patch affects multiple subsystems and has an Acked-by: from
 one subsystem maintainer then this usually indicates acknowledgement of just
 the part which affects that maintainer's code.  Judgement should be used here.
- When in doubt people should refer to the original discussion in the mailing
+When in doubt people should refer to the original discussion in the mailing
 list archives.
 
+If a person has had the opportunity to comment on a patch, but has not
+provided such comments, you may optionally add a "Cc:" tag to the patch.
+This is the only tag which might be added without an explicit action by the
+person it names.  This tag documents that potentially interested parties
+have been included in the discussion
+
+
+14) Using Test-by: and Reviewed-by:
+
+A Tested-by: tag indicates that the patch has been successfully tested (in
+some environment) by the person named.  This tag informs maintainers that
+some testing has been performed, provides a means to locate testers for
+future patches, and ensures credit for the testers.
+
+Reviewed-by:, instead, indicates that the patch has been reviewed and found
+acceptable according to the Reviewer's Statement:
+
+        Reviewer's statement of oversight
+
+        By offering my Reviewed-by: tag, I state that:
+
+         (a) I have carried out a technical review of this patch to
+             evaluate its appropriateness and readiness for inclusion into
+             the mainline kernel.
+
+         (b) Any problems, concerns, or questions relating to the patch
+             have been communicated back to the submitter.  I am satisfied
+             with the submitter's response to my comments.
+
+         (c) While there may be things that could be improved with this
+             submission, I believe that it is, at this time, (1) a
+             worthwhile modification to the kernel, and (2) free of known
+             issues which would argue against its inclusion.
+
+         (d) While I have reviewed the patch and believe it to be sound, I
+             do not (unless explicitly stated elsewhere) make any
+             warranties or guarantees that it will achieve its stated
+             purpose or function properly in any given situation.
+
+A Reviewed-by tag is a statement of opinion that the patch is an
+appropriate modification of the kernel without any remaining serious
+technical issues.  Any interested reviewer (who has done the work) can
+offer a Reviewed-by tag for a patch.  This tag serves to give credit to
+reviewers and to inform maintainers of the degree of review which has been
+done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
+understand the subject area and to perform thorough reviews, will normally
+increase the liklihood of your patch getting into the kernel.
+
 
-14) The canonical patch format
+15) The canonical patch format
 
 The canonical patch subject line is:
 
@@ -512,7 +606,7 @@ They provide type safety, have no length limitations, no formatting
 limitations, and under gcc they are as cheap as macros.
 
 Macros should only be used for cases where a static inline is clearly
-suboptimal [there a few, isolated cases of this in fast paths],
+suboptimal [there are a few, isolated cases of this in fast paths],
 or where it is impossible to use a static inline function [such as
 string-izing].
 
diff --git a/Documentation/arm/Samsung-S3C24XX/NAND.txt b/Documentation/arm/Samsung-S3C24XX/NAND.txt
new file mode 100644
index 000000000000..bc478a3409b8
--- /dev/null
+++ b/Documentation/arm/Samsung-S3C24XX/NAND.txt
@@ -0,0 +1,30 @@
+                        S3C24XX NAND Support
+                        ====================
+
+Introduction
+------------
+
+Small Page NAND
+---------------
+
+The driver uses a 512 byte (1 page) ECC code for this setup. The
+ECC code is not directly compatible with the default kernel ECC
+code, so the driver enforces its own OOB layout and ECC parameters
+
+Large Page NAND
+---------------
+
+The driver is capable of handling NAND flash with a 2KiB page
+size, with support for hardware ECC generation and correction.
+
+Unlike the 512byte page mode, the driver generates ECC data for
+each 256 byte block in an 2KiB page. This means that more than
+one error in a page can be rectified. It also means that the
+OOB layout remains the default kernel layout for these flashes.
+
+
+Document Author
+---------------
+
+Ben Dooks, Copyright 2007 Simtec Electronics
+
diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt
index c31b76fa66c4..d04e1e30c47f 100644
--- a/Documentation/arm/Samsung-S3C24XX/Overview.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt
@@ -156,6 +156,8 @@ NAND
   controller. If there are any problems the latest linux-mtd
   code can be found from http://www.linux-mtd.infradead.org/
 
+  For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
+
 
 Serial
 ------
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 93f223b9723f..4dbb8be1c991 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -1097,7 +1097,7 @@ lock themselves, if required. Drivers that explicitly used the
 io_request_lock for serialization need to be modified accordingly.
 Usually it's as easy as adding a global lock:
 
-        static spinlock_t my_driver_lock = SPIN_LOCK_UNLOCKED;
+        static DEFINE_SPINLOCK(my_driver_lock);
 
 and passing the address to that lock to blk_init_queue().
 
diff --git a/Documentation/braille-console.txt b/Documentation/braille-console.txt
new file mode 100644
index 000000000000..000b0fbdc105
--- /dev/null
+++ b/Documentation/braille-console.txt
@@ -0,0 +1,34 @@
+                       Linux Braille Console
+
+To get early boot messages on a braille device (before userspace screen
+readers can start), you first need to compile the support for the usual serial
+console (see serial-console.txt), and for braille device (in Device Drivers -
+Accessibility).
+
+Then you need to specify a console=brl, option on the kernel command line, the
+format is:
+
+        console=brl,serial_options...
+
+where serial_options... are the same as described in serial-console.txt
+
+So for instance you can use console=brl,ttyS0 if the braille device is connected
+to the first serial port, and console=brl,ttyS0,115200 to override the baud rate
+to 115200, etc.
+
+By default, the braille device will just show the last kernel message (console
+mode).  To review previous messages, press the Insert key to switch to the VT
+review mode.  In review mode, the arrow keys permit to browse in the VT content,
+page up/down keys go at the top/bottom of the screen, and the home key goes back
+to the cursor, hence providing very basic screen reviewing facility.
+
+Sound feedback can be obtained by adding the braille_console.sound=1 kernel
+parameter.
+
+For simplicity, only one braille console can be enabled, other uses of
+console=brl,... will be discarded.  Also note that it does not interfere with
+the console selection mecanism described in serial-console.txt
+
+For now, only the VisioBraille device is supported.
+
+Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index e65736c6b8bc..63e59b8847c5 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt
@@ -21,6 +21,11 @@ This driver is known to work with the following cards:
         * SA E200
         * SA E200i
         * SA E500
+        * SA P212
+        * SA P410
+        * SA P410i
+        * SA P411
+        * SA P812
 
 Detecting drive failures:
 -------------------------
diff --git a/Documentation/cdrom/cdrom-standard.tex b/Documentation/cdrom/cdrom-standard.tex
index c713aeb020c4..c06233fe52ac 100644
--- a/Documentation/cdrom/cdrom-standard.tex
+++ b/Documentation/cdrom/cdrom-standard.tex
@@ -777,7 +777,7 @@ Note that a driver must have one static structure, $<device>_dops$, while
 it may have as many structures $<device>_info$ as there are minor devices
 active. $Register_cdrom()$ builds a linked list from these. 
 
-\subsection{$Int\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
+\subsection{$Void\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
 
 Unregistering device $cdi$ with minor number $MINOR(cdi\to dev)$ removes
 the minor device from the list. If it was the last registered minor for
diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt
index 31d12e21ff8a..824fc0274471 100644
--- a/Documentation/cgroups.txt
+++ b/Documentation/cgroups.txt
@@ -310,8 +310,8 @@ and then start a subshell 'sh' in that cgroup:
   cd /dev/cgroup
   mkdir Charlie
   cd Charlie
-  /bin/echo 2-3 > cpus
-  /bin/echo 1 > mems
+  /bin/echo 2-3 > cpuset.cpus
+  /bin/echo 1 > cpuset.mems
   /bin/echo $$ > tasks
   sh
   # The subshell 'sh' is now running in cgroup Charlie
@@ -500,8 +500,7 @@ post-attachment activity that requires memory allocations or blocking.
 
 void fork(struct cgroup_subsy *ss, struct task_struct *task)
 
-Called when a task is forked into a cgroup. Also called during
-registration for all existing tasks.
+Called when a task is forked into a cgroup.
 
 void exit(struct cgroup_subsys *ss, struct task_struct *task)
 
diff --git a/Documentation/cli-sti-removal.txt b/Documentation/cli-sti-removal.txt
index 0223c9d20331..60932b02fcb3 100644
--- a/Documentation/cli-sti-removal.txt
+++ b/Documentation/cli-sti-removal.txt
@@ -43,7 +43,7 @@ would execute while the cli()-ed section is executing.
 
 but from now on a more direct method of locking has to be used:
 
-        spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
+        DEFINE_SPINLOCK(driver_lock);
         struct driver_data;
 
         irq_handler (...)
diff --git a/Documentation/controllers/devices.txt b/Documentation/controllers/devices.txt
new file mode 100644
index 000000000000..4dcea42432c2
--- /dev/null
+++ b/Documentation/controllers/devices.txt
@@ -0,0 +1,48 @@
+Device Whitelist Controller
+
+1. Description:
+
+Implement a cgroup to track and enforce open and mknod restrictions
+on device files.  A device cgroup associates a device access
+whitelist with each cgroup.  A whitelist entry has 4 fields.
+'type' is a (all), c (char), or b (block).  'all' means it applies
+to all types and all major and minor numbers.  Major and minor are
+either an integer or * for all.  Access is a composition of r
+(read), w (write), and m (mknod).
+
+The root device cgroup starts with rwm to 'all'.  A child device
+cgroup gets a copy of the parent.  Administrators can then remove
+devices from the whitelist or add new entries.  A child cgroup can
+never receive a device access which is denied its parent.  However
+when a device access is removed from a parent it will not also be
+removed from the child(ren).
+
+2. User Interface
+
+An entry is added using devices.allow, and removed using
+devices.deny.  For instance
+
+        echo 'c 1:3 mr' > /cgroups/1/devices.allow
+
+allows cgroup 1 to read and mknod the device usually known as
+/dev/null.  Doing
+
+        echo a > /cgroups/1/devices.deny
+
+will remove the default 'a *:* mrw' entry.
+
+3. Security
+
+Any task can move itself between cgroups.  This clearly won't
+suffice, but we can decide the best way to adequately restrict
+movement as people get some experience with this.  We may just want
+to require CAP_SYS_ADMIN, which at least is a separate bit from
+CAP_MKNOD.  We may want to just refuse moving to a cgroup which
+isn't a descendent of the current one.  Or we may want to use
+CAP_MAC_ADMIN, since we really are trying to lock down root.
+
+CAP_SYS_ADMIN is needed to modify the whitelist or move another
+task to a new cgroup.  (Again we'll probably want to change that).
+
+A cgroup may not be granted more permissions than the cgroup's
+parent has.
diff --git a/Documentation/controllers/resource_counter.txt b/Documentation/controllers/resource_counter.txt
new file mode 100644
index 000000000000..f196ac1d7d25
--- /dev/null
+++ b/Documentation/controllers/resource_counter.txt
@@ -0,0 +1,181 @@
+
+                The Resource Counter
+
+The resource counter, declared at include/linux/res_counter.h,
+is supposed to facilitate the resource management by controllers
+by providing common stuff for accounting.
+
+This "stuff" includes the res_counter structure and routines
+to work with it.
+
+
+
+1. Crucial parts of the res_counter structure
+
+ a. unsigned long long usage
+
+        The usage value shows the amount of a resource that is consumed
+        by a group at a given time. The units of measurement should be
+        determined by the controller that uses this counter. E.g. it can
+        be bytes, items or any other unit the controller operates on.
+
+ b. unsigned long long max_usage
+
+        The maximal value of the usage over time.
+
+        This value is useful when gathering statistical information about
+        the particular group, as it shows the actual resource requirements
+        for a particular group, not just some usage snapshot.
+
+ c. unsigned long long limit
+
+        The maximal allowed amount of resource to consume by the group. In
+        case the group requests for more resources, so that the usage value
+        would exceed the limit, the resource allocation is rejected (see
+        the next section).
+
+ d. unsigned long long failcnt
+
+        The failcnt stands for "failures counter". This is the number of
+        resource allocation attempts that failed.
+
+ c. spinlock_t lock
+
+        Protects changes of the above values.
+
+
+
+2. Basic accounting routines
+
+ a. void res_counter_init(struct res_counter *rc)
+
+        Initializes the resource counter. As usual, should be the first
+        routine called for a new counter.
+
+ b. int res_counter_charge[_locked]
+                        (struct res_counter *rc, unsigned long val)
+
+        When a resource is about to be allocated it has to be accounted
+        with the appropriate resource counter (controller should determine
+        which one to use on its own). This operation is called "charging".
+
+        This is not very important which operation - resource allocation
+        or charging - is performed first, but
+          * if the allocation is performed first, this may create a
+            temporary resource over-usage by the time resource counter is
+            charged;
+          * if the charging is performed first, then it should be uncharged
+            on error path (if the one is called).
+
+ c. void res_counter_uncharge[_locked]
+                        (struct res_counter *rc, unsigned long val)
+
+        When a resource is released (freed) it should be de-accounted
+        from the resource counter it was accounted to.  This is called
+        "uncharging".
+
+    The _locked routines imply that the res_counter->lock is taken.
+
+
+ 2.1 Other accounting routines
+
+    There are more routines that may help you with common needs, like
+    checking whether the limit is reached or resetting the max_usage
+    value. They are all declared in include/linux/res_counter.h.
+
+
+
+3. Analyzing the resource counter registrations
+
+ a. If the failcnt value constantly grows, this means that the counter's
+    limit is too tight. Either the group is misbehaving and consumes too
+    many resources, or the configuration is not suitable for the group
+    and the limit should be increased.
+
+ b. The max_usage value can be used to quickly tune the group. One may
+    set the limits to maximal values and either load the container with
+    a common pattern or leave one for a while. After this the max_usage
+    value shows the amount of memory the container would require during
+    its common activity.
+
+    Setting the limit a bit above this value gives a pretty good
+    configuration that works in most of the cases.
+
+ c. If the max_usage is much less than the limit, but the failcnt value
+    is growing, then the group tries to allocate a big chunk of resource
+    at once.
+
+ d. If the max_usage is much less than the limit, but the failcnt value
+    is 0, then this group is given too high limit, that it does not
+    require. It is better to lower the limit a bit leaving more resource
+    for other groups.
+
+
+
+4. Communication with the control groups subsystem (cgroups)
+
+All the resource controllers that are using cgroups and resource counters
+should provide files (in the cgroup filesystem) to work with the resource
+counter fields. They are recommended to adhere to the following rules:
+
+ a. File names
+
+        Field name      File name
+        ---------------------------------------------------
+        usage           usage_in_<unit_of_measurement>
+        max_usage       max_usage_in_<unit_of_measurement>
+        limit           limit_in_<unit_of_measurement>
+        failcnt         failcnt
+        lock            no file :)
+
+ b. Reading from file should show the corresponding field value in the
+    appropriate format.
+
+ c. Writing to file
+
+        Field           Expected behavior
+        ----------------------------------
+        usage           prohibited
+        max_usage       reset to usage
+        limit           set the limit
+        failcnt         reset to zero
+
+
+
+5. Usage example
+
+ a. Declare a task group (take a look at cgroups subsystem for this) and
+    fold a res_counter into it
+
+        struct my_group {
+                struct res_counter res;
+
+                <other fields>
+        }
+
+ b. Put hooks in resource allocation/release paths
+
+        int alloc_something(...)
+        {
+                if (res_counter_charge(res_counter_ptr, amount) < 0)
+                        return -ENOMEM;
+
+                <allocate the resource and return to the caller>
+        }
+
+        void release_something(...)
+        {
+                res_counter_uncharge(res_counter_ptr, amount);
+
+                <release the resource>
+        }
+
+    In order to keep the usage value self-consistent, both the
+    "res_counter_ptr" and the "amount" in release_something() should be
+    the same as they were in the alloc_something() when the releasing
+    resource was allocated.
+
+ c. Provide the way to read res_counter values and set them (the cgroups
+    still can help with it).
+
+ c. Compile and run :)
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index 6a9c55bd556b..dcec0564d040 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -129,14 +129,6 @@ to its default value of '80' it means that between the checking
 intervals the CPU needs to be on average more than 80% in use to then
 decide that the CPU frequency needs to be increased.  
 
-sampling_down_factor: this parameter controls the rate that the CPU
-makes a decision on when to decrease the frequency.  When set to its
-default value of '5' it means that at 1/5 the sampling_rate the kernel
-makes a decision to lower the frequency.  Five "lower rate" decisions
-have to be made in a row before the CPU frequency is actually lower.
-If set to '1' then the frequency decreases as quickly as it increases,
-if set to '2' it decreases at half the rate of the increase.
-
 ignore_nice_load: this parameter takes a value of '0' or '1'. When
 set to '0' (its default), all processes are counted towards the
 'cpu utilisation' value.  When set to '1', the processes that are
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index af3b925ece08..6c442d8426b5 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -154,6 +154,11 @@ scaling_governor,		and by "echoing" the name of another
                                 that some governors won't load - they only
                                 work on some specific architectures or
                                 processors.
+
+cpuinfo_cur_freq :              Current speed of the CPU, in KHz.
+
+scaling_available_frequencies : List of available frequencies, in KHz.
+
 scaling_min_freq and
 scaling_max_freq                show the current "policy limits" (in
                                 kHz). By echoing new values into these
@@ -162,6 +167,15 @@ scaling_max_freq		show the current "policy limits" (in
                                 first set scaling_max_freq, then
                                 scaling_min_freq.
 
+affected_cpus :                 List of CPUs that require software coordination
+                                of frequency.
+
+related_cpus :                  List of CPUs that need some sort of frequency
+                                coordination, whether software or hardware.
+
+scaling_driver :                Hardware driver for cpufreq.
+
+scaling_cur_freq :              Current frequency of the CPU, in KHz.
 
 If you have selected the "userspace" governor which allows you to
 set the CPU operating frequency to a specific value, you can read out
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index ad2bb3b3acc1..353504de3084 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt
@@ -8,6 +8,7 @@ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
 Modified by Paul Jackson <pj@sgi.com>
 Modified by Christoph Lameter <clameter@sgi.com>
 Modified by Paul Menage <menage@google.com>
+Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
 
 CONTENTS:
 =========
@@ -20,7 +21,8 @@ CONTENTS:
   1.5 What is memory_pressure ?
   1.6 What is memory spread ?
   1.7 What is sched_load_balance ?
-  1.8 How do I use cpusets ?
+  1.8 What is sched_relax_domain_level ?
+  1.9 How do I use cpusets ?
 2. Usage Examples and Syntax
   2.1 Basic Usage
   2.2 Adding/removing cpus
@@ -169,6 +171,7 @@ files describing that cpuset:
  - memory_migrate flag: if set, move pages to cpusets nodes
  - cpu_exclusive flag: is cpu placement exclusive?
  - mem_exclusive flag: is memory placement exclusive?
+ - mem_hardwall flag:  is memory allocation hardwalled
  - memory_pressure: measure of how much paging pressure in cpuset
 
 In addition, the root cpuset only has the following file:
@@ -196,7 +199,7 @@ using the sched_setaffinity, mbind and set_mempolicy system calls.
 The following rules apply to each cpuset:
 
  - Its CPUs and Memory Nodes must be a subset of its parents.
- - It can only be marked exclusive if its parent is.
+ - It can't be marked exclusive unless its parent is.
  - If its cpu or memory is exclusive, they may not overlap any sibling.
 
 These rules, and the natural hierarchy of cpusets, enable efficient
@@ -220,17 +223,18 @@ If a cpuset is cpu or mem exclusive, no other cpuset, other than
 a direct ancestor or descendent, may share any of the same CPUs or
 Memory Nodes.
 
-A cpuset that is mem_exclusive restricts kernel allocations for
-page, buffer and other data commonly shared by the kernel across
-multiple users.  All cpusets, whether mem_exclusive or not, restrict
-allocations of memory for user space.  This enables configuring a
-system so that several independent jobs can share common kernel data,
-such as file system pages, while isolating each jobs user allocation in
-its own cpuset.  To do this, construct a large mem_exclusive cpuset to
-hold all the jobs, and construct child, non-mem_exclusive cpusets for
-each individual job.  Only a small amount of typical kernel memory,
-such as requests from interrupt handlers, is allowed to be taken
-outside even a mem_exclusive cpuset.
+A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled",
+i.e. it restricts kernel allocations for page, buffer and other data
+commonly shared by the kernel across multiple users.  All cpusets,
+whether hardwalled or not, restrict allocations of memory for user
+space.  This enables configuring a system so that several independent
+jobs can share common kernel data, such as file system pages, while
+isolating each job's user allocation in its own cpuset.  To do this,
+construct a large mem_exclusive cpuset to hold all the jobs, and
+construct child, non-mem_exclusive cpusets for each individual job.
+Only a small amount of typical kernel memory, such as requests from
+interrupt handlers, is allowed to be taken outside even a
+mem_exclusive cpuset.
 
 
 1.5 What is memory_pressure ?
@@ -341,7 +345,7 @@ is modified to perform an inline check for this PF_SPREAD_PAGE task
 flag, and if set, a call to a new routine cpuset_mem_spread_node()
 returns the node to prefer for the allocation.
 
-Similarly, setting 'memory_spread_cache' turns on the flag
+Similarly, setting 'memory_spread_slab' turns on the flag
 PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
 pages from the node returned by cpuset_mem_spread_node().
 
@@ -497,7 +501,73 @@ the cpuset code to update these sched domains, it compares the new
 partition requested with the current, and updates its sched domains,
 removing the old and adding the new, for each change.
 
-1.8 How do I use cpusets ?
+
+1.8 What is sched_relax_domain_level ?
+--------------------------------------
+
+In sched domain, the scheduler migrates tasks in 2 ways; periodic load
+balance on tick, and at time of some schedule events.
+
+When a task is woken up, scheduler try to move the task on idle CPU.
+For example, if a task A running on CPU X activates another task B
+on the same CPU X, and if CPU Y is X's sibling and performing idle,
+then scheduler migrate task B to CPU Y so that task B can start on
+CPU Y without waiting task A on CPU X.
+
+And if a CPU run out of tasks in its runqueue, the CPU try to pull
+extra tasks from other busy CPUs to help them before it is going to
+be idle.
+
+Of course it takes some searching cost to find movable tasks and/or
+idle CPUs, the scheduler might not search all CPUs in the domain
+everytime.  In fact, in some architectures, the searching ranges on
+events are limited in the same socket or node where the CPU locates,
+while the load balance on tick searchs all.
+
+For example, assume CPU Z is relatively far from CPU X.  Even if CPU Z
+is idle while CPU X and the siblings are busy, scheduler can't migrate
+woken task B from X to Z since it is out of its searching range.
+As the result, task B on CPU X need to wait task A or wait load balance
+on the next tick.  For some applications in special situation, waiting
+1 tick may be too long.
+
+The 'sched_relax_domain_level' file allows you to request changing
+this searching range as you like.  This file takes int value which
+indicates size of searching range in levels ideally as follows,
+otherwise initial value -1 that indicates the cpuset has no request.
+
+  -1  : no request. use system default or follow request of others.
+   0  : no search.
+   1  : search siblings (hyperthreads in a core).
+   2  : search cores in a package.
+   3  : search cpus in a node [= system wide on non-NUMA system]
+ ( 4  : search nodes in a chunk of node [on NUMA system] )
+ ( 5  : search system wide [on NUMA system] )
+
+This file is per-cpuset and affect the sched domain where the cpuset
+belongs to.  Therefore if the flag 'sched_load_balance' of a cpuset
+is disabled, then 'sched_relax_domain_level' have no effect since
+there is no sched domain belonging the cpuset.
+
+If multiple cpusets are overlapping and hence they form a single sched
+domain, the largest value among those is used.  Be careful, if one
+requests 0 and others are -1 then 0 is used.
+
+Note that modifying this file will have both good and bad effects,
+and whether it is acceptable or not will be depend on your situation.
+Don't modify this file if you are not sure.
+
+If your situation is:
+ - The migration costs between each cpu can be assumed considerably
+   small(for you) due to your special application's behavior or
+   special hardware support for CPU cache etc.
+ - The searching cost doesn't have impact(for you) or you can make
+   the searching cost enough small by managing cpuset to compact etc.
+ - The latency is required even it sacrifices cache hit rate etc.
+then increasing 'sched_relax_domain_level' would benefit you.
+
+
+1.9 How do I use cpusets ?
 --------------------------
 
 In order to minimize the impact of cpusets on critical kernel
@@ -639,7 +709,10 @@ Now you want to do something with this cpuset.
 
 In this directory you can find several files:
 # ls
-cpus  cpu_exclusive  mems  mem_exclusive  tasks
+cpu_exclusive  memory_migrate      mems                      tasks
+cpus           memory_pressure     notify_on_release
+mem_exclusive  memory_spread_page  sched_load_balance
+mem_hardwall   memory_spread_slab  sched_relax_domain_level
 
 Reading them will give you information about the state of this cpuset:
 the CPUs and Memory Nodes it can use, the processes that are using
diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt
index c360d4e91b48..59a91e5c6909 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -41,15 +41,19 @@ to a working state and enables physical DMA by default for all remote nodes.
 This can be turned off by ohci1394's module parameter phys_dma=0.
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
-DMA, hence is not yet suitable for remote debugging.
+DMA by default, which is more secure but not suitable for remote debugging.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
+Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
+DMA.
 
-Because ohci1394 depends on the PCI enumeration to be completed, an
-initialization routine which runs pretty early (long before console_init()
-which makes the printk buffer appear on the console can be called) was written.
+Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+completed, an initialization routine which runs pretty early has been
+implemented for x86.  This routine runs long before console_init() can be
+called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
-Provide code for enabling DMA over FireWire early on boot) and pass the
-parameter "ohci1394_dma=early" to the recompiled kernel on boot.
+Remote debugging over FireWire early on boot) and pass the parameter
+"ohci1394_dma=early" to the recompiled kernel on boot.
 
 Tools
 -----
diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt
new file mode 100644
index 000000000000..6680cab2c705
--- /dev/null
+++ b/Documentation/device-mapper/dm-crypt.txt
@@ -0,0 +1,52 @@
+dm-crypt
+=========
+
+Device-Mapper's "crypt" target provides transparent encryption of block devices
+using the kernel crypto API.
+
+Parameters: <cipher> <key> <iv_offset> <device path> <offset>
+
+<cipher>
+    Encryption cipher and an optional IV generation mode.
+    (In format cipher-chainmode-ivopts:ivmode).
+    Examples:
+       des
+       aes-cbc-essiv:sha256
+       twofish-ecb
+
+    /proc/crypto contains supported crypto modes
+
+<key>
+    Key used for encryption. It is encoded as a hexadecimal number.
+    You can only use key sizes that are valid for the selected cipher.
+
+<iv_offset>
+    The IV offset is a sector count that is added to the sector number
+    before creating the IV.
+
+<device path>
+    This is the device that is going to be used as backend and contains the
+    encrypted data.  You can specify it as a path like /dev/xxx or a device
+    number <major>:<minor>.
+
+<offset>
+    Starting sector within the device where the encrypted data begins.
+
+Example scripts
+===============
+LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
+encryption with dm-crypt using the 'cryptsetup' utility, see
+http://luks.endorphin.org/
+
+[[
+#!/bin/sh
+# Create a crypt device using dmsetup
+dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
+]]
+
+[[
+#!/bin/sh
+# Create a crypt device using cryptsetup and LUKS header with default cipher
+cryptsetup luksFormat $1
+cryptsetup luksOpen $1 crypt1
+]]
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index c09a96b99354..881e6dd03aea 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -47,7 +47,6 @@
 .mm
 53c700_d.h
 53c8xx_d.h*
-BitKeeper
 COPYING
 CREDITS
 CVS
@@ -142,6 +141,7 @@ mkprep
 mktables
 mktree
 modpost
+modules.order
 modversions.h*
 offset.h
 offsets.h
@@ -172,6 +172,7 @@ sm_tbl*
 split-include
 tags
 tftpboot.img
+timeconst.h
 times.h*
 tkparse
 trix_boot.h
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README
index 766d320c8eb6..e35d83052192 100644
--- a/Documentation/early-userspace/README
+++ b/Documentation/early-userspace/README
@@ -89,8 +89,8 @@ the 2.7 era (it missed the boat for 2.5).
 You can obtain somewhat infrequent snapshots of klibc from
 ftp://ftp.kernel.org/pub/linux/libs/klibc/
 
-For active users, you are better off using the klibc BitKeeper
-repositories, at http://klibc.bkbits.net/
+For active users, you are better off using the klibc git
+repository, at http://git.kernel.org/?p=libs/klibc/klibc.git
 
 The standalone klibc distribution currently provides three components,
 in addition to the klibc library:
diff --git a/Documentation/fb/gxfb.txt b/Documentation/fb/gxfb.txt
new file mode 100644
index 000000000000..2f640903bbb2
--- /dev/null
+++ b/Documentation/fb/gxfb.txt
@@ -0,0 +1,52 @@
+[This file is cloned from VesaFB/aty128fb]
+
+What is gxfb?
+=================
+
+This is a graphics framebuffer driver for AMD Geode GX2 based processors.
+
+Advantages:
+
+ * No need to use AMD's VSA code (or other VESA emulation layer) in the
+   BIOS.
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF68_FBDev on top of /dev/fb0
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * graphic mode is slower than text mode...
+
+
+How to use it?
+==============
+
+Switching modes is done using  gxfb.mode_option=<resolution>... boot
+parameter or using `fbset' program.
+
+See Documentation/fb/modedb.txt for more information on modedb
+resolutions.
+
+
+X11
+===
+
+XF68_FBDev should generally work fine, but it is non-accelerated.
+
+
+Configuration
+=============
+
+You can pass kernel command line options to gxfb with gxfb.<option>.
+For example, gxfb.mode_option=800x600@75.
+Accepted options:
+
+mode_option     - specify the video mode.  Of the form
+                  <x>x<y>[-<bpp>][@<refresh>]
+vram            - size of video ram (normally auto-detected)
+vt_switch       - enable vt switching during suspend/resume.  The vt
+                  switch is slow, but harmless.
+
+--
+Andres Salomon <dilinger@debian.org>
diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt
index da5ee74219e8..27a3160650a4 100644
--- a/Documentation/fb/intelfb.txt
+++ b/Documentation/fb/intelfb.txt
@@ -14,6 +14,8 @@ graphics devices.  These would include:
         Intel 915GM
         Intel 945G
         Intel 945GM
+        Intel 965G
+        Intel 965GM
 
 B.  List of available options
 
diff --git a/Documentation/fb/lxfb.txt b/Documentation/fb/lxfb.txt
new file mode 100644
index 000000000000..38b3ca6f6ca7
--- /dev/null
+++ b/Documentation/fb/lxfb.txt
@@ -0,0 +1,52 @@
+[This file is cloned from VesaFB/aty128fb]
+
+What is lxfb?
+=================
+
+This is a graphics framebuffer driver for AMD Geode LX based processors.
+
+Advantages:
+
+ * No need to use AMD's VSA code (or other VESA emulation layer) in the
+   BIOS.
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF68_FBDev on top of /dev/fb0
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * graphic mode is slower than text mode...
+
+
+How to use it?
+==============
+
+Switching modes is done using  lxfb.mode_option=<resolution>... boot
+parameter or using `fbset' program.
+
+See Documentation/fb/modedb.txt for more information on modedb
+resolutions.
+
+
+X11
+===
+
+XF68_FBDev should generally work fine, but it is non-accelerated.
+
+
+Configuration
+=============
+
+You can pass kernel command line options to lxfb with lxfb.<option>.
+For example, lxfb.mode_option=800x600@75.
+Accepted options:
+
+mode_option     - specify the video mode.  Of the form
+                  <x>x<y>[-<bpp>][@<refresh>]
+vram            - size of video ram (normally auto-detected)
+vt_switch       - enable vt switching during suspend/resume.  The vt
+                  switch is slow, but harmless.
+
+--
+Andres Salomon <dilinger@debian.org>
diff --git a/Documentation/fb/metronomefb.txt b/Documentation/fb/metronomefb.txt
index b9a2e7b7e838..237ca412582d 100644
--- a/Documentation/fb/metronomefb.txt
+++ b/Documentation/fb/metronomefb.txt
@@ -1,7 +1,7 @@
                         Metronomefb
                         -----------
 Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
-Last revised: Nov 20, 2007
+Last revised: Mar 10, 2008
 
 Metronomefb is a driver for the Metronome display controller. The controller
 is from E-Ink Corporation. It is intended to be used to drive the E-Ink
@@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html .
 Metronome is interfaced to the host CPU through the AMLCD interface. The
 host CPU generates the control information and the image in a framebuffer
 which is then delivered to the AMLCD interface by a host specific method.
-Currently, that's implemented for the PXA's LCDC controller. The display and
-error status are each pulled through individual GPIOs.
+The display and error status are each pulled through individual GPIOs.
 
-Metronomefb was written for the PXA255/gumstix/lyre combination and
-therefore currently has board set specific code in it. If other boards based on
-other architectures are available, then the host specific code can be separated
-and abstracted out.
+Metronomefb is platform independent and depends on a board specific driver
+to do all physical IO work. Currently, an example is implemented for the
+PXA board used in the AM-200 EPD devkit. This example is am200epd.c
 
 Metronomefb requires waveform information which is delivered via the AMLCD
 interface to the metronome controller. The waveform information is expected to
 be delivered from userspace via the firmware class interface. The waveform file
 can be compressed as long as your udev or hotplug script is aware of the need
-to uncompress it before delivering it. metronomefb will ask for waveform.wbf
-which would typically go into /lib/firmware/waveform.wbf depending on your
+to uncompress it before delivering it. metronomefb will ask for metronome.wbf
+which would typically go into /lib/firmware/metronome.wbf depending on your
 udev/hotplug setup. I have only tested with a single waveform file which was
 originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
 Caution should be exercised when manipulating the waveform as there may be
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt
index 4fcdb4cf4cca..ec4dee75a354 100644
--- a/Documentation/fb/modedb.txt
+++ b/Documentation/fb/modedb.txt
@@ -125,8 +125,12 @@ There may be more modes.
     amifb       - Amiga chipset frame buffer
     aty128fb    - ATI Rage128 / Pro frame buffer
     atyfb       - ATI Mach64 frame buffer
+    pm2fb       - Permedia 2/2V frame buffer
+    pm3fb       - Permedia 3 frame buffer
+    sstfb       - Voodoo 1/2 (SST1) chipset frame buffer
     tdfxfb      - 3D Fx frame buffer
     tridentfb   - Trident (Cyber)blade chipset frame buffer
+    vt8623fb    - VIA 8623 frame buffer
 
 BTW, only a few drivers use this at the moment. Others are to follow
 (feel free to send patches).
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index bf0e3df8e7a1..46ece3fba6f9 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -128,15 +128,6 @@ Who:	Arjan van de Ven <arjan@linux.intel.com>
 
 ---------------------------
 
-What:   vm_ops.nopage
-When:   Soon, provided in-kernel callers have been converted
-Why:    This interface is replaced by vm_ops.fault, but it has been around
-        forever, is used by a lot of drivers, and doesn't cost much to
-        maintain.
-Who:    Nick Piggin <npiggin@suse.de>
-
----------------------------
-
 What:   PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
 When:   October 2008
 Why:    The stacking of class devices makes these values misleading and
@@ -147,6 +138,24 @@ Who:	Kay Sievers <kay.sievers@suse.de>
 
 ---------------------------
 
+What:   find_task_by_pid
+When:   2.6.26
+Why:    With pid namespaces, calling this funciton will return the
+        wrong task when called from inside a namespace.
+
+        The best way to save a task pid and find a task by this
+        pid later, is to find this task's struct pid pointer (or get
+        it directly from the task) and call pid_task() later.
+
+        If someone really needs to get a task by its pid_t, then
+        he most likely needs the find_task_by_vpid() to get the
+        task from the same namespace as the current task is in, but
+        this may be not so in general.
+
+Who:    Pavel Emelyanov <xemul@openvz.org>
+
+---------------------------
+
 What:   ACPI procfs interface
 When:   July 2008
 Why:    ACPI sysfs conversion should be finished by January 2008.
@@ -203,16 +212,8 @@ Who:  linuxppc-dev@ozlabs.org
 
 ---------------------------
 
-What:   sk98lin network driver
-When:   Feburary 2008
-Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
-        replaced by the skge driver. 
-Who:    Stephen Hemminger <shemminger@linux-foundation.org>
-
----------------------------
-
 What:   i386/x86_64 bzImage symlinks
-When:   April 2008
+When:   April 2010
 
 Why:    The i386/x86_64 merge provides a symlink to the old bzImage
         location so not yet updated user space tools, e.g. package
@@ -221,8 +222,6 @@ Who:	Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
----------------------------
-
 What:   i2c-i810, i2c-prosavage and i2c-savage4
 When:   May 2008
 Why:    These drivers are superseded by i810fb, intelfb and savagefb.
@@ -230,33 +229,6 @@ Who:	Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
 
-What:   bcm43xx wireless network driver
-When:   2.6.26
-Files:  drivers/net/wireless/bcm43xx
-Why:    This driver's functionality has been replaced by the
-        mac80211-based b43 and b43legacy drivers.
-Who:    John W. Linville <linville@tuxdriver.com>
-
----------------------------
-
-What:   ieee80211 softmac wireless networking component
-When:   2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
-Files:  net/ieee80211/softmac
-Why:    No in-kernel drivers will depend on it any longer.
-Who:    John W. Linville <linville@tuxdriver.com>
-
----------------------------
-
-What:   rc80211-simple rate control algorithm for mac80211
-When:   2.6.26
-Files:  net/mac80211/rc80211-simple.c
-Why:    This algorithm was provided for reference but always exhibited bad
-        responsiveness and performance and has some serious flaws. It has been
-        replaced by rc80211-pid.
-Who:    Stefano Brivio <stefano.brivio@polimi.it>
-
----------------------------
-
 What (Why):
         - include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files
           (superseded by xt_TOS/xt_tos target & match)
@@ -298,17 +270,6 @@ Who:	Michael Buesch <mb@bu3sch.de>
 
 ---------------------------
 
-What:   Solaris/SunOS syscall and binary support on Sparc
-When:   2.6.26
-Why:    Largely unmaintained and almost entirely unused.  File system
-        layering used to divert library and dynamic linker searches to
-        /usr/gnemul is extremely buggy and unfixable.  Making it work
-        is largely pointless as without a lot of work only the most
-        trivial of Solaris binaries can work with the emulation code.
-Who:    David S. Miller <davem@davemloft.net>
-
----------------------------
-
 What:   init_mm export
 When:   2.6.26
 Why:    Not used in-tree. The current out-of-tree users used it to
@@ -318,3 +279,45 @@ Why:	Not used in-tree. The current out-of-tree users used it to
         code / infrastructure should be in the kernel and not in some
         out-of-tree driver.
 Who:    Thomas Gleixner <tglx@linutronix.de>
+
+----------------------------
+
+What:   usedac i386 kernel parameter
+When:   2.6.27
+Why:    replaced by allowdac and no dac combination
+Who:    Glauber Costa <gcosta@redhat.com>
+
+---------------------------
+
+What:   old style serial driver for ColdFire (CONFIG_SERIAL_COLDFIRE)
+When:   2.6.28
+Why:    This driver still uses the old interface and has been replaced
+        by CONFIG_SERIAL_MCF.
+Who:    Sebastian Siewior <sebastian@breakpoint.cc>
+
+---------------------------
+
+What:   /sys/o2cb symlink
+When:   January 2010
+Why:    /sys/fs/o2cb is the proper location for this information - /sys/o2cb
+        exists as a symlink for backwards compatibility for old versions of
+        ocfs2-tools. 2 years should be sufficient time to phase in new versions
+        which know to look in /sys/fs/o2cb.
+Who:    ocfs2-devel@oss.oracle.com
+
+---------------------------
+
+What:   asm/semaphore.h
+When:   2.6.26
+Why:    Implementation became generic; users should now include
+        linux/semaphore.h instead.
+Who:    Matthew Wilcox <willy@linux.intel.com>
+
+---------------------------
+
+What:   CONFIG_THERMAL_HWMON
+When:   January 2009
+Why:    This option was introduced just to allow older lm-sensors userspace
+        to keep working over the upgrade to 2.6.26. At the scheduled time of
+        removal fixed lm-sensors (2.x or 3.x) should be readily available.
+Who:    Rene Herman <rene.herman@gmail.com>
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index e68021c08fbd..52cd611277a3 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -66,6 +66,8 @@ mandatory-locking.txt
         - info on the Linux implementation of Sys V mandatory file locking.
 ncpfs.txt
         - info on Novell Netware(tm) filesystem using NCP protocol.
+nfsroot.txt
+        - short guide on setting up a diskless box with NFS root filesystem.
 ntfs.txt
         - info and mount options for the NTFS filesystem (Windows NT).
 ocfs2.txt
@@ -82,6 +84,10 @@ relay.txt
         - info on relay, for efficient streaming from kernel to user space.
 romfs.txt
         - description of the ROMFS filesystem.
+rpc-cache.txt
+        - introduction to the caching mechanisms in the sunrpc layer.
+seq_file.txt
+        - how to use the seq_file API
 sharedsubtree.txt
         - a description of shared subtrees for namespaces.
 smbfs.txt
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 42d4b30b1045..8b22d7d8b991 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -92,7 +92,6 @@ prototypes:
         void (*destroy_inode)(struct inode *);
         void (*dirty_inode) (struct inode *);
         int (*write_inode) (struct inode *, int);
-        void (*put_inode) (struct inode *);
         void (*drop_inode) (struct inode *);
         void (*delete_inode) (struct inode *);
         void (*put_super) (struct super_block *);
@@ -115,7 +114,6 @@ alloc_inode:		no	no	no
 destroy_inode:          no
 dirty_inode:            no                              (must not sleep)
 write_inode:            no
-put_inode:              no
 drop_inode:             no                              !!!inode_lock!!!
 delete_inode:           no
 put_super:              yes     yes     no
@@ -511,7 +509,6 @@ prototypes:
         void (*open)(struct vm_area_struct*);
         void (*close)(struct vm_area_struct*);
         int (*fault)(struct vm_area_struct*, struct vm_fault *);
-        struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
         int (*page_mkwrite)(struct vm_area_struct *, struct page *);
 
 locking rules:
@@ -519,7 +516,6 @@ locking rules:
 open:           no      yes
 close:          no      yes
 fault:          no      yes
-nopage:         no      yes
 page_mkwrite:   no      yes             no
 
         ->page_mkwrite() is called when a previously read-only page is
@@ -537,4 +533,3 @@ NULL.
 
 ipc/shm.c::shm_delete() - may need BKL.
 ->read() and ->write() in many drivers are (probably) missing BKL.
-drivers/sgi/char/graphics.c::sgi_graphics_nopage() - may need BKL.
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 560f88dc7090..0c5086db8352 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -139,8 +139,16 @@ commit=nrsec	(*)	Ext4 can be told to sync all its data and metadata
                         Setting it to very large values will improve
                         performance.
 
-barrier=1               This enables/disables barriers.  barrier=0 disables
-                        it, barrier=1 enables it.
+barrier=<0|1(*)>        This enables/disables the use of write barriers in
+                        the jbd code.  barrier=0 disables, barrier=1 enables.
+                        This also requires an IO stack which can support
+                        barriers, and if jbd gets an error on a barrier
+                        write, it will disable again with a warning.
+                        Write barriers enforce proper on-disk ordering
+                        of journal commits, making volatile disk write caches
+                        safe to use, at some performance penalty.  If
+                        your disks are battery-backed in one way or another,
+                        disabling barriers may safely improve performance.
 
 orlov           (*)     This enables the new Orlov block allocator. It is
                         enabled by default.
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt
new file mode 100644
index 000000000000..d0ec45ae4e7d
--- /dev/null
+++ b/Documentation/filesystems/nfs-rdma.txt
@@ -0,0 +1,256 @@
+################################################################################
+#                                                                              #
+#                               NFS/RDMA README                                #
+#                                                                              #
+################################################################################
+
+ Author: NetApp and Open Grid Computing
+ Date: April 15, 2008
+
+Table of Contents
+~~~~~~~~~~~~~~~~~
+ - Overview
+ - Getting Help
+ - Installation
+ - Check RDMA and NFS Setup
+ - NFS/RDMA Setup
+
+Overview
+~~~~~~~~
+
+  This document describes how to install and setup the Linux NFS/RDMA client
+  and server software.
+
+  The NFS/RDMA client was first included in Linux 2.6.24. The NFS/RDMA server
+  was first included in the following release, Linux 2.6.25.
+
+  In our testing, we have obtained excellent performance results (full 10Gbit
+  wire bandwidth at minimal client CPU) under many workloads. The code passes
+  the full Connectathon test suite and operates over both Infiniband and iWARP
+  RDMA adapters.
+
+Getting Help
+~~~~~~~~~~~~
+
+  If you get stuck, you can ask questions on the
+
+                nfs-rdma-devel@lists.sourceforge.net
+
+  mailing list.
+
+Installation
+~~~~~~~~~~~~
+
+  These instructions are a step by step guide to building a machine for
+  use with NFS/RDMA.
+
+  - Install an RDMA device
+
+    Any device supported by the drivers in drivers/infiniband/hw is acceptable.
+
+    Testing has been performed using several Mellanox-based IB cards, the
+    Ammasso AMS1100 iWARP adapter, and the Chelsio cxgb3 iWARP adapter.
+
+  - Install a Linux distribution and tools
+
+    The first kernel release to contain both the NFS/RDMA client and server was
+    Linux 2.6.25  Therefore, a distribution compatible with this and subsequent
+    Linux kernel release should be installed.
+
+    The procedures described in this document have been tested with
+    distributions from Red Hat's Fedora Project (http://fedora.redhat.com/).
+
+  - Install nfs-utils-1.1.1 or greater on the client
+
+    An NFS/RDMA mount point can only be obtained by using the mount.nfs
+    command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs
+    you are using, type:
+
+    > /sbin/mount.nfs -V
+
+    If the version is less than 1.1.1 or the command does not exist,
+    then you will need to install the latest version of nfs-utils.
+
+    Download the latest package from:
+
+    http://www.kernel.org/pub/linux/utils/nfs
+
+    Uncompress the package and follow the installation instructions.
+
+    If you will not be using GSS and NFSv4, the installation process
+    can be simplified by disabling these features when running configure:
+
+    > ./configure --disable-gss --disable-nfsv4
+
+    For more information on this see the package's README and INSTALL files.
+
+    After building the nfs-utils package, there will be a mount.nfs binary in
+    the utils/mount directory. This binary can be used to initiate NFS v2, v3,
+    or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4.
+    The standard technique is to create a symlink called mount.nfs4 to mount.nfs.
+
+    NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed
+    on the NFS client machine. You do not need this specific version of
+    nfs-utils on the server. Furthermore, only the mount.nfs command from
+    nfs-utils-1.1.1 is needed on the client.
+
+  - Install a Linux kernel with NFS/RDMA
+
+    The NFS/RDMA client and server are both included in the mainline Linux
+    kernel version 2.6.25 and later. This and other versions of the 2.6 Linux
+    kernel can be found at:
+
+    ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
+
+    Download the sources and place them in an appropriate location.
+
+  - Configure the RDMA stack
+
+    Make sure your kernel configuration has RDMA support enabled. Under
+    Device Drivers -> InfiniBand support, update the kernel configuration
+    to enable InfiniBand support [NOTE: the option name is misleading. Enabling
+    InfiniBand support is required for all RDMA devices (IB, iWARP, etc.)].
+
+    Enable the appropriate IB HCA support (mlx4, mthca, ehca, ipath, etc.) or
+    iWARP adapter support (amso, cxgb3, etc.).
+
+    If you are using InfiniBand, be sure to enable IP-over-InfiniBand support.
+
+  - Configure the NFS client and server
+
+    Your kernel configuration must also have NFS file system support and/or
+    NFS server support enabled. These and other NFS related configuration
+    options can be found under File Systems -> Network File Systems.
+
+  - Build, install, reboot
+
+    The NFS/RDMA code will be enabled automatically if NFS and RDMA
+    are turned on. The NFS/RDMA client and server are configured via the hidden
+    SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
+    value of SUNRPC_XPRT_RDMA will be:
+
+     - N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
+       and server will not be built
+     - M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M,
+       in this case the NFS/RDMA client and server will be built as modules
+     - Y if both SUNRPC and INFINIBAND are Y, in this case the NFS/RDMA client
+       and server will be built into the kernel
+
+    Therefore, if you have followed the steps above and turned no NFS and RDMA,
+    the NFS/RDMA client and server will be built.
+
+    Build a new kernel, install it, boot it.
+
+Check RDMA and NFS Setup
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+    Before configuring the NFS/RDMA software, it is a good idea to test
+    your new kernel to ensure that the kernel is working correctly.
+    In particular, it is a good idea to verify that the RDMA stack
+    is functioning as expected and standard NFS over TCP/IP and/or UDP/IP
+    is working properly.
+
+  - Check RDMA Setup
+
+    If you built the RDMA components as modules, load them at
+    this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel
+    card:
+
+    > modprobe ib_mthca
+    > modprobe ib_ipoib
+
+    If you are using InfiniBand, make sure there is a Subnet Manager (SM)
+    running on the network. If your IB switch has an embedded SM, you can
+    use it. Otherwise, you will need to run an SM, such as OpenSM, on one
+    of your end nodes.
+
+    If an SM is running on your network, you should see the following:
+
+    > cat /sys/class/infiniband/driverX/ports/1/state
+    4: ACTIVE
+
+    where driverX is mthca0, ipath5, ehca3, etc.
+
+    To further test the InfiniBand software stack, use IPoIB (this
+    assumes you have two IB hosts named host1 and host2):
+
+    host1> ifconfig ib0 a.b.c.x
+    host2> ifconfig ib0 a.b.c.y
+    host1> ping a.b.c.y
+    host2> ping a.b.c.x
+
+    For other device types, follow the appropriate procedures.
+
+  - Check NFS Setup
+
+    For the NFS components enabled above (client and/or server),
+    test their functionality over standard Ethernet using TCP/IP or UDP/IP.
+
+NFS/RDMA Setup
+~~~~~~~~~~~~~~
+
+  We recommend that you use two machines, one to act as the client and
+  one to act as the server.
+
+  One time configuration:
+
+  - On the server system, configure the /etc/exports file and
+    start the NFS/RDMA server.
+
+    Exports entries with the following formats have been tested:
+
+    /vol0   192.168.0.47(fsid=0,rw,async,insecure,no_root_squash)
+    /vol0   192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash)
+
+    The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the
+    cleint's iWARP address(es) for an RNIC.
+
+    NOTE: The "insecure" option must be used because the NFS/RDMA client does not
+    use a reserved port.
+
+ Each time a machine boots:
+
+  - Load and configure the RDMA drivers
+
+    For InfiniBand using a Mellanox adapter:
+
+    > modprobe ib_mthca
+    > modprobe ib_ipoib
+    > ifconfig ib0 a.b.c.d
+
+    NOTE: use unique addresses for the client and server
+
+  - Start the NFS server
+
+    If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
+    load the RDMA transport module:
+
+    > modprobe svcrdma
+
+    Regardless of how the server was built (module or built-in), start the server:
+
+    > /etc/init.d/nfs start
+
+    or
+
+    > service nfs start
+
+    Instruct the server to listen on the RDMA transport:
+
+    > echo rdma 2050 > /proc/fs/nfsd/portlist
+
+  - On the client system
+
+    If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
+    load the RDMA client module:
+
+    > modprobe xprtrdma.ko
+
+    Regardless of how the client was built (module or built-in), issue the mount.nfs command:
+
+    > /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050
+
+    To verify that the mount is using RDMA, run "cat /proc/mounts" and check the
+    "proto" field for the given mount.
+
+  Congratulations! You're using NFS/RDMA!
diff --git a/Documentation/nfsroot.txt b/Documentation/filesystems/nfsroot.txt
index 31b329172343..31b329172343 100644
--- a/Documentation/nfsroot.txt
+++ b/Documentation/filesystems/nfsroot.txt
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 518ebe609e2b..dbc3c6a3650f 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -43,6 +43,7 @@ Table of Contents
   2.13  /proc/<pid>/oom_score - Display current oom-killer score
   2.14  /proc/<pid>/io - Display the IO accounting fields
   2.15  /proc/<pid>/coredump_filter - Core dump filtering settings
+  2.16  /proc/<pid>/mountinfo - Information about mounts
 
 ------------------------------------------------------------------------------
 Preface
@@ -462,11 +463,17 @@ SwapTotal:           0 kB
 SwapFree:            0 kB
 Dirty:             968 kB
 Writeback:           0 kB
+AnonPages:      861800 kB
 Mapped:         280372 kB
-Slab:           684068 kB
+Slab:           284364 kB
+SReclaimable:   159856 kB
+SUnreclaim:     124508 kB
+PageTables:      24448 kB
+NFS_Unstable:        0 kB
+Bounce:              0 kB
+WritebackTmp:        0 kB
 CommitLimit:   7669796 kB
 Committed_AS:   100056 kB
-PageTables:      24448 kB
 VmallocTotal:   112216 kB
 VmallocUsed:       428 kB
 VmallocChunk:   111088 kB
@@ -502,8 +509,17 @@ VmallocChunk:   111088 kB
               on the disk
        Dirty: Memory which is waiting to get written back to the disk
    Writeback: Memory which is actively being written back to the disk
+   AnonPages: Non-file backed pages mapped into userspace page tables
       Mapped: files which have been mmaped, such as libraries
         Slab: in-kernel data structures cache
+SReclaimable: Part of Slab, that might be reclaimed, such as caches
+  SUnreclaim: Part of Slab, that cannot be reclaimed on memory pressure
+  PageTables: amount of memory dedicated to the lowest level of page
+              tables.
+NFS_Unstable: NFS pages sent to the server, but not yet committed to stable
+              storage
+      Bounce: Memory used for block device "bounce buffers"
+WritebackTmp: Memory used by FUSE for temporary writeback buffers
  CommitLimit: Based on the overcommit ratio ('vm.overcommit_ratio'),
               this is the total amount of  memory currently available to
               be allocated on the system. This limit is only adhered to
@@ -530,8 +546,6 @@ Committed_AS: The amount of memory presently allocated on the system.
               above) will not be permitted. This is useful if one needs
               to guarantee that processes will not fail due to lack of
               memory once that memory has been successfully allocated.
-  PageTables: amount of memory dedicated to the lowest level of page
-              tables.
 VmallocTotal: total size of vmalloc memory area
  VmallocUsed: amount of vmalloc area which is used
 VmallocChunk: largest contigious block of vmalloc area which is free
@@ -2348,4 +2362,41 @@ For example:
   $ echo 0x7 > /proc/self/coredump_filter
   $ ./some_program
 
+2.16    /proc/<pid>/mountinfo - Information about mounts
+--------------------------------------------------------
+
+This file contains lines of the form:
+
+36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
+(1)(2)(3)   (4)   (5)      (6)      (7)   (8) (9)   (10)         (11)
+
+(1) mount ID:  unique identifier of the mount (may be reused after umount)
+(2) parent ID:  ID of parent (or of self for the top of the mount tree)
+(3) major:minor:  value of st_dev for files on filesystem
+(4) root:  root of the mount within the filesystem
+(5) mount point:  mount point relative to the process's root
+(6) mount options:  per mount options
+(7) optional fields:  zero or more fields of the form "tag[:value]"
+(8) separator:  marks the end of the optional fields
+(9) filesystem type:  name of filesystem of the form "type[.subtype]"
+(10) mount source:  filesystem specific information or "none"
+(11) super options:  per super block options
+
+Parsers should ignore all unrecognised optional fields.  Currently the
+possible optional fields are:
+
+shared:X  mount is shared in peer group X
+master:X  mount is slave to peer group X
+propagate_from:X  mount is slave and receives propagation from peer group X (*)
+unbindable  mount is unbindable
+
+(*) X is the closest dominant peer group under the process's root.  If
+X is the immediate master of the mount, or if there's no dominant peer
+group under the same root, then only the "master:X" field is present
+and not the "propagate_from:X" field.
+
+For more information on mount propagation see:
+
+  Documentation/filesystems/sharedsubtree.txt
+
 ------------------------------------------------------------------------------
diff --git a/Documentation/rpc-cache.txt b/Documentation/filesystems/rpc-cache.txt
index 8a382bea6808..8a382bea6808 100644
--- a/Documentation/rpc-cache.txt
+++ b/Documentation/filesystems/rpc-cache.txt
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
new file mode 100644
index 000000000000..b843743aa0b5
--- /dev/null
+++ b/Documentation/filesystems/seq_file.txt
@@ -0,0 +1,294 @@
+The seq_file interface
+
+        Copyright 2003 Jonathan Corbet <corbet@lwn.net>
+        This file is originally from the LWN.net Driver Porting series at
+        http://lwn.net/Articles/driver-porting/
+
+
+There are numerous ways for a device driver (or other kernel component) to
+provide information to the user or system administrator.  One useful
+technique is the creation of virtual files, in debugfs, /proc or elsewhere.
+Virtual files can provide human-readable output that is easy to get at
+without any special utility programs; they can also make life easier for
+script writers. It is not surprising that the use of virtual files has
+grown over the years.
+
+Creating those files correctly has always been a bit of a challenge,
+however. It is not that hard to make a virtual file which returns a
+string. But life gets trickier if the output is long - anything greater
+than an application is likely to read in a single operation.  Handling
+multiple reads (and seeks) requires careful attention to the reader's
+position within the virtual file - that position is, likely as not, in the
+middle of a line of output. The kernel has traditionally had a number of
+implementations that got this wrong.
+
+The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
+which are designed to make it easy for virtual file creators to get it
+right.
+
+The seq_file interface is available via <linux/seq_file.h>. There are
+three aspects to seq_file:
+
+     * An iterator interface which lets a virtual file implementation
+       step through the objects it is presenting.
+
+     * Some utility functions for formatting objects for output without
+       needing to worry about things like output buffers.
+
+     * A set of canned file_operations which implement most operations on
+       the virtual file.
+
+We'll look at the seq_file interface via an extremely simple example: a
+loadable module which creates a file called /proc/sequence. The file, when
+read, simply produces a set of increasing integer values, one per line. The
+sequence will continue until the user loses patience and finds something
+better to do. The file is seekable, in that one can do something like the
+following:
+
+    dd if=/proc/sequence of=out1 count=1
+    dd if=/proc/sequence skip=1 out=out2 count=1
+
+Then concatenate the output files out1 and out2 and get the right
+result. Yes, it is a thoroughly useless module, but the point is to show
+how the mechanism works without getting lost in other details.  (Those
+wanting to see the full source for this module can find it at
+http://lwn.net/Articles/22359/).
+
+
+The iterator interface
+
+Modules implementing a virtual file with seq_file must implement a simple
+iterator object that allows stepping through the data of interest.
+Iterators must be able to move to a specific position - like the file they
+implement - but the interpretation of that position is up to the iterator
+itself. A seq_file implementation that is formatting firewall rules, for
+example, could interpret position N as the Nth rule in the chain.
+Positioning can thus be done in whatever way makes the most sense for the
+generator of the data, which need not be aware of how a position translates
+to an offset in the virtual file. The one obvious exception is that a
+position of zero should indicate the beginning of the file.
+
+The /proc/sequence iterator just uses the count of the next number it
+will output as its position.
+
+Four functions must be implemented to make the iterator work. The first,
+called start() takes a position as an argument and returns an iterator
+which will start reading at that position. For our simple sequence example,
+the start() function looks like:
+
+        static void *ct_seq_start(struct seq_file *s, loff_t *pos)
+        {
+                loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
+                if (! spos)
+                        return NULL;
+                *spos = *pos;
+                return spos;
+        }
+
+The entire data structure for this iterator is a single loff_t value
+holding the current position. There is no upper bound for the sequence
+iterator, but that will not be the case for most other seq_file
+implementations; in most cases the start() function should check for a
+"past end of file" condition and return NULL if need be.
+
+For more complicated applications, the private field of the seq_file
+structure can be used. There is also a special value which can be returned
+by the start() function called SEQ_START_TOKEN; it can be used if you wish
+to instruct your show() function (described below) to print a header at the
+top of the output. SEQ_START_TOKEN should only be used if the offset is
+zero, however.
+
+The next function to implement is called, amazingly, next(); its job is to
+move the iterator forward to the next position in the sequence.  The
+example module can simply increment the position by one; more useful
+modules will do what is needed to step through some data structure. The
+next() function returns a new iterator, or NULL if the sequence is
+complete. Here's the example version:
+
+        static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
+        {
+                loff_t *spos = v;
+                *pos = ++*spos;
+                return spos;
+        }
+
+The stop() function is called when iteration is complete; its job, of
+course, is to clean up. If dynamic memory is allocated for the iterator,
+stop() is the place to free it.
+
+        static void ct_seq_stop(struct seq_file *s, void *v)
+        {
+                kfree(v);
+        }
+
+Finally, the show() function should format the object currently pointed to
+by the iterator for output.  The example module's show() function is:
+
+        static int ct_seq_show(struct seq_file *s, void *v)
+        {
+                loff_t *spos = v;
+                seq_printf(s, "%lld\n", (long long)*spos);
+                return 0;
+        }
+
+If all is well, the show() function should return zero.  A negative error
+code in the usual manner indicates that something went wrong; it will be
+passed back to user space.  This function can also return SEQ_SKIP, which
+causes the current item to be skipped; if the show() function has already
+generated output before returning SEQ_SKIP, that output will be dropped.
+
+We will look at seq_printf() in a moment. But first, the definition of the
+seq_file iterator is finished by creating a seq_operations structure with
+the four functions we have just defined:
+
+        static const struct seq_operations ct_seq_ops = {
+                .start = ct_seq_start,
+                .next  = ct_seq_next,
+                .stop  = ct_seq_stop,
+                .show  = ct_seq_show
+        };
+
+This structure will be needed to tie our iterator to the /proc file in
+a little bit.
+
+It's worth noting that the iterator value returned by start() and
+manipulated by the other functions is considered to be completely opaque by
+the seq_file code. It can thus be anything that is useful in stepping
+through the data to be output. Counters can be useful, but it could also be
+a direct pointer into an array or linked list. Anything goes, as long as
+the programmer is aware that things can happen between calls to the
+iterator function. However, the seq_file code (by design) will not sleep
+between the calls to start() and stop(), so holding a lock during that time
+is a reasonable thing to do. The seq_file code will also avoid taking any
+other locks while the iterator is active.
+
+
+Formatted output
+
+The seq_file code manages positioning within the output created by the
+iterator and getting it into the user's buffer. But, for that to work, that
+output must be passed to the seq_file code. Some utility functions have
+been defined which make this task easy.
+
+Most code will simply use seq_printf(), which works pretty much like
+printk(), but which requires the seq_file pointer as an argument. It is
+common to ignore the return value from seq_printf(), but a function
+producing complicated output may want to check that value and quit if
+something non-zero is returned; an error return means that the seq_file
+buffer has been filled and further output will be discarded.
+
+For straight character output, the following functions may be used:
+
+        int seq_putc(struct seq_file *m, char c);
+        int seq_puts(struct seq_file *m, const char *s);
+        int seq_escape(struct seq_file *m, const char *s, const char *esc);
+
+The first two output a single character and a string, just like one would
+expect. seq_escape() is like seq_puts(), except that any character in s
+which is in the string esc will be represented in octal form in the output.
+
+There is also a pair of functions for printing filenames:
+
+        int seq_path(struct seq_file *m, struct path *path, char *esc);
+        int seq_path_root(struct seq_file *m, struct path *path,
+                          struct path *root, char *esc)
+
+Here, path indicates the file of interest, and esc is a set of characters
+which should be escaped in the output.  A call to seq_path() will output
+the path relative to the current process's filesystem root.  If a different
+root is desired, it can be used with seq_path_root().  Note that, if it
+turns out that path cannot be reached from root, the value of root will be
+changed in seq_file_root() to a root which *does* work.
+
+
+Making it all work
+
+So far, we have a nice set of functions which can produce output within the
+seq_file system, but we have not yet turned them into a file that a user
+can see. Creating a file within the kernel requires, of course, the
+creation of a set of file_operations which implement the operations on that
+file. The seq_file interface provides a set of canned operations which do
+most of the work. The virtual file author still must implement the open()
+method, however, to hook everything up. The open function is often a single
+line, as in the example module:
+
+        static int ct_open(struct inode *inode, struct file *file)
+        {
+                return seq_open(file, &ct_seq_ops);
+        }
+
+Here, the call to seq_open() takes the seq_operations structure we created
+before, and gets set up to iterate through the virtual file.
+
+On a successful open, seq_open() stores the struct seq_file pointer in
+file->private_data. If you have an application where the same iterator can
+be used for more than one file, you can store an arbitrary pointer in the
+private field of the seq_file structure; that value can then be retrieved
+by the iterator functions.
+
+The other operations of interest - read(), llseek(), and release() - are
+all implemented by the seq_file code itself. So a virtual file's
+file_operations structure will look like:
+
+        static const struct file_operations ct_file_ops = {
+                .owner   = THIS_MODULE,
+                .open    = ct_open,
+                .read    = seq_read,
+                .llseek  = seq_lseek,
+                .release = seq_release
+        };
+
+There is also a seq_release_private() which passes the contents of the
+seq_file private field to kfree() before releasing the structure.
+
+The final step is the creation of the /proc file itself. In the example
+code, that is done in the initialization code in the usual way:
+
+        static int ct_init(void)
+        {
+                struct proc_dir_entry *entry;
+
+                entry = create_proc_entry("sequence", 0, NULL);
+                if (entry)
+                        entry->proc_fops = &ct_file_ops;
+                return 0;
+        }
+
+        module_init(ct_init);
+
+And that is pretty much it.
+
+
+seq_list
+
+If your file will be iterating through a linked list, you may find these
+routines useful:
+
+        struct list_head *seq_list_start(struct list_head *head,
+                                         loff_t pos);
+        struct list_head *seq_list_start_head(struct list_head *head,
+                                              loff_t pos);
+        struct list_head *seq_list_next(void *v, struct list_head *head,
+                                        loff_t *ppos);
+
+These helpers will interpret pos as a position within the list and iterate
+accordingly.  Your start() and next() functions need only invoke the
+seq_list_* helpers with a pointer to the appropriate list_head structure.
+
+
+The extra-simple version
+
+For extremely simple virtual files, there is an even easier interface.  A
+module can define only the show() function, which should create all the
+output that the virtual file will contain. The file's open() method then
+calls:
+
+        int single_open(struct file *file,
+                        int (*show)(struct seq_file *m, void *p),
+                        void *data);
+
+When output time comes, the show() function will be called once. The data
+value given to single_open() can be found in the private field of the
+seq_file structure. When using single_open(), the programmer should use
+single_release() instead of seq_release() in the file_operations structure
+to avoid a memory leak.
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 5daa2aaec2c5..68ef48839c04 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -36,6 +36,7 @@ files, each with their own function.
        local_cpus          nearby CPU mask (cpumask, ro)
        resource            PCI resource host addresses (ascii, ro)
        resource0..N        PCI resource N, if present (binary, mmap)
+       resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, mmap)
        rom                 PCI ROM resource, if present (binary, ro)
        subsystem_device    PCI subsystem device (ascii, ro)
        subsystem_vendor    PCI subsystem vendor (ascii, ro)
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 4598ef7b622b..7f27b8f840d0 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -176,8 +176,10 @@ implementations:
   Recall that an attribute should only be exporting one value, or an
   array of similar values, so this shouldn't be that expensive. 
 
-  This allows userspace to do partial reads and seeks arbitrarily over
-  the entire file at will. 
+  This allows userspace to do partial reads and forward seeks
+  arbitrarily over the entire file at will. If userspace seeks back to
+  zero or does a pread(2) with an offset of '0' the show() method will
+  be called again, rearmed, to fill the buffer.
 
 - On write(2), sysfs expects the entire buffer to be passed during the
   first write. Sysfs then passes the entire buffer to the store()
@@ -192,6 +194,9 @@ implementations:
 
 Other notes:
 
+- Writing causes the show() method to be rearmed regardless of current
+  file position.
+
 - The buffer will always be PAGE_SIZE bytes in length. On i386, this
   is 4096. 
 
diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt
index 145e44086358..222437efd75a 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -92,6 +92,18 @@ NodeList format is a comma-separated list of decimal numbers and ranges,
 a range being two hyphen-separated decimal numbers, the smallest and
 largest node numbers in the range.  For example, mpol=bind:0-3,5,7,9-15
 
+NUMA memory allocation policies have optional flags that can be used in
+conjunction with their modes.  These optional flags can be specified
+when tmpfs is mounted by appending them to the mode before the NodeList.
+See Documentation/vm/numa_memory_policy.txt for a list of all available
+memory allocation policy mode flags.
+
+        =static         is equivalent to        MPOL_F_STATIC_NODES
+        =relative       is equivalent to        MPOL_F_RELATIVE_NODES
+
+For example, mpol=bind=static:NodeList, is the equivalent of an
+allocation policy of MPOL_BIND | MPOL_F_STATIC_NODES.
+
 Note that trying to mount a tmpfs with an mpol option will fail if the
 running kernel does not support NUMA; and will fail if its nodelist
 specifies a node which is not online.  If your system relies on that
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index fcc123ffa252..2d5e1e582e13 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -17,6 +17,21 @@ dmask=###     -- The permission mask for the directory.
 fmask=###     -- The permission mask for files.
                  The default is the umask of current process.
 
+allow_utime=### -- This option controls the permission check of mtime/atime.
+
+                  20 - If current process is in group of file's group ID,
+                       you can change timestamp.
+                   2 - Other users can change timestamp.
+
+                 The default is set from `dmask' option. (If the directory is
+                 writable, utime(2) is also allowed. I.e. ~dmask & 022)
+
+                 Normally utime(2) checks current process is owner of
+                 the file, or it has CAP_FOWNER capability.  But FAT
+                 filesystem doesn't have uid/gid on disk, so normal
+                 check is too unflexible. With this option you can
+                 relax it.
+
 codepage=###  -- Sets the codepage number for converting to shortname
                  characters on FAT filesystem.
                  By default, FAT_DEFAULT_CODEPAGE setting is used.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 81e5be6e6e35..b7522c6cbae3 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -205,7 +205,6 @@ struct super_operations {
 
         void (*dirty_inode) (struct inode *);
         int (*write_inode) (struct inode *, int);
-        void (*put_inode) (struct inode *);
         void (*drop_inode) (struct inode *);
         void (*delete_inode) (struct inode *);
         void (*put_super) (struct super_block *);
@@ -246,9 +245,6 @@ or bottom half).
         inode to disc.  The second parameter indicates whether the write
         should be synchronous or not, not all filesystems check this flag.
 
-  put_inode: called when the VFS inode is removed from the inode
-        cache.
-
   drop_inode: called when the last access to the inode is dropped,
         with the inode_lock spinlock held.
 
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 74aeb142ae5f..0a1668ba2600 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -52,16 +52,15 @@ When mounting an XFS filesystem, the following options are accepted.
         and also gets the setgid bit set if it is a directory itself.
 
   ihashsize=value
-        Sets the number of hash buckets available for hashing the
-        in-memory inodes of the specified mount point.  If a value
-        of zero is used, the value selected by the default algorithm
-        will be displayed in /proc/mounts.
+        In memory inode hashes have been removed, so this option has
+        no function as of August 2007. Option is deprecated.
 
   ikeep/noikeep
-        When inode clusters are emptied of inodes, keep them around
-        on the disk (ikeep) - this is the traditional XFS behaviour
-        and is still the default for now.  Using the noikeep option,
-        inode clusters are returned to the free space pool.
+        When ikeep is specified, XFS does not delete empty inode clusters
+        and keeps them around on disk. ikeep is the traditional XFS
+        behaviour. When noikeep is specified, empty inode clusters
+        are returned to the free space pool. The default is noikeep for
+        non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
 
   inode64
         Indicates that XFS is allowed to create inodes at any location
diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
deleted file mode 100644
index 6865cbe075ec..000000000000
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * firmware_sample_driver.c -
- *
- * Copyright (c) 2003 Manuel Estrada Sainz
- *
- * Sample code on how to use request_firmware() from drivers.
- *
- */
-
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/device.h>
-#include <linux/string.h>
-
-#include "linux/firmware.h"
-
-static struct device ghost_device = {
-        .bus_id    = "ghost0",
-};
-
-
-static void sample_firmware_load(char *firmware, int size)
-{
-        u8 buf[size+1];
-        memcpy(buf, firmware, size);
-        buf[size] = '\0';
-        printk(KERN_INFO "firmware_sample_driver: firmware: %s\n", buf);
-}
-
-static void sample_probe_default(void)
-{
-        /* uses the default method to get the firmware */
-        const struct firmware *fw_entry;
-        printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n");
-
-        if(request_firmware(&fw_entry, "sample_driver_fw", &ghost_device)!=0)
-        {
-                printk(KERN_ERR
-                       "firmware_sample_driver: Firmware not available\n");
-                return;
-        }
-        
-        sample_firmware_load(fw_entry->data, fw_entry->size);
-
-        release_firmware(fw_entry);
-
-        /* finish setting up the device */
-}
-static void sample_probe_specific(void)
-{
-        /* Uses some specific hotplug support to get the firmware from
-         * userspace  directly into the hardware, or via some sysfs file */
-
-        /* NOTE: This currently doesn't work */
-
-        printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n");
-
-        if(request_firmware(NULL, "sample_driver_fw", &ghost_device)!=0)
-        {
-                printk(KERN_ERR
-                       "firmware_sample_driver: Firmware load failed\n");
-                return;
-        }
-        
-        /* request_firmware blocks until userspace finished, so at
-         * this point the firmware should be already in the device */
-
-        /* finish setting up the device */
-}
-static void sample_probe_async_cont(const struct firmware *fw, void *context)
-{
-        if(!fw){
-                printk(KERN_ERR
-                       "firmware_sample_driver: firmware load failed\n");
-                return;
-        }
-
-        printk(KERN_INFO "firmware_sample_driver: device pointer \"%s\"\n",
-               (char *)context);
-        sample_firmware_load(fw->data, fw->size);
-}
-static void sample_probe_async(void)
-{
-        /* Let's say that I can't sleep */
-        int error;
-        error = request_firmware_nowait (THIS_MODULE, FW_ACTION_NOHOTPLUG,
-                                         "sample_driver_fw", &ghost_device,
-                                         "my device pointer",
-                                         sample_probe_async_cont);
-        if(error){
-                printk(KERN_ERR 
-                       "firmware_sample_driver:"
-                       " request_firmware_nowait failed\n");
-        }
-}
-
-static int sample_init(void)
-{
-        device_initialize(&ghost_device);
-        /* since there is no real hardware insertion I just call the
-         * sample probe functions here */
-        sample_probe_specific();
-        sample_probe_default();
-        sample_probe_async();
-        return 0;
-}
-static void __exit sample_exit(void)
-{
-}
-
-module_init (sample_init);
-module_exit (sample_exit);
-
-MODULE_LICENSE("GPL");
diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c
deleted file mode 100644
index 2de62854f0e5..000000000000
--- a/Documentation/firmware_class/firmware_sample_firmware_class.c
+++ /dev/null
@@ -1,207 +0,0 @@
-/*
- * firmware_sample_firmware_class.c -
- *
- * Copyright (c) 2003 Manuel Estrada Sainz
- *
- * NOTE: This is just a probe of concept, if you think that your driver would
- * be well served by this mechanism please contact me first.
- *
- * DON'T USE THIS CODE AS IS
- *
- */
-
-#include <linux/device.h>
-#include <linux/module.h>
-#include <linux/init.h>
-#include <linux/timer.h>
-#include <linux/slab.h>
-#include <linux/string.h>
-#include <linux/firmware.h>
-
-
-MODULE_AUTHOR("Manuel Estrada Sainz");
-MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
-MODULE_LICENSE("GPL");
-
-static inline struct class_device *to_class_dev(struct kobject *obj)
-{
-        return container_of(obj,struct class_device,kobj);
-}
-static inline
-struct class_device_attribute *to_class_dev_attr(struct attribute *_attr)
-{
-        return container_of(_attr,struct class_device_attribute,attr);
-}
-
-int sysfs_create_bin_file(struct kobject * kobj, struct bin_attribute * attr);
-int sysfs_remove_bin_file(struct kobject * kobj, struct bin_attribute * attr);
-
-struct firmware_priv {
-        char fw_id[FIRMWARE_NAME_MAX];
-        s32 loading:2;
-        u32 abort:1;
-};
-
-extern struct class firmware_class;
-
-static ssize_t firmware_loading_show(struct class_device *class_dev, char *buf)
-{
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-        return sprintf(buf, "%d\n", fw_priv->loading);
-}
-static ssize_t firmware_loading_store(struct class_device *class_dev,
-                                      const char *buf, size_t count)
-{
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-        int prev_loading = fw_priv->loading;
-
-        fw_priv->loading = simple_strtol(buf, NULL, 10);
-        
-        switch(fw_priv->loading){
-        case -1:
-                /* abort load an panic */
-                break;
-        case 1:
-                /* setup load */
-                break;
-        case 0:
-                if(prev_loading==1){
-                        /* finish load and get the device back to working
-                         * state */
-                }
-                break;
-        }
-
-        return count;
-}
-static CLASS_DEVICE_ATTR(loading, 0644,
-                         firmware_loading_show, firmware_loading_store);
-
-static ssize_t firmware_data_read(struct kobject *kobj,
-                                  struct bin_attribute *bin_attr,
-                                  char *buffer, loff_t offset, size_t count)
-{
-        struct class_device *class_dev = to_class_dev(kobj);
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-
-        /* read from the devices firmware memory */
-
-        return count;
-}
-static ssize_t firmware_data_write(struct kobject *kobj,
-                                   struct bin_attribute *bin_attr,
-                                   char *buffer, loff_t offset, size_t count)
-{
-        struct class_device *class_dev = to_class_dev(kobj);
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-
-        /* write to the devices firmware memory */
-
-        return count;
-}
-static struct bin_attribute firmware_attr_data = {
-        .attr = {.name = "data", .mode = 0644},
-        .size = 0,
-        .read = firmware_data_read,
-        .write = firmware_data_write,
-};
-static int fw_setup_class_device(struct class_device *class_dev,
-                                 const char *fw_name,
-                                 struct device *device)
-{
-        int retval;
-        struct firmware_priv *fw_priv;
-
-        fw_priv = kzalloc(sizeof(struct firmware_priv), GFP_KERNEL);
-        if (!fw_priv) {
-                retval = -ENOMEM;
-                goto out;
-        }
-
-        memset(class_dev, 0, sizeof(*class_dev));
-
-        strncpy(fw_priv->fw_id, fw_name, FIRMWARE_NAME_MAX);
-        fw_priv->fw_id[FIRMWARE_NAME_MAX-1] = '\0';
-
-        strncpy(class_dev->class_id, device->bus_id, BUS_ID_SIZE);
-        class_dev->class_id[BUS_ID_SIZE-1] = '\0';
-        class_dev->dev = device;
-
-        class_dev->class = &firmware_class,
-        class_set_devdata(class_dev, fw_priv);
-        retval = class_device_register(class_dev);
-        if (retval){
-                printk(KERN_ERR "%s: class_device_register failed\n",
-                       __FUNCTION__);
-                goto error_free_fw_priv;
-        }
-
-        retval = sysfs_create_bin_file(&class_dev->kobj, &firmware_attr_data);
-        if (retval){
-                printk(KERN_ERR "%s: sysfs_create_bin_file failed\n",
-                       __FUNCTION__);
-                goto error_unreg_class_dev;
-        }
-
-        retval = class_device_create_file(class_dev,
-                                          &class_device_attr_loading);
-        if (retval){
-                printk(KERN_ERR "%s: class_device_create_file failed\n",
-                       __FUNCTION__);
-                goto error_remove_data;
-        }
-
-        goto out;
-        
-error_remove_data:
-        sysfs_remove_bin_file(&class_dev->kobj, &firmware_attr_data);
-error_unreg_class_dev:
-        class_device_unregister(class_dev);
-error_free_fw_priv:
-        kfree(fw_priv);
-out:
-        return retval;
-}
-static void fw_remove_class_device(struct class_device *class_dev)
-{
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-
-        class_device_remove_file(class_dev, &class_device_attr_loading);
-        sysfs_remove_bin_file(&class_dev->kobj, &firmware_attr_data);
-        class_device_unregister(class_dev);
-}
-
-static struct class_device *class_dev;
-
-static struct device my_device = {
-        .bus_id    = "my_dev0",
-};
-
-static int __init firmware_sample_init(void)
-{
-        int error;
-
-        device_initialize(&my_device);
-        class_dev = kmalloc(sizeof(struct class_device), GFP_KERNEL);
-        if(!class_dev)
-                return -ENOMEM;
-
-        error = fw_setup_class_device(class_dev, "my_firmware_image",
-                                      &my_device);
-        if(error){
-                kfree(class_dev);
-                return error;
-        }
-        return 0;
-
-}
-static void __exit firmware_sample_exit(void)
-{
-        struct firmware_priv *fw_priv = class_get_devdata(class_dev);
-        fw_remove_class_device(class_dev);
-        kfree(fw_priv);
-        kfree(class_dev);
-}
-module_init(firmware_sample_init);
-module_exit(firmware_sample_exit);
-
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 54630095aa3c..c35ca9e40d4c 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -107,6 +107,16 @@ type of GPIO controller, and on one particular board 80-95 with an FPGA.
 The numbers need not be contiguous; either of those platforms could also
 use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
 
+If you want to initialize a structure with an invalid GPIO number, use
+some negative number (perhaps "-EINVAL"); that will never be valid.  To
+test if a number could reference a GPIO, you may use this predicate:
+
+        int gpio_is_valid(int number);
+
+A number that's not valid will be rejected by calls which may request
+or free GPIOs (see below).  Other numbers may also be rejected; for
+example, a number might be valid but unused on a given board.
+
 Whether a platform supports multiple GPIO controllers is currently a
 platform-specific implementation issue.
 
diff --git a/Documentation/highuid.txt b/Documentation/highuid.txt
index 76034d9dbfc0..6bad6f1d1cac 100644
--- a/Documentation/highuid.txt
+++ b/Documentation/highuid.txt
@@ -28,8 +28,6 @@ What's left to be done for 32-bit UIDs on all Linux architectures:
   uses the 32-bit UID system calls properly otherwise.
 
   This affects at least:
-        SunOS emulation
-        Solaris emulation
         iBCS on Intel
 
         sparc32 emulation on sparc64
diff --git a/Documentation/hwmon/adt7473 b/Documentation/hwmon/adt7473
index 22d8b19046ab..2126de34c711 100644
--- a/Documentation/hwmon/adt7473
+++ b/Documentation/hwmon/adt7473
@@ -69,7 +69,8 @@ point2: Set the pwm speed at a higher temperature bound.
 
 The ADT7473 will scale the pwm between the lower and higher pwm speed when
 the temperature is between the two temperature boundaries.  PWM values range
-from 0 (off) to 255 (full speed).
+from 0 (off) to 255 (full speed).  Fan speed will be set to maximum when the
+temperature sensor associated with the PWM control exceeds temp#_max.
 
 Notes
 -----
diff --git a/Documentation/hwmon/ibmaem b/Documentation/hwmon/ibmaem
new file mode 100644
index 000000000000..2fefaf582a43
--- /dev/null
+++ b/Documentation/hwmon/ibmaem
@@ -0,0 +1,37 @@
+Kernel driver ibmaem
+======================
+
+Supported systems:
+  * Any recent IBM System X server with Active Energy Manager support.
+    This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,
+    x3950 M2, and certain HS2x/LS2x/QS2x blades.  The IPMI host interface
+    driver ("ipmi-si") needs to be loaded for this driver to do anything.
+    Prefix: 'ibmaem'
+    Datasheet: Not available
+
+Author: Darrick J. Wong
+
+Description
+-----------
+
+This driver implements sensor reading support for the energy and power
+meters available on various IBM System X hardware through the BMC.  All
+sensor banks will be exported as platform devices; this driver can talk
+to both v1 and v2 interfaces.  This driver is completely separate from the
+older ibmpex driver.
+
+The v1 AEM interface has a simple set of features to monitor energy use.
+There is a register that displays an estimate of raw energy consumption
+since the last BMC reset, and a power sensor that returns average power
+use over a configurable interval.
+
+The v2 AEM interface is a bit more sophisticated, being able to present
+a wider range of energy and power use registers, the power cap as
+set by the AEM software, and temperature sensors.
+
+Special Features
+----------------
+
+The "power_cap" value displays the current system power cap, as set by
+the Active Energy Manager software.  Setting the power cap from the host
+is not currently supported.
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index f4a8ebc1ef1a..2d845730d4e0 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -2,17 +2,12 @@ Naming and data format standards for sysfs files
 ------------------------------------------------
 
 The libsensors library offers an interface to the raw sensors data
-through the sysfs interface. See libsensors documentation and source for
-further information. As of writing this document, libsensors
-(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating
-support for any given chip requires modifying the library's code.
-This is because libsensors was written for the procfs interface
-older kernel modules were using, which wasn't standardized enough.
-Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
-support for the sysfs interface, though.
-
-The new sysfs interface was designed to be as chip-independent as
-possible.
+through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
+completely chip-independent. It assumes that all the kernel drivers
+implement the standard sysfs interface described in this document.
+This makes adding or updating support for any given chip very easy, as
+libsensors, and applications using it, do not need to be modified.
+This is a major improvement compared to lm-sensors 2.
 
 Note that motherboards vary widely in the connections to sensor chips.
 There is no standard that ensures, for example, that the second
@@ -35,19 +30,17 @@ access this data in a simple and consistent way. That said, such programs
 will have to implement conversion, labeling and hiding of inputs. For
 this reason, it is still not recommended to bypass the library.
 
-If you are developing a userspace application please send us feedback on
-this standard.
-
-Note that this standard isn't completely established yet, so it is subject
-to changes. If you are writing a new hardware monitoring driver those
-features can't seem to fit in this interface, please contact us with your
-extension proposal. Keep in mind that backward compatibility must be
-preserved.
-
 Each chip gets its own directory in the sysfs /sys/devices tree.  To
 find all sensor chips, it is easier to follow the device symlinks from
 /sys/class/hwmon/hwmon*.
 
+Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
+in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
+in the hwmon "class" device directory are also supported. Complex drivers
+(e.g. drivers for multifunction chips) may want to use this possibility to
+avoid namespace pollution. The only drawback will be that older versions of
+libsensors won't support the driver in question.
+
 All sysfs values are fixed point numbers.
 
 There is only one value per file, unlike the older /proc specification.
diff --git a/Documentation/hwmon/w83l785ts b/Documentation/hwmon/w83l785ts
index 1841cedc25b2..bd1fa9d4468d 100644
--- a/Documentation/hwmon/w83l785ts
+++ b/Documentation/hwmon/w83l785ts
@@ -33,7 +33,8 @@ Known Issues
 ------------
 
 On some systems (Asus), the BIOS is known to interfere with the driver
-and cause read errors. The driver will retry a given number of times
+and cause read errors. Or maybe the W83L785TS-S chip is simply unreliable,
+we don't really know. The driver will retry a given number of times
 (5 by default) and then give up, returning the old value (or 0 if
 there is no old value). It seems to work well enough so that you should
 not notice anything. Thanks to James Bolt for helping test this feature.
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 60cca249e452..42c17c1fb3cd 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -51,26 +51,38 @@ A few combinations of the above flags are also defined for your convenience:
                                   the transparent emulation layer)
 
 
-ALGORITHM/ADAPTER IMPLEMENTATION
---------------------------------
+ADAPTER IMPLEMENTATION
+----------------------
 
-When you write a new algorithm driver, you will have to implement a
-function callback `functionality', that gets an i2c_adapter structure
-pointer as its only parameter:
+When you write a new adapter driver, you will have to implement a
+function callback `functionality'. Typical implementations are given
+below.
 
-  struct i2c_algorithm {
-        /* Many other things of course; check <linux/i2c.h>! */
-        u32 (*functionality) (struct i2c_adapter *);
+A typical SMBus-only adapter would list all the SMBus transactions it
+supports. This example comes from the i2c-piix4 driver:
+
+  static u32 piix4_func(struct i2c_adapter *adapter)
+  {
+        return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
+               I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
+               I2C_FUNC_SMBUS_BLOCK_DATA;
   }
 
-A typically implementation is given below, from i2c-algo-bit.c:
+A typical full-I2C adapter would use the following (from the i2c-pxa
+driver):
 
-  static u32 bit_func(struct i2c_adapter *adap)
+  static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
   {
-        return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
-               I2C_FUNC_PROTOCOL_MANGLING;
+        return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
   }
 
+I2C_FUNC_SMBUS_EMUL includes all the SMBus transactions (with the
+addition of I2C block transactions) which i2c-core can emulate using
+I2C_FUNC_I2C without any help from the adapter driver. The idea is
+to let the client drivers check for the support of SMBus functions
+without having to care whether the said functions are implemented in
+hardware by the adapter, or emulated in software by i2c-core on top
+of an I2C adapter.
 
 
 CLIENT CHECKING
@@ -78,36 +90,33 @@ CLIENT CHECKING
 
 Before a client tries to attach to an adapter, or even do tests to check
 whether one of the devices it supports is present on an adapter, it should
-check whether the needed functionality is present. There are two functions
-defined which should be used instead of calling the functionality hook
-in the algorithm structure directly:
-
-  /* Return the functionality mask */
-  extern u32 i2c_get_functionality (struct i2c_adapter *adap);
-
-  /* Return 1 if adapter supports everything we need, 0 if not. */
-  extern int i2c_check_functionality (struct i2c_adapter *adap, u32 func);
+check whether the needed functionality is present. The typical way to do
+this is (from the lm75 driver):
 
-This is a typical way to use these functions (from the writing-clients
-document):
-  int foo_detect_client(struct i2c_adapter *adapter, int address, 
-                          unsigned short flags, int kind)
+  static int lm75_detect(...)
   {
-        /* Define needed variables */
-
-        /* As the very first action, we check whether the adapter has the
-           needed functionality: we need the SMBus read_word_data,
-           write_word_data and write_byte functions in this example. */
-        if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
-                                             I2C_FUNC_SMBUS_WRITE_BYTE))
-                goto ERROR0;
-
-        /* Now we can do the real detection */
-
-        ERROR0:
-                /* Return an error */
+        (...)
+        if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+                                     I2C_FUNC_SMBUS_WORD_DATA))
+                goto exit;
+        (...)
   }
 
+Here, the lm75 driver checks if the adapter can do both SMBus byte data
+and SMBus word data transactions. If not, then the driver won't work on
+this adapter and there's no point in going on. If the check above is
+successful, then the driver knows that it can call the following
+functions: i2c_smbus_read_byte_data(), i2c_smbus_write_byte_data(),
+i2c_smbus_read_word_data() and i2c_smbus_write_word_data(). As a rule of
+thumb, the functionality constants you test for with
+i2c_check_functionality() should match exactly the i2c_smbus_* functions
+which you driver is calling.
+
+Note that the check above doesn't tell whether the functionalities are
+implemented in hardware by the underlying adapter or emulated in
+software by i2c-core. Client drivers don't have to care about this, as
+i2c-core will transparently implement SMBus transactions on top of I2C
+adapters.
 
 
 CHECKING THROUGH /DEV
@@ -116,19 +125,19 @@ CHECKING THROUGH /DEV
 If you try to access an adapter from a userspace program, you will have
 to use the /dev interface. You will still have to check whether the
 functionality you need is supported, of course. This is done using
-the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect
-program, is below:
+the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
+below:
 
   int file;
-  if (file = open("/dev/i2c-0",O_RDWR) < 0) {
+  if (file = open("/dev/i2c-0", O_RDWR) < 0) {
         /* Some kind of error handling */
         exit(1);
   }
-  if (ioctl(file,I2C_FUNCS,&funcs) < 0) {
+  if (ioctl(file, I2C_FUNCS, &funcs) < 0) {
         /* Some kind of error handling */
         exit(1);
   }
-  if (! (funcs & I2C_FUNC_SMBUS_QUICK)) {
+  if (!(funcs & I2C_FUNC_SMBUS_QUICK)) {
         /* Oops, the needed functionality (SMBus write_quick function) is
            not available! */
         exit(1);
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 8a653c60d25a..03f08fb491cc 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -1,5 +1,6 @@
 SMBus Protocol Summary
 ======================
+
 The following is a summary of the SMBus protocol. It applies to
 all revisions of the protocol (1.0, 1.1, and 2.0).
 Certain protocol features which are not supported by
@@ -8,6 +9,7 @@ this package are briefly described at the end of this document.
 Some adapters understand only the SMBus (System Management Bus) protocol,
 which is a subset from the I2C protocol. Fortunately, many devices use
 only the same subset, which makes it possible to put them on an SMBus.
+
 If you write a driver for some I2C device, please try to use the SMBus
 commands if at all possible (if the device uses only that subset of the
 I2C protocol). This makes it possible to use the device driver on both
@@ -15,7 +17,12 @@ SMBus adapters and I2C adapters (the SMBus command set is automatically
 translated to I2C on I2C adapters, but plain I2C commands can not be
 handled at all on most pure SMBus adapters).
 
-Below is a list of SMBus commands.
+Below is a list of SMBus protocol operations, and the functions executing
+them.  Note that the names used in the SMBus protocol specifications usually
+don't match these function names.  For some of the operations which pass a
+single data byte, the functions using SMBus protocol operation names execute
+a different protocol operation entirely.
+
 
 Key to symbols
 ==============
@@ -35,17 +42,16 @@ Count (8 bits): A data byte containing the length of a block operation.
 [..]: Data sent by I2C device, as opposed to data sent by the host adapter.
 
 
-SMBus Write Quick
-=================
+SMBus Quick Command:  i2c_smbus_write_quick()
+=============================================
 
 This sends a single bit to the device, at the place of the Rd/Wr bit.
-There is no equivalent Read Quick command.
 
 A Addr Rd/Wr [A] P
 
 
-SMBus Read Byte
-===============
+SMBus Receive Byte:  i2c_smbus_read_byte()
+==========================================
 
 This reads a single byte from a device, without specifying a device
 register. Some devices are so simple that this interface is enough; for
@@ -55,17 +61,17 @@ the previous SMBus command.
 S Addr Rd [A] [Data] NA P
 
 
-SMBus Write Byte
-================
+SMBus Send Byte:  i2c_smbus_write_byte()
+========================================
 
-This is the reverse of Read Byte: it sends a single byte to a device.
-See Read Byte for more information.
+This operation is the reverse of Receive Byte: it sends a single byte
+to a device.  See Receive Byte for more information.
 
 S Addr Wr [A] Data [A] P
 
 
-SMBus Read Byte Data
-====================
+SMBus Read Byte:  i2c_smbus_read_byte_data()
+============================================
 
 This reads a single byte from a device, from a designated register.
 The register is specified through the Comm byte.
@@ -73,30 +79,30 @@ The register is specified through the Comm byte.
 S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
 
 
-SMBus Read Word Data
-====================
+SMBus Read Word:  i2c_smbus_read_word_data()
+============================================
 
-This command is very like Read Byte Data; again, data is read from a
+This operation is very like Read Byte; again, data is read from a
 device, from a designated register that is specified through the Comm
 byte. But this time, the data is a complete word (16 bits).
 
 S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
 
 
-SMBus Write Byte Data
-=====================
+SMBus Write Byte:  i2c_smbus_write_byte_data()
+==============================================
 
 This writes a single byte to a device, to a designated register. The
 register is specified through the Comm byte. This is the opposite of
-the Read Byte Data command.
+the Read Byte operation.
 
 S Addr Wr [A] Comm [A] Data [A] P
 
 
-SMBus Write Word Data
-=====================
+SMBus Write Word:  i2c_smbus_write_word_data()
+==============================================
 
-This is the opposite operation of the Read Word Data command. 16 bits
+This is the opposite of the Read Word operation. 16 bits
 of data is written to a device, to the designated register that is
 specified through the Comm byte. 
 
@@ -113,8 +119,8 @@ S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
                              S Addr Rd [A] [DataLow] A [DataHigh] NA P
 
 
-SMBus Block Read
-================
+SMBus Block Read:  i2c_smbus_read_block_data()
+==============================================
 
 This command reads a block of up to 32 bytes from a device, from a 
 designated register that is specified through the Comm byte. The amount
@@ -124,8 +130,8 @@ S Addr Wr [A] Comm [A]
            S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
 
 
-SMBus Block Write
-=================
+SMBus Block Write:  i2c_smbus_write_block_data()
+================================================
 
 The opposite of the Block Read command, this writes up to 32 bytes to 
 a device, to a designated register that is specified through the
@@ -134,10 +140,11 @@ Comm byte. The amount of data is specified in the Count byte.
 S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
 
 
-SMBus Block Process Call
-========================
+SMBus Block Write - Block Read Process Call
+===========================================
 
-SMBus Block Process Call was introduced in Revision 2.0 of the specification.
+SMBus Block Write - Block Read Process Call was introduced in
+Revision 2.0 of the specification.
 
 This command selects a device register (through the Comm byte), sends
 1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return.
@@ -159,13 +166,16 @@ alerting device's address.
 
 Packet Error Checking (PEC)
 ===========================
+
 Packet Error Checking was introduced in Revision 1.1 of the specification.
 
-PEC adds a CRC-8 error-checking byte to all transfers.
+PEC adds a CRC-8 error-checking byte to transfers using it, immediately
+before the terminating STOP.
 
 
 Address Resolution Protocol (ARP)
 =================================
+
 The Address Resolution Protocol was introduced in Revision 2.0 of
 the specification. It is a higher-layer protocol which uses the
 messages above.
@@ -177,14 +187,17 @@ require PEC checksums.
 
 I2C Block Transactions
 ======================
+
 The following I2C block transactions are supported by the
 SMBus layer and are described here for completeness.
+They are *NOT* defined by the SMBus specification.
+
 I2C block transactions do not limit the number of bytes transferred
 but the SMBus layer places a limit of 32 bytes.
 
 
-I2C Block Read
-==============
+I2C Block Read:  i2c_smbus_read_i2c_block_data()
+================================================
 
 This command reads a block of bytes from a device, from a 
 designated register that is specified through the Comm byte.
@@ -203,8 +216,8 @@ S Addr Wr [A] Comm1 [A] Comm2 [A]
            S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
 
 
-I2C Block Write
-===============
+I2C Block Write:  i2c_smbus_write_i2c_block_data()
+==================================================
 
 The opposite of the Block Read command, this writes bytes to 
 a device, to a designated register that is specified through the
@@ -212,5 +225,3 @@ Comm byte. Note that command lengths of 0, 2, or more bytes are
 supported as they are indistinguishable from data.
 
 S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
-
-
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index bfb0a5520817..d4cd4126d1ad 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -25,12 +25,23 @@ routines, and should be zero-initialized except for fields with data you
 provide.  A client structure holds device-specific information like the
 driver model device node, and its I2C address.
 
+/* iff driver uses driver model ("new style") binding model: */
+
+static struct i2c_device_id foo_idtable[] = {
+        { "foo", my_id_for_foo },
+        { "bar", my_id_for_bar },
+        { }
+};
+
+MODULE_DEVICE_TABLE(i2c, foo_idtable);
+
 static struct i2c_driver foo_driver = {
         .driver = {
                 .name   = "foo",
         },
 
         /* iff driver uses driver model ("new style") binding model: */
+        .id_table       = foo_ids,
         .probe          = foo_probe,
         .remove         = foo_remove,
 
@@ -164,7 +175,8 @@ I2C device drivers using this binding model work just like any other
 kind of driver in Linux:  they provide a probe() method to bind to
 those devices, and a remove() method to unbind.
 
-        static int foo_probe(struct i2c_client *client);
+        static int foo_probe(struct i2c_client *client,
+                             const struct i2c_device_id *id);
         static int foo_remove(struct i2c_client *client);
 
 Remember that the i2c_driver does not create those client handles.  The
@@ -172,10 +184,9 @@ handle may be used during foo_probe().  If foo_probe() reports success
 (zero not a negative status code) it may save the handle and use it until
 foo_remove() returns.  That binding model is used by most Linux drivers.
 
-Drivers match devices when i2c_client.driver_name and the driver name are
-the same; this approach is used in several other busses that don't have
-device typing support in the hardware.  The driver and module name should
-match, so hotplug/coldplug mechanisms will modprobe the driver.
+The probe function is called when an entry in the id_table name field
+matches the device's name. It is passed the entry that was matched so
+the driver knows which one in the table matched.
 
 
 Device Creation (Standard driver model)
diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/i386/IO-APIC.txt
index f95166645d29..30b4c714fbe1 100644
--- a/Documentation/i386/IO-APIC.txt
+++ b/Documentation/i386/IO-APIC.txt
@@ -70,7 +70,7 @@ Every PCI card emits a PCI IRQ, which can be INTA, INTB, INTC or INTD:
 
 These INTA-D PCI IRQs are always 'local to the card', their real meaning
 depends on which slot they are in. If you look at the daisy chaining diagram,
-a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
+a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ4 of
 the PCI chipset. Most cards issue INTA, this creates optimal distribution
 between the PIRQ lines. (distributing IRQ sources properly is not a
 necessity, PCI IRQs can be shared at will, but it's a good for performance
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
index fc49b79bc1ab..95ad15c3b01f 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/i386/boot.txt
@@ -40,8 +40,18 @@ Protocol 2.05:	(Kernel 2.6.20) Make protected mode kernel relocatable.
                 Introduce relocatable_kernel and kernel_alignment fields.
 
 Protocol 2.06:  (Kernel 2.6.22) Added a field that contains the size of
-                the boot command line
+                the boot command line.
 
+Protocol 2.07:  (Kernel 2.6.24) Added paravirtualised boot protocol.
+                Introduced hardware_subarch and hardware_subarch_data
+                and KEEP_SEGMENTS flag in load_flags.
+
+Protocol 2.08:  (Kernel 2.6.26) Added crc32 checksum and ELF format
+                payload. Introduced payload_offset and payload length
+                fields to aid in locating the payload.
+
+Protocol 2.09:  (Kernel 2.6.26) Added a field of 64-bit physical
+                pointer to single linked list of struct setup_data.
 
 **** MEMORY LAYOUT
 
@@ -170,6 +180,10 @@ Offset	Proto	Name		Meaning
 0238/4  2.06+   cmdline_size    Maximum size of the kernel command line
 023C/4  2.07+   hardware_subarch Hardware subarchitecture
 0240/8  2.07+   hardware_subarch_data Subarchitecture-specific data
+0248/4  2.08+   payload_offset  Offset of kernel payload
+024C/4  2.08+   payload_length  Length of kernel payload
+0250/8  2.09+   setup_data      64-bit physical pointer to linked list
+                                of struct setup_data
 
 (1) For backwards compatibility, if the setup_sects field contains 0, the
     real value is 4.
@@ -512,6 +526,32 @@ Protocol:	2.07+
 
   A pointer to data that is specific to hardware subarch
 
+Field name:     payload_offset
+Type:           read
+Offset/size:    0x248/4
+Protocol:       2.08+
+
+  If non-zero then this field contains the offset from the end of the
+  real-mode code to the payload.
+
+  The payload may be compressed. The format of both the compressed and
+  uncompressed data should be determined using the standard magic
+  numbers. Currently only gzip compressed ELF is used.
+  
+Field name:     payload_length
+Type:           read
+Offset/size:    0x24c/4
+Protocol:       2.08+
+
+  The length of the payload.
+
+**** THE IMAGE CHECKSUM
+
+From boot protocol version 2.08 onwards the CRC-32 is calculated over
+the entire file using the characteristic polynomial 0x04C11DB7 and an
+initial remainder of 0xffffffff.  The checksum is appended to the
+file; therefore the CRC of the file up to the limit specified in the
+syssize field of the header is always 0.
 
 **** THE KERNEL COMMAND LINE
 
@@ -544,6 +584,28 @@ command line is entered using the following protocol:
         covered by setup_move_size, so you may need to adjust this
         field.
 
+Field name:     setup_data
+Type:           write (obligatory)
+Offset/size:    0x250/8
+Protocol:       2.09+
+
+  The 64-bit physical pointer to NULL terminated single linked list of
+  struct setup_data. This is used to define a more extensible boot
+  parameters passing mechanism. The definition of struct setup_data is
+  as follow:
+
+  struct setup_data {
+          u64 next;
+          u32 type;
+          u32 len;
+          u8  data[0];
+  };
+
+  Where, the next is a 64-bit physical pointer to the next node of
+  linked list, the next field of the last node is 0; the type is used
+  to identify the contents of data; the len is the length of data
+  field; the data holds the real payload.
+
 
 **** MEMORY LAYOUT OF THE REAL-MODE CODE
 
diff --git a/Documentation/ia64/kvm.txt b/Documentation/ia64/kvm.txt
new file mode 100644
index 000000000000..bec9d815da33
--- /dev/null
+++ b/Documentation/ia64/kvm.txt
@@ -0,0 +1,82 @@
+Currently, kvm module in EXPERIMENTAL stage on IA64. This means that
+interfaces are not stable enough to use. So, plase had better don't run
+critical applications in virtual machine. We will try our best to make it
+strong in future versions!
+                                Guide: How to boot up guests on kvm/ia64
+
+This guide is to describe how to enable kvm support for IA-64 systems.
+
+1. Get the kvm source from git.kernel.org.
+        Userspace source:
+                git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
+        Kernel Source:
+                git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git
+
+2. Compile the source code.
+        2.1 Compile userspace code:
+                (1)cd ./kvm-userspace
+                (2)./configure
+                (3)cd kernel
+                (4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)
+                (5)cd ..
+                (6)make qemu
+                (7)cd qemu; make install
+
+        2.2 Compile kernel source code:
+                (1) cd ./$kernel_dir
+                (2) Make menuconfig
+                (3) Enter into virtualization option, and choose kvm.
+                (4) make
+                (5) Once (4) done, make modules_install
+                (6) Make initrd, and use new kernel to reboot up host machine.
+                (7) Once (6) done, cd $kernel_dir/arch/ia64/kvm
+                (8) insmod kvm.ko; insmod kvm-intel.ko
+
+Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.
+
+3. Get Guest Firmware named as Flash.fd, and put it under right place:
+        (1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.
+
+        (2) If you have no firmware at hand, Please download its source from
+                hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg
+            you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.
+
+        (3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu
+
+4. Boot up Linux or Windows guests:
+        4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.
+
+        4.2 Boot up guests use the following command.
+                /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
+                (xx is the number of virtual processors for the guest, now the maximum value is 4)
+
+5. Known possibile issue on some platforms with old Firmware.
+
+If meet strange host crashe issues, try to solve it through either of the following ways:
+
+(1): Upgrade your Firmware to the latest one.
+
+(2): Applying the below patch to kernel source.
+diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S
+index 0b53344..f02b0f7 100644
+--- a/arch/ia64/kernel/pal.S
++++ b/arch/ia64/kernel/pal.S
+@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)
+        mov ar.pfs = loc1
+        mov rp = loc0
+        ;;
+-       srlz.d                          // seralize restoration of psr.l
++       srlz.i                  // seralize restoration of psr.l
++       ;;
+        br.ret.sptk.many b0
+ END(ia64_pal_call_static)
+
+6. Bug report:
+        If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.
+        https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/
+
+Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!
+
+
+                                                                Xiantao Zhang <xiantao.zhang@intel.com>
+                                                                                        2008.3.10
diff --git a/Documentation/ide/ide-tape.txt b/Documentation/ide/ide-tape.txt
index 658f271a373f..3f348a0b21d8 100644
--- a/Documentation/ide/ide-tape.txt
+++ b/Documentation/ide/ide-tape.txt
@@ -1,146 +1,65 @@
-/*
- * IDE ATAPI streaming tape driver.
- *
- * This driver is a part of the Linux ide driver.
- *
- * The driver, in co-operation with ide.c, basically traverses the
- * request-list for the block device interface. The character device
- * interface, on the other hand, creates new requests, adds them
- * to the request-list of the block device, and waits for their completion.
- *
- * Pipelined operation mode is now supported on both reads and writes.
- *
- * The block device major and minor numbers are determined from the
- * tape's relative position in the ide interfaces, as explained in ide.c.
- *
- * The character device interface consists of the following devices:
- *
- * ht0          major 37, minor 0       first  IDE tape, rewind on close.
- * ht1          major 37, minor 1       second IDE tape, rewind on close.
- * ...
- * nht0         major 37, minor 128     first  IDE tape, no rewind on close.
- * nht1         major 37, minor 129     second IDE tape, no rewind on close.
- * ...
- *
- * The general magnetic tape commands compatible interface, as defined by
- * include/linux/mtio.h, is accessible through the character device.
- *
- * General ide driver configuration options, such as the interrupt-unmask
- * flag, can be configured by issuing an ioctl to the block device interface,
- * as any other ide device.
- *
- * Our own ide-tape ioctl's can be issued to either the block device or
- * the character device interface.
- *
- * Maximal throughput with minimal bus load will usually be achieved in the
- * following scenario:
- *
- *      1.      ide-tape is operating in the pipelined operation mode.
- *      2.      No buffering is performed by the user backup program.
- *
- * Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
- *
- * Here are some words from the first releases of hd.c, which are quoted
- * in ide.c and apply here as well:
- *
- * | Special care is recommended.  Have Fun!
- *
- *
- * An overview of the pipelined operation mode.
- *
- * In the pipelined write mode, we will usually just add requests to our
- * pipeline and return immediately, before we even start to service them. The
- * user program will then have enough time to prepare the next request while
- * we are still busy servicing previous requests. In the pipelined read mode,
- * the situation is similar - we add read-ahead requests into the pipeline,
- * before the user even requested them.
- *
- * The pipeline can be viewed as a "safety net" which will be activated when
- * the system load is high and prevents the user backup program from keeping up
- * with the current tape speed. At this point, the pipeline will get
- * shorter and shorter but the tape will still be streaming at the same speed.
- * Assuming we have enough pipeline stages, the system load will hopefully
- * decrease before the pipeline is completely empty, and the backup program
- * will be able to "catch up" and refill the pipeline again.
- *
- * When using the pipelined mode, it would be best to disable any type of
- * buffering done by the user program, as ide-tape already provides all the
- * benefits in the kernel, where it can be done in a more efficient way.
- * As we will usually not block the user program on a request, the most
- * efficient user code will then be a simple read-write-read-... cycle.
- * Any additional logic will usually just slow down the backup process.
- *
- * Using the pipelined mode, I get a constant over 400 KBps throughput,
- * which seems to be the maximum throughput supported by my tape.
- *
- * However, there are some downfalls:
- *
- *      1.      We use memory (for data buffers) in proportional to the number
- *              of pipeline stages (each stage is about 26 KB with my tape).
- *      2.      In the pipelined write mode, we cheat and postpone error codes
- *              to the user task. In read mode, the actual tape position
- *              will be a bit further than the last requested block.
- *
- * Concerning (1):
- *
- *      1.      We allocate stages dynamically only when we need them. When
- *              we don't need them, we don't consume additional memory. In
- *              case we can't allocate stages, we just manage without them
- *              (at the expense of decreased throughput) so when Linux is
- *              tight in memory, we will not pose additional difficulties.
- *
- *      2.      The maximum number of stages (which is, in fact, the maximum
- *              amount of memory) which we allocate is limited by the compile
- *              time parameter IDETAPE_MAX_PIPELINE_STAGES.
- *
- *      3.      The maximum number of stages is a controlled parameter - We
- *              don't start from the user defined maximum number of stages
- *              but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we
- *              will not even allocate this amount of stages if the user
- *              program can't handle the speed). We then implement a feedback
- *              loop which checks if the pipeline is empty, and if it is, we
- *              increase the maximum number of stages as necessary until we
- *              reach the optimum value which just manages to keep the tape
- *              busy with minimum allocated memory or until we reach
- *              IDETAPE_MAX_PIPELINE_STAGES.
- *
- * Concerning (2):
- *
- *      In pipelined write mode, ide-tape can not return accurate error codes
- *      to the user program since we usually just add the request to the
- *      pipeline without waiting for it to be serviced. In case an error
- *      occurs, I will report it on the next user request.
- *
- *      In the pipelined read mode, subsequent read requests or forward
- *      filemark spacing will perform correctly, as we preserve all blocks
- *      and filemarks which we encountered during our excess read-ahead.
- *
- *      For accurate tape positioning and error reporting, disabling
- *      pipelined mode might be the best option.
- *
- * You can enable/disable/tune the pipelined operation mode by adjusting
- * the compile time parameters below.
- *
- *
- *      Possible improvements.
- *
- *      1.      Support for the ATAPI overlap protocol.
- *
- *              In order to maximize bus throughput, we currently use the DSC
- *              overlap method which enables ide.c to service requests from the
- *              other device while the tape is busy executing a command. The
- *              DSC overlap method involves polling the tape's status register
- *              for the DSC bit, and servicing the other device while the tape
- *              isn't ready.
- *
- *              In the current QIC development standard (December 1995),
- *              it is recommended that new tape drives will *in addition*
- *              implement the ATAPI overlap protocol, which is used for the
- *              same purpose - efficient use of the IDE bus, but is interrupt
- *              driven and thus has much less CPU overhead.
- *
- *              ATAPI overlap is likely to be supported in most new ATAPI
- *              devices, including new ATAPI cdroms, and thus provides us
- *              a method by which we can achieve higher throughput when
- *              sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
- */
+IDE ATAPI streaming tape driver.
+
+This driver is a part of the Linux ide driver.
+
+The driver, in co-operation with ide.c, basically traverses the
+request-list for the block device interface. The character device
+interface, on the other hand, creates new requests, adds them
+to the request-list of the block device, and waits for their completion.
+
+The block device major and minor numbers are determined from the
+tape's relative position in the ide interfaces, as explained in ide.c.
+
+The character device interface consists of the following devices:
+
+ht0             major 37, minor 0       first  IDE tape, rewind on close.
+ht1             major 37, minor 1       second IDE tape, rewind on close.
+...
+nht0            major 37, minor 128     first  IDE tape, no rewind on close.
+nht1            major 37, minor 129     second IDE tape, no rewind on close.
+...
+
+The general magnetic tape commands compatible interface, as defined by
+include/linux/mtio.h, is accessible through the character device.
+
+General ide driver configuration options, such as the interrupt-unmask
+flag, can be configured by issuing an ioctl to the block device interface,
+as any other ide device.
+
+Our own ide-tape ioctl's can be issued to either the block device or
+the character device interface.
+
+Maximal throughput with minimal bus load will usually be achieved in the
+following scenario:
+
+     1. ide-tape is operating in the pipelined operation mode.
+     2. No buffering is performed by the user backup program.
+
+Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
+
+Here are some words from the first releases of hd.c, which are quoted
+in ide.c and apply here as well:
+
+| Special care is recommended.  Have Fun!
+
+Possible improvements:
+
+1. Support for the ATAPI overlap protocol.
+
+In order to maximize bus throughput, we currently use the DSC
+overlap method which enables ide.c to service requests from the
+other device while the tape is busy executing a command. The
+DSC overlap method involves polling the tape's status register
+for the DSC bit, and servicing the other device while the tape
+isn't ready.
+
+In the current QIC development standard (December 1995),
+it is recommended that new tape drives will *in addition*
+implement the ATAPI overlap protocol, which is used for the
+same purpose - efficient use of the IDE bus, but is interrupt
+driven and thus has much less CPU overhead.
+
+ATAPI overlap is likely to be supported in most new ATAPI
+devices, including new ATAPI cdroms, and thus provides us
+a method by which we can achieve higher throughput when
+sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt
index 818676aad45a..0c78f4b1d9d9 100644
--- a/Documentation/ide/ide.txt
+++ b/Documentation/ide/ide.txt
@@ -71,29 +71,6 @@ This driver automatically probes for most IDE interfaces (including all PCI
 ones), for the drives/geometries attached to those interfaces, and for the IRQ
 lines being used by the interfaces (normally 14, 15 for ide0/ide1).
 
-For special cases, interfaces may be specified using kernel "command line"
-options.  For example,
-
-        ide3=0x168,0x36e,10     /* ioports 0x168-0x16f,0x36e, irq 10 */
-
-Normally the irq number need not be specified, as ide.c will probe for it:
-
-        ide3=0x168,0x36e        /* ioports 0x168-0x16f,0x36e */
-
-The standard port, and irq values are these:
-
-        ide0=0x1f0,0x3f6,14
-        ide1=0x170,0x376,15
-        ide2=0x1e8,0x3ee,11
-        ide3=0x168,0x36e,10
-
-Note that the first parameter reserves 8 contiguous ioports, whereas the
-second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.
-
-In all probability the device uses these ports and IRQs if it is attached
-to the appropriate ide channel.  Pass the parameter for the correct ide
-channel to the kernel, as explained above.
-
 Any number of interfaces may share a single IRQ if necessary, at a slight
 performance penalty, whether on separate cards or a single VLB card.
 The IDE driver automatically detects and handles this.  However, this may
@@ -105,27 +82,26 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
 For really weird situations, the apparent (fdisk) geometry can also be specified
 on the kernel "command line" using LILO.  The format of such lines is:
 
-        hdx=cyls,heads,sects
-or      hdx=cdrom
+        ide_core.chs=[interface_number.device_number]:cyls,heads,sects
+or      ide_core.cdrom=[interface_number.device_number]
 
-where hdx can be any of hda through hdh, Three values are required
-(cyls,heads,sects).  For example:
+For example:
 
-        hdc=1050,32,64  hdd=cdrom
+        ide_core.chs=1.0:1050,32,64  ide_core.cdrom=1.1
 
-either {hda,hdb} or {hdc,hdd}.  The results of successful auto-probing may
-override the physical geometry/irq specified, though the "original" geometry
-may be retained as the "logical" geometry for partitioning purposes (fdisk).
+The results of successful auto-probing may override the physical geometry/irq
+specified, though the "original" geometry may be retained as the "logical"
+geometry for partitioning purposes (fdisk).
 
 If the auto-probing during boot time confuses a drive (ie. the drive works
 with hd.c but not with ide.c), then an command line option may be specified
 for each drive for which you'd like the drive to skip the hardware
 probe/identification sequence.  For example:
 
-        hdb=noprobe
+        ide_core.noprobe=0.1
 or
-        hdc=768,16,32
-        hdc=noprobe
+        ide_core.chs=1.0:768,16,32
+        ide_core.noprobe=1.0
 
 Note that when only one IDE device is attached to an interface, it should be
 jumpered as "single" or "master", *not* "slave".  Many folks have had
@@ -141,9 +117,9 @@ If for some reason your cdrom drive is *not* found at boot time, you can force
 the probe to look harder by supplying a kernel command line parameter
 via LILO, such as:
 
-        hdc=cdrom       /* hdc = "master" on second interface */
+        ide_core.cdrom=1.0      /* "master" on second interface (hdc) */
 or
-        hdd=cdrom       /* hdd = "slave" on second interface */
+        ide_core.cdrom=1.1      /* "slave" on second interface (hdd) */
 
 For example, a GW2000 system might have a hard drive on the primary
 interface (/dev/hda) and an IDE cdrom drive on the secondary interface
@@ -184,13 +160,6 @@ provided it is mounted with the default block size of 1024 (as above).
 Please pass on any feedback on any of this stuff to the maintainer,
 whose address can be found in linux/MAINTAINERS.
 
-Note that if BOTH hd.c and ide.c are configured into the kernel,
-hd.c will normally be allowed to control the primary IDE interface.
-This is useful for older hardware that may be incompatible with ide.c,
-and still allows newer hardware to run on the 2nd/3rd/4th IDE ports
-under control of ide.c.   To have ide.c also "take over" the primary
-IDE port in this situation, use the "command line" parameter:  ide0=0x1f0
-
 The IDE driver is modularized.  The high level disk/CD-ROM/tape/floppy
 drivers can always be compiled as loadable modules, the chipset drivers
 can only be compiled into the kernel, and the core code (ide.c) can be
@@ -204,9 +173,7 @@ to /etc/modprobe.conf.
 
 When ide.c is used as a module, you can pass command line parameters to the
 driver using the "options=" keyword to insmod, while replacing any ',' with
-';'.  For example:
-
-        insmod ide.o options="ide0=serialize ide1=serialize ide2=0x1e8;0x3ee;11"
+';'.
 
 
 ================================================================================
@@ -214,81 +181,48 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
 Summary of ide driver parameters for kernel command line
 --------------------------------------------------------
 
- "hdx="  is recognized for all "x" from "a" to "u", such as "hdc".
-
- "idex=" is recognized for all "x" from "0" to "9", such as "ide1".
-
- "hdx=noprobe"          : drive may be present, but do not probe for it
-
- "hdx=none"             : drive is NOT present, ignore cmos and do not probe
-
- "hdx=nowerr"           : ignore the WRERR_STAT bit on this drive
-
- "hdx=cdrom"            : drive is present, and is a cdrom drive
-
- "hdx=cyl,head,sect"    : disk drive is present, with specified geometry
-
- "hdx=autotune"         : driver will attempt to tune interface speed
-                          to the fastest PIO mode supported,
-                          if possible for this drive only.
-                          Not fully supported by all chipset types,
-                          and quite likely to cause trouble with
-                          older/odd IDE drives.
-
- "hdx=nodma"            : disallow DMA
-
- "idebus=xx"            : inform IDE driver of VESA/PCI bus speed in MHz,
-                          where "xx" is between 20 and 66 inclusive,
-                          used when tuning chipset PIO modes.
-                          For PCI bus, 25 is correct for a P75 system,
-                          30 is correct for P90,P120,P180 systems,
-                          and 33 is used for P100,P133,P166 systems.
-                          If in doubt, use idebus=33 for PCI.
-                          As for VLB, it is safest to not specify it.
-                          Bigger values are safer than smaller ones.
+For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
+you need to explicitly enable probing by using "probe" kernel parameter,
+i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
 
- "idex=base"            : probe for an interface at the addr specified,
-                          where "base" is usually 0x1f0 or 0x170
-                          and "ctl" is assumed to be "base"+0x206
+* "ali14xx.probe" boot option when ali14xx driver is built-in the kernel
 
- "idex=base,ctl"        : specify both base and ctl
+* "probe" module parameter when ali14xx driver is compiled as module
+  ("modprobe ali14xx probe")
 
- "idex=base,ctl,irq"    : specify base, ctl, and irq number
+Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
+kernel paremeter to enable probing for VLB version of the chipset (PCI ones
+are detected automatically).
 
- "idex=serialize"       : do not overlap operations on idex. Please note
-                          that you will have to specify this option for
-                          both the respective primary and secondary channel
-                          to take effect.
+You also need to use "probe" kernel parameter for ide-4drives driver
+(support for IDE generic chipset with four drives on one port).
 
- "idex=four"            : four drives on idex and ide(x^1) share same ports
+To enable support for IDE doublers on Amiga use "doubler" kernel parameter
+for gayle host driver (i.e. "gayle.doubler" if the driver is built-in).
 
- "idex=reset"           : reset interface after probe
+To force ignoring cable detection (this should be needed only if you're using
+short 40-wires cable which cannot be automatically detected - if this is not
+a case please report it as a bug instead) use "ignore_cable" kernel parameter:
 
- "idex=ata66"           : informs the interface that it has an 80c cable
-                          for chipsets that are ATA-66 capable, but the
-                          ability to bit test for detection is currently
-                          unknown.
+* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in
+  (i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1")
 
- "ide=reverse"          : formerly called to pci sub-system, but now local.
+* "ignore_cable=[interface_number]" module parameter (for ide_core module)
+  if IDE is compiled as module
 
- "ide=doubler"          : probe/support IDE doublers on Amiga
+Other kernel parameters for ide_core are:
 
-There may be more options than shown -- use the source, Luke!
+* "nodma=[interface_number.device_number]" to disallow DMA for a device
 
-Everything else is rejected with a "BAD OPTION" message.
+* "noflush=[interface_number.device_number]" to disable flush requests
 
-For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
-you need to explicitly enable probing by using "probe" kernel parameter,
-i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
+* "noprobe=[interface_number.device_number]" to skip probing
 
-* "ali14xx.probe" boot option when ali14xx driver is built-in the kernel
+* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
 
-* "probe" module parameter when ali14xx driver is compiled as module
-  ("modprobe ali14xx probe")
+* "cdrom=[interface_number.device_number]" to force device as a CD-ROM
 
-Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
-kernel paremeter to enable probing for VLB version of the chipset (PCI ones
-are detected automatically).
+* "chs=[interface_number.device_number]" to force device as a disk (using CHS)
 
 ================================================================================
 
diff --git a/Documentation/ide/warm-plug-howto.txt b/Documentation/ide/warm-plug-howto.txt
new file mode 100644
index 000000000000..d5885468b072
--- /dev/null
+++ b/Documentation/ide/warm-plug-howto.txt
@@ -0,0 +1,13 @@
+
+IDE warm-plug HOWTO
+===================
+
+To warm-plug devices on a port 'idex':
+
+# echo -n "1" > /sys/class/ide_port/idex/delete_devices
+
+unplug old device(s) and plug new device(s)
+
+# echo -n "1" > /sys/class/ide_port/idex/scan
+
+done
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index c18363bd8d11..240ce7a56c40 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -183,6 +183,8 @@ Code	Seq#	Include File		Comments
 0xAC    00-1F   linux/raw.h
 0xAD    00      Netfilter device        in development:
                                         <mailto:rusty@rustcorp.com.au>  
+0xAE    all     linux/kvm.h             Kernel-based Virtual Machine
+                                        <mailto:kvm-devel@lists.sourceforge.net>
 0xB0    all     RATIO devices           in development:
                                         <mailto:vgo@ratio.de>
 0xB1    00-1F   PPPoX                   <mailto:mostrows@styx.uwaterloo.ca>
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index 649cb8799890..c412c245848f 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -104,14 +104,15 @@ applicable everywhere (see syntax).
   Reverse dependencies can only be used with boolean or tristate
   symbols.
   Note:
-        select is evil.... select will by brute force set a symbol
-        equal to 'y' without visiting the dependencies. So abusing
-        select you are able to select a symbol FOO even if FOO depends
-        on BAR that is not set. In general use select only for
-        non-visible symbols (no prompts anywhere) and for symbols with
-        no dependencies. That will limit the usefulness but on the
-        other hand avoid the illegal configurations all over. kconfig
-        should one day warn about such things.
+        select should be used with care. select will force
+        a symbol to a value without visiting the dependencies.
+        By abusing select you are able to select a symbol FOO even
+        if FOO depends on BAR that is not set.
+        In general use select only for non-visible symbols
+        (no prompts anywhere) and for symbols with no dependencies.
+        That will limit the usefulness but on the other hand avoid
+        the illegal configurations all over.
+        kconfig should one day warn about such things.
 
 - numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
   This allows to limit the range of possible input values for int
@@ -376,27 +377,3 @@ config FOO
 
 limits FOO to module (=m) or disabled (=n).
 
-
-Build limited by a third config symbol which may be =y or =m
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A common idiom that we see (and sometimes have problems with) is this:
-
-When option C in B (module or subsystem) uses interfaces from A (module
-or subsystem), and both A and B are tristate (could be =y or =m if they
-were independent of each other, but they aren't), then we need to limit
-C such that it cannot be built statically if A is built as a loadable
-module.  (C already depends on B, so there is no dependency issue to
-take care of here.)
-
-If A is linked statically into the kernel image, C can be built
-statically or as loadable module(s).  However, if A is built as loadable
-module(s), then C must be restricted to loadable module(s) also.  This
-can be expressed in kconfig language as:
-
-config C
-        depends on A = y || A = B
-
-or for real examples, use this command in a kernel tree:
-
-$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig
-
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index 1d247d59ad56..1821c077b435 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt
@@ -486,7 +486,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
         Sometimes, an external module uses exported symbols from another
         external module. Kbuild needs to have full knowledge on all symbols
         to avoid spitting out warnings about undefined symbols.
-        Two solutions exist to let kbuild know all symbols of more than
+        Three solutions exist to let kbuild know all symbols of more than
         one external module.
         The method with a top-level kbuild file is recommended but may be
         impractical in certain situations.
@@ -523,6 +523,13 @@ Module.symvers contains a list of all exported symbols from a kernel build.
                 containing the sum of all symbols defined and not part of the
                 kernel.
 
+        Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
+                If it is impractical to copy Module.symvers from another
+                module, you can assign a space separated list of files to
+                KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
+                loaded by modpost during the initialisation of its symbol
+                tables.
+
 === 8. Tips & Tricks
 
 --- 8.1 Testing for CONFIG_FOO_BAR
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index d0ac72cc19ff..b8e52c0355d3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -245,6 +245,8 @@ The syntax is:
     crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
     range=start-[end]
 
+    'start' is inclusive and 'end' is exclusive.
+
 For example:
 
     crashkernel=512M-2G:64M,2G-:128M
@@ -253,10 +255,11 @@ This would mean:
 
     1) if the RAM is smaller than 512M, then don't reserve anything
        (this is the "rescue" case)
-    2) if the RAM size is between 512M and 2G, then reserve 64M
+    2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
     3) if the RAM size is larger than 2G, then reserve 128M
 
 
+
 Boot into System Kernel
 =======================
 
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index 2075c0658bf5..0bd32748a467 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -1,6 +1,105 @@
 kernel-doc nano-HOWTO
 =====================
 
+How to format kernel-doc comments
+---------------------------------
+
+In order to provide embedded, 'C' friendly, easy to maintain,
+but consistent and extractable documentation of the functions and
+data structures in the Linux kernel, the Linux kernel has adopted
+a consistent style for documenting functions and their parameters,
+and structures and their members.
+
+The format for this documentation is called the kernel-doc format.
+It is documented in this Documentation/kernel-doc-nano-HOWTO.txt file.
+
+This style embeds the documentation within the source files, using
+a few simple conventions.  The scripts/kernel-doc perl script, some
+SGML templates in Documentation/DocBook, and other tools understand
+these conventions, and are used to extract this embedded documentation
+into various documents.
+
+In order to provide good documentation of kernel functions and data
+structures, please use the following conventions to format your
+kernel-doc comments in Linux kernel source.
+
+We definitely need kernel-doc formatted documentation for functions
+that are exported to loadable modules using EXPORT_SYMBOL.
+
+We also look to provide kernel-doc formatted documentation for
+functions externally visible to other kernel files (not marked
+"static").
+
+We also recommend providing kernel-doc formatted documentation
+for private (file "static") routines, for consistency of kernel
+source code layout.  But this is lower priority and at the
+discretion of the MAINTAINER of that kernel source file.
+
+Data structures visible in kernel include files should also be
+documented using kernel-doc formatted comments.
+
+The opening comment mark "/**" is reserved for kernel-doc comments.
+Only comments so marked will be considered by the kernel-doc scripts,
+and any comment so marked must be in kernel-doc format.  Do not use
+"/**" to be begin a comment block unless the comment block contains
+kernel-doc formatted comments.  The closing comment marker for
+kernel-doc comments can be either "*/" or "**/".
+
+Kernel-doc comments should be placed just before the function
+or data structure being described.
+
+Example kernel-doc function comment:
+
+/**
+ * foobar() - short function description of foobar
+ * @arg1:       Describe the first argument to foobar.
+ * @arg2:       Describe the second argument to foobar.
+ *              One can provide multiple line descriptions
+ *              for arguments.
+ *
+ * A longer description, with more discussion of the function foobar()
+ * that might be useful to those using or modifying it.  Begins with
+ * empty comment line, and may include additional embedded empty
+ * comment lines.
+ *
+ * The longer description can have multiple paragraphs.
+ **/
+
+The first line, with the short description, must be on a single line.
+
+The @argument descriptions must begin on the very next line following
+this opening short function description line, with no intervening
+empty comment lines.
+
+Example kernel-doc data structure comment.
+
+/**
+ * struct blah - the basic blah structure
+ * @mem1:       describe the first member of struct blah
+ * @mem2:       describe the second member of struct blah,
+ *              perhaps with more lines and words.
+ *
+ * Longer description of this structure.
+ **/
+
+The kernel-doc function comments describe each parameter to the
+function, in order, with the @name lines.
+
+The kernel-doc data structure comments describe each structure member
+in the data structure, with the @name lines.
+
+The longer description formatting is "reflowed", losing your line
+breaks.  So presenting carefully formatted lists within these
+descriptions won't work so well; derived documentation will lose
+the formatting.
+
+See the section below "How to add extractable documentation to your
+source files" for more details and notes on how to format kernel-doc
+comments.
+
+Components of the kernel-doc system
+-----------------------------------
+
 Many places in the source tree have extractable documentation in the
 form of block comments above functions.  The components of this system
 are:
diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt
index 5a4ef48224ae..28cdc2af2131 100644
--- a/Documentation/kernel-docs.txt
+++ b/Documentation/kernel-docs.txt
@@ -715,14 +715,14 @@
 
      * Name: "Gary's Encyclopedia - The Linux Kernel"
        Author: Gary (I suppose...).
-       URL: http://www.lisoleg.net/cgi-bin/lisoleg.pl?view=kernel.htm
-       Keywords: links, not found here?.
+       URL: http://slencyclopedia.berlios.de/index.html
+       Keywords: linux, community, everything!
        Description: Gary's Encyclopedia exists to allow the rapid finding
        of documentation and other information of interest to GNU/Linux
        users. It has about 4000 links to external pages in 150 major
        categories. This link is for kernel-specific links, documents,
-       sites... Look there if you could not find here what you were
-       looking for.
+       sites...  This list is now hosted by developer.Berlios.de,
+       but seems not to have been updated since sometime in 1999.
 
      * Name: "The home page of Linux-MM"
        Author: The Linux-MM team.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 508e2a2c9864..f1e970acad4c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -170,11 +170,6 @@ and is between 256 and 4096 characters. It is defined in the file
         acpi_irq_isa=   [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
                         Format: <irq>,<irq>...
 
-        acpi_new_pts_ordering [HW,ACPI]
-                        Enforce the ACPI 2.0 ordering of the _PTS control
-                        method wrt putting devices into low power states
-                        default: pre ACPI 2.0 ordering of _PTS
-
         acpi_no_auto_ssdt       [HW,ACPI] Disable automatic loading of SSDT
 
         acpi_os_name=   [HW,ACPI] Tell ACPI BIOS the name of the OS
@@ -371,6 +366,12 @@ and is between 256 and 4096 characters. It is defined in the file
                         possible to determine what the correct size should be.
                         This option provides an override for these situations.
 
+        security=       [SECURITY] Choose a security module to enable at boot.
+                        If this boot parameter is not specified, only the first
+                        security module asking for security registration will be
+                        loaded. An invalid security module name will be treated
+                        as if no module has been chosen.
+
         capability.disable=
                         [SECURITY] Disable capabilities.  This would normally
                         be used only if an alternative security model is to be
@@ -380,6 +381,10 @@ and is between 256 and 4096 characters. It is defined in the file
         ccw_timeout_log [S390]
                         See Documentation/s390/CommonIO for details.
 
+        cgroup_disable= [KNL] Disable a particular controller
+                        Format: {name of the controller(s) to disable}
+                                {Currently supported controllers - "memory"}
+
         checkreqprot    [SELINUX] Set initial checkreqprot flag value.
                         Format: { "0" | "1" }
                         See security/selinux/Kconfig help text.
@@ -393,9 +398,6 @@ and is between 256 and 4096 characters. It is defined in the file
         cio_ignore=     [S390]
                         See Documentation/s390/CommonIO for details.
 
-        cio_msg=        [S390]
-                        See Documentation/s390/CommonIO for details.
-
         clock=          [BUGS=X86-32, HW] gettimeofday clocksource override.
                         [Deprecated]
                         Forces specified clocksource (if available) to be used
@@ -491,6 +493,11 @@ and is between 256 and 4096 characters. It is defined in the file
                         switching to the matching ttyS device later.  The
                         options are the same as for ttyS, above.
 
+                If the device connected to the port is not a TTY but a braille
+                device, prepend "brl," before the device type, for instance
+                        console=brl,ttyS0
+                For now, only VisioBraille is supported.
+
         earlycon=       [KNL] Output early console device and options.
                 uart[8250],io,<addr>[,options]
                 uart[8250],mmio,<addr>[,options]
@@ -551,6 +558,8 @@ and is between 256 and 4096 characters. It is defined in the file
                         1 will print _a lot_ more information - normally
                         only useful to kernel developers.
 
+        debug_objects   [KNL] Enable object debugging
+
         decnet.addr=    [HW,NET]
                         Format: <area>[,<node>]
                         See also Documentation/networking/decnet.txt.
@@ -622,8 +631,7 @@ and is between 256 and 4096 characters. It is defined in the file
         eata=           [HW,SCSI]
 
         edd=            [EDD]
-                        Format: {"of[f]" | "sk[ipmbr]"}
-                        See comment in arch/i386/boot/edd.S
+                        Format: {"off" | "on" | "skip[mbr]"}
 
         eisa_irq_edge=  [PARISC,HW]
                         See header of drivers/parisc/eisa.c.
@@ -678,6 +686,12 @@ and is between 256 and 4096 characters. It is defined in the file
         floppy=         [HW]
                         See Documentation/floppy.txt.
 
+        force_pal_cache_flush
+                        [IA-64] Avoid check_sal_cache_flush which may hang on
+                        buggy SAL_CACHE_FLUSH implementations. Using this
+                        parameter will force ia64_sal_cache_flush to call
+                        ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
+
         gamecon.map[2|3]=
                         [HW,JOY] Multisystem joystick and NES/SNES/PSX pad
                         support via parallel port (up to 5 devices per port)
@@ -764,11 +778,7 @@ and is between 256 and 4096 characters. It is defined in the file
                         Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
         ide=            [HW] (E)IDE subsystem
-                        Format: ide=nodma or ide=doubler or ide=reverse
-                        See Documentation/ide/ide.txt.
-
-        ide?=           [HW] (E)IDE subsystem
-                        Format: ide?=noprobe or chipset specific parameters.
+                        Format: ide=nodma or ide=doubler
                         See Documentation/ide/ide.txt.
 
         idebus=         [HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -813,6 +823,19 @@ and is between 256 and 4096 characters. It is defined in the file
 
         inttest=        [IA64]
 
+        iommu=          [x86]
+                off
+                force
+                noforce
+                biomerge
+                panic
+                nopanic
+                merge
+                nomerge
+                forcesac
+                soft
+
+
         intel_iommu=    [DMAR] Intel IOMMU driver (DMAR) option
                 off
                         Disable intel iommu driver.
@@ -829,6 +852,10 @@ and is between 256 and 4096 characters. It is defined in the file
                         than 32 bit addressing. The default is to look
                         for translation below 32 bit and if not available
                         then look in the higher range.
+                strict [Default Off]
+                        With this option on every unmap_single operation will
+                        result in a hardware IOTLB flush operation as opposed
+                        to batching them for performance.
 
         io_delay=       [X86-32,X86-64] I/O delay method
                 0x80
@@ -845,7 +872,7 @@ and is between 256 and 4096 characters. It is defined in the file
                         arch/alpha/kernel/core_marvel.c.
 
         ip=             [IP_PNP]
-                        See Documentation/nfsroot.txt.
+                        See Documentation/filesystems/nfsroot.txt.
 
         ip2=            [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
                         See comment before ip2_setup() in
@@ -929,8 +956,15 @@ and is between 256 and 4096 characters. It is defined in the file
         kstack=N        [X86-32,X86-64] Print N words from the kernel stack
                         in oops dumps.
 
+        kgdboc=         [HW] kgdb over consoles.
+                        Requires a tty driver that supports console polling.
+                        (only serial suported for now)
+                        Format: <serial_device>[,baud]
+
         l2cr=           [PPC]
 
+        l3cr=           [PPC]
+
         lapic           [X86-32,APIC] Enable the local APIC even if BIOS
                         disabled it.
 
@@ -1063,9 +1097,6 @@ and is between 256 and 4096 characters. It is defined in the file
         mac5380=        [HW,SCSI] Format:
                         <can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>
 
-        mac53c9x=       [HW,SCSI] Format:
-                        <num_esps>,<disconnect>,<nosync>,<can_queue>,<cmd_per_lun>,<sg_tablesize>,<hostid>,<use_tags>
-
         machvec=        [IA64] Force the use of a particular machine-vector
                         (machvec) in a generic kernel.
                         Example: machvec=hpzx1_swiotlb
@@ -1135,6 +1166,11 @@ and is between 256 and 4096 characters. It is defined in the file
                                  or
                                  memmap=0x10000$0x18690000
 
+        memtest=        [KNL,X86_64] Enable memtest
+                        Format: <integer>
+                        range: 0,4 : pattern number
+                        default : 0 <disable>
+
         meye.*=         [HW] Set MotionEye Camera parameters
                         See Documentation/video4linux/meye.txt.
 
@@ -1172,6 +1208,11 @@ and is between 256 and 4096 characters. It is defined in the file
         mtdparts=       [MTD]
                         See drivers/mtd/cmdlinepart.c.
 
+        mtdset=         [ARM]
+                        ARM/S3C2412 JIVE boot control
+
+                        See arch/arm/mach-s3c2412/mach-jive.c
+
         mtouchusb.raw_coordinates=
                         [HW] Make the MicroTouch USB driver use raw coordinates
                         ('y', default) or cooked coordinates ('n')
@@ -1199,10 +1240,10 @@ and is between 256 and 4096 characters. It is defined in the file
                         file if at all.
 
         nfsaddrs=       [NFS]
-                        See Documentation/nfsroot.txt.
+                        See Documentation/filesystems/nfsroot.txt.
 
         nfsroot=        [NFS] nfs root filesystem for disk-less boxes.
-                        See Documentation/nfsroot.txt.
+                        See Documentation/filesystems/nfsroot.txt.
 
         nfs.callback_tcpport=
                         [NFS] set the TCP port on which the NFSv4 callback
@@ -1252,8 +1293,16 @@ and is between 256 and 4096 characters. It is defined in the file
         noexec          [IA-64]
 
         noexec          [X86-32,X86-64]
+                        On X86-32 available only on PAE configured kernels.
                         noexec=on: enable non-executable mappings (default)
-                        noexec=off: disable nn-executable mappings
+                        noexec=off: disable non-executable mappings
+
+        noexec32        [X86-64]
+                        This affects only 32-bit executables.
+                        noexec32=on: enable non-executable mappings (default)
+                                read doesn't imply executable mappings
+                        noexec32=off: disable non-executable mappings
+                                read implies executable mappings
 
         nofxsr          [BUGS=X86-32] Disables x86 floating point extended
                         register save and restore. The kernel will only save
@@ -1340,6 +1389,10 @@ and is between 256 and 4096 characters. It is defined in the file
 
         nowb            [ARM]
 
+        nptcg=          [IA64] Override max number of concurrent global TLB
+                        purges which is reported from either PAL_VM_SUMMARY or
+                        SAL PALO.
+
         numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
                         one of ['zone', 'node', 'default'] can be specified
                         This can be set from sysctl after boot.
@@ -1347,6 +1400,13 @@ and is between 256 and 4096 characters. It is defined in the file
 
         nr_uarts=       [SERIAL] maximum number of UARTs to be registered.
 
+        olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
+                        Rather than timing out after 20 ms if an EC
+                        command is not properly ACKed, override the length
+                        of the timeout.  We have interrupts disabled while
+                        waiting for the ACK, so if this is set too high
+                        interrupts *may* be lost!
+
         opl3=           [HW,OSS]
                         Format: <io>
 
@@ -1429,10 +1489,6 @@ and is between 256 and 4096 characters. It is defined in the file
                 nomsi           [MSI] If the PCI_MSI kernel config parameter is
                                 enabled, this kernel boot option can be used to
                                 disable the use of MSI interrupts system-wide.
-                nosort          [X86-32] Don't sort PCI devices according to
-                                order given by the PCI BIOS. This sorting is
-                                done to get a device order compatible with
-                                older kernels.
                 biosirq         [X86-32] Use PCI BIOS calls to get the interrupt
                                 routing table. These calls are known to be buggy
                                 on several machines and they hang the machine
@@ -1474,6 +1530,8 @@ and is between 256 and 4096 characters. It is defined in the file
                                 This is normally done in pci_enable_device(),
                                 so this option is a temporary workaround
                                 for broken drivers that don't call it.
+                skip_isa_align  [X86] do not align io start addr, so can
+                                handle more pci cards
                 firmware        [ARM] Do not re-enumerate the bus but instead
                                 just use the configuration from the
                                 bootloader. This is currently used on
diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt
index 266955d23ee6..09b55e461740 100644
--- a/Documentation/keys-request-key.txt
+++ b/Documentation/keys-request-key.txt
@@ -11,26 +11,29 @@ request_key*():
 
         struct key *request_key(const struct key_type *type,
                                 const char *description,
-                                const char *callout_string);
+                                const char *callout_info);
 
 or:
 
         struct key *request_key_with_auxdata(const struct key_type *type,
                                              const char *description,
-                                             const char *callout_string,
+                                             const char *callout_info,
+                                             size_t callout_len,
                                              void *aux);
 
 or:
 
         struct key *request_key_async(const struct key_type *type,
                                       const char *description,
-                                      const char *callout_string);
+                                      const char *callout_info,
+                                      size_t callout_len);
 
 or:
 
         struct key *request_key_async_with_auxdata(const struct key_type *type,
                                                    const char *description,
-                                                   const char *callout_string,
+                                                   const char *callout_info,
+                                                   size_t callout_len,
                                                    void *aux);
 
 Or by userspace invoking the request_key system call:
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 51652d39e61c..d5c7a57d1700 100644
--- a/Documentation/keys.txt
+++ b/Documentation/keys.txt
@@ -170,7 +170,8 @@ The key service provides a number of features besides keys:
      amount of description and payload space that can be consumed.
 
      The user can view information on this and other statistics through procfs
-     files.
+     files.  The root user may also alter the quota limits through sysctl files
+     (see the section "New procfs files").
 
      Process-specific and thread-specific keyrings are not counted towards a
      user's quota.
@@ -329,6 +330,27 @@ about the status of the key service:
         <bytes>/<max>           Key size quota
 
 
+Four new sysctl files have been added also for the purpose of controlling the
+quota limits on keys:
+
+ (*) /proc/sys/kernel/keys/root_maxkeys
+     /proc/sys/kernel/keys/root_maxbytes
+
+     These files hold the maximum number of keys that root may have and the
+     maximum total number of bytes of data that root may have stored in those
+     keys.
+
+ (*) /proc/sys/kernel/keys/maxkeys
+     /proc/sys/kernel/keys/maxbytes
+
+     These files hold the maximum number of keys that each non-root user may
+     have and the maximum total number of bytes of data that each of those
+     users may have stored in their keys.
+
+Root may alter these by writing each new limit as a decimal number string to
+the appropriate file.
+
+
 ===============================
 USERSPACE SYSTEM CALL INTERFACE
 ===============================
@@ -711,6 +733,27 @@ The keyctl syscall functions are:
      The assumed authoritative key is inherited across fork and exec.
 
 
+ (*) Get the LSM security context attached to a key.
+
+        long keyctl(KEYCTL_GET_SECURITY, key_serial_t key, char *buffer,
+                    size_t buflen)
+
+     This function returns a string that represents the LSM security context
+     attached to a key in the buffer provided.
+
+     Unless there's an error, it always returns the amount of data it could
+     produce, even if that's too big for the buffer, but it won't copy more
+     than requested to userspace. If the buffer pointer is NULL then no copy
+     will take place.
+
+     A NUL character is included at the end of the string if the buffer is
+     sufficiently big.  This is included in the returned count.  If no LSM is
+     in force then an empty string will be returned.
+
+     A process must have view permission on the key for this function to be
+     successful.
+
+
 ===============
 KERNEL SERVICES
 ===============
@@ -771,7 +814,7 @@ payload contents" for more information.
 
         struct key *request_key(const struct key_type *type,
                                 const char *description,
-                                const char *callout_string);
+                                const char *callout_info);
 
     This is used to request a key or keyring with a description that matches
     the description specified according to the key type's match function. This
@@ -793,24 +836,28 @@ payload contents" for more information.
 
         struct key *request_key_with_auxdata(const struct key_type *type,
                                              const char *description,
-                                             const char *callout_string,
+                                             const void *callout_info,
+                                             size_t callout_len,
                                              void *aux);
 
     This is identical to request_key(), except that the auxiliary data is
-    passed to the key_type->request_key() op if it exists.
+    passed to the key_type->request_key() op if it exists, and the callout_info
+    is a blob of length callout_len, if given (the length may be 0).
 
 
 (*) A key can be requested asynchronously by calling one of:
 
         struct key *request_key_async(const struct key_type *type,
                                       const char *description,
-                                      const char *callout_string);
+                                      const void *callout_info,
+                                      size_t callout_len);
 
     or:
 
         struct key *request_key_async_with_auxdata(const struct key_type *type,
                                                    const char *description,
-                                                   const char *callout_string,
+                                                   const char *callout_info,
+                                                   size_t callout_len,
                                                    void *aux);
 
     which are asynchronous equivalents of request_key() and
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index bf3256e04027..51a8021ee532 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -305,7 +305,7 @@ should not be manipulated by any other user.
 
 A kset keeps its children in a standard kernel linked list.  Kobjects point
 back to their containing kset via their kset field. In almost all cases,
-the kobjects belonging to a ket have that kset (or, strictly, its embedded
+the kobjects belonging to a kset have that kset (or, strictly, its embedded
 kobject) in their parent.
 
 As a kset contains a kobject within it, it should always be dynamically
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index be89f393274f..6877e7187113 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -37,6 +37,11 @@ registration function such as register_kprobe() specifies where
 the probe is to be inserted and what handler is to be called when
 the probe is hit.
 
+There are also register_/unregister_*probes() functions for batch
+registration/unregistration of a group of *probes. These functions
+can speed up unregistration process when you have to unregister
+a lot of probes at once.
+
 The next three subsections explain how the different types of
 probes work.  They explain certain things that you'll need to
 know in order to make the best use of Kprobes -- e.g., the
@@ -190,10 +195,11 @@ code mapping.
 4. API Reference
 
 The Kprobes API includes a "register" function and an "unregister"
-function for each type of probe.  Here are terse, mini-man-page
-specifications for these functions and the associated probe handlers
-that you'll write.  See the files in the samples/kprobes/ sub-directory
-for examples.
+function for each type of probe. The API also includes "register_*probes"
+and "unregister_*probes" functions for (un)registering arrays of probes.
+Here are terse, mini-man-page specifications for these functions and
+the associated probe handlers that you'll write. See the files in the
+samples/kprobes/ sub-directory for examples.
 
 4.1 register_kprobe
 
@@ -319,6 +325,43 @@ void unregister_kretprobe(struct kretprobe *rp);
 Removes the specified probe.  The unregister function can be called
 at any time after the probe has been registered.
 
+NOTE:
+If the functions find an incorrect probe (ex. an unregistered probe),
+they clear the addr field of the probe.
+
+4.5 register_*probes
+
+#include <linux/kprobes.h>
+int register_kprobes(struct kprobe **kps, int num);
+int register_kretprobes(struct kretprobe **rps, int num);
+int register_jprobes(struct jprobe **jps, int num);
+
+Registers each of the num probes in the specified array.  If any
+error occurs during registration, all probes in the array, up to
+the bad probe, are safely unregistered before the register_*probes
+function returns.
+- kps/rps/jps: an array of pointers to *probe data structures
+- num: the number of the array entries.
+
+NOTE:
+You have to allocate(or define) an array of pointers and set all
+of the array entries before using these functions.
+
+4.6 unregister_*probes
+
+#include <linux/kprobes.h>
+void unregister_kprobes(struct kprobe **kps, int num);
+void unregister_kretprobes(struct kretprobe **rps, int num);
+void unregister_jprobes(struct jprobe **jps, int num);
+
+Removes each of the num probes in the specified array at once.
+
+NOTE:
+If the functions find some incorrect probes (ex. unregistered
+probes) in the specified array, they clear the addr field of those
+incorrect probes. However, other probes in the array are
+unregistered correctly.
+
 5. Kprobes Features and Limitations
 
 Kprobes allows multiple probes at the same address.  Currently,
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt
index 23df051dbf69..79b7dbd22141 100644
--- a/Documentation/laptops/acer-wmi.txt
+++ b/Documentation/laptops/acer-wmi.txt
@@ -80,7 +80,7 @@ once you enable the radio, will depend on your hardware and driver combination.
 e.g. With the BCM4318 on the Acer Aspire 5020 series:
 
 ndiswrapper: Light blinks on when transmitting
-bcm43xx/b43: Solid light, blinks off when transmitting
+b43: Solid light, blinks off when transmitting
 
 Wireless radio control is unconditionally enabled - all Acer laptops that support
 acer-wmi come with built-in wireless. However, should you feel so inclined to
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 76cb428435da..64b3f146e4b0 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1,7 +1,7 @@
                      ThinkPad ACPI Extras Driver
 
-                            Version 0.19
-                         January 06th, 2008
+                            Version 0.20
+                          April 09th, 2008
 
                Borislav Deianov <borislav@users.sf.net>
              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -18,6 +18,11 @@ This driver used to be named ibm-acpi until kernel 2.6.21 and release
 moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
 2.6.22, and release 0.14.
 
+The driver is named "thinkpad-acpi".  In some places, like module
+names, "thinkpad_acpi" is used because of userspace issues.
+
+"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too
+long due to length limitations on some Linux kernel versions.
 
 Status
 ------
@@ -498,7 +503,7 @@ generate input device EV_KEY events.
 In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW
 events for switches:
 
-SW_RADIO        T60 and later hardare rfkill rocker switch
+SW_RFKILL_ALL   T60 and later hardare rfkill rocker switch
 SW_TABLET_MODE  Tablet ThinkPads HKEY events 0x5009 and 0x500A
 
 Non hot-key ACPI HKEY event map:
@@ -571,6 +576,47 @@ netlink interface and the input layer interface, and don't bother at all
 with hotkey_report_mode.
 
 
+Brightness hotkey notes:
+
+These are the current sane choices for brightness key mapping in
+thinkpad-acpi:
+
+For IBM and Lenovo models *without* ACPI backlight control (the ones on
+which thinkpad-acpi will autoload its backlight interface by default,
+and on which ACPI video does not export a backlight interface):
+
+1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as
+   these older firmware versions unfortunately won't respect the hotkey
+   mask for brightness keys anyway, and always reacts to them.  This
+   usually work fine, unless X.org drivers are doing something to block
+   the BIOS.  In that case, use (3) below.  This is the default mode of
+   operation.
+
+2. Enable the hotkeys, but map them to something else that is NOT
+   KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause
+   userspace to try to change the backlight level, and use that as an
+   on-screen-display hint.
+
+3. IF AND ONLY IF X.org drivers find a way to block the firmware from
+   automatically changing the brightness, enable the hotkeys and map
+   them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to
+   something that calls xbacklight.  thinkpad-acpi will not be able to
+   change brightness in that case either, so you should disable its
+   backlight interface.
+
+For Lenovo models *with* ACPI backlight control:
+
+1. Load up ACPI video and use that.  ACPI video will report ACPI
+   events for brightness change keys.  Do not mess with thinkpad-acpi
+   defaults in this case.  thinkpad-acpi should not have anything to do
+   with backlight events in a scenario where ACPI video is loaded:
+   brightness hotkeys must be disabled, and the backlight interface is
+   to be kept disabled as well.  This is the default mode of operation.
+
+2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
+   and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN.  Process
+   these keys on userspace somehow (e.g. by calling xbacklight).
+
 Bluetooth
 ---------
 
@@ -647,16 +693,31 @@ while others are still having problems. For more information:
 
 https://bugs.freedesktop.org/show_bug.cgi?id=2000
 
-ThinkLight control -- /proc/acpi/ibm/light
-------------------------------------------
+ThinkLight control
+------------------
+
+procfs: /proc/acpi/ibm/light
+sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED
 
-The current status of the ThinkLight can be found in this file. A few
-models which do not make the status available will show it as
-"unknown". The available commands are:
+procfs notes:
+
+The ThinkLight status can be read and set through the procfs interface.  A
+few models which do not make the status available will show the ThinkLight
+status as "unknown". The available commands are:
 
         echo on  > /proc/acpi/ibm/light
         echo off > /proc/acpi/ibm/light
 
+sysfs notes:
+
+The ThinkLight sysfs interface is documented by the LED class
+documentation, in Documentation/leds-class.txt.  The ThinkLight LED name
+is "tpacpi::thinklight".
+
+Due to limitations in the sysfs LED class, if the status of the thinklight
+cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
+It is impossible to know if the status returned through sysfs is valid.
+
 Docking / undocking -- /proc/acpi/ibm/dock
 ------------------------------------------
 
@@ -815,28 +876,63 @@ The cmos command interface is prone to firmware split-brain problems, as
 in newer ThinkPads it is just a compatibility layer.  Do not use it, it is
 exported just as a debug tool.
 
-LED control -- /proc/acpi/ibm/led
----------------------------------
+LED control
+-----------
+
+procfs: /proc/acpi/ibm/led
+sysfs attributes: as per LED class, see below for names
+
+Some of the LED indicators can be controlled through this feature.  On
+some older ThinkPad models, it is possible to query the status of the
+LED indicators as well.  Newer ThinkPads cannot query the real status
+of the LED indicators.
 
-Some of the LED indicators can be controlled through this feature. The
-available commands are:
+procfs notes:
+
+The available commands are:
 
-        echo '<led number> on' >/proc/acpi/ibm/led
-        echo '<led number> off' >/proc/acpi/ibm/led
-        echo '<led number> blink' >/proc/acpi/ibm/led
+        echo '<LED number> on' >/proc/acpi/ibm/led
+        echo '<LED number> off' >/proc/acpi/ibm/led
+        echo '<LED number> blink' >/proc/acpi/ibm/led
 
-The <led number> range is 0 to 7. The set of LEDs that can be
-controlled varies from model to model. Here is the mapping on the X40:
+The <LED number> range is 0 to 7. The set of LEDs that can be
+controlled varies from model to model. Here is the common ThinkPad
+mapping:
 
         0 - power
         1 - battery (orange)
         2 - battery (green)
-        3 - UltraBase
+        3 - UltraBase/dock
         4 - UltraBay
+        5 - UltraBase battery slot
+        6 - (unknown)
         7 - standby
 
 All of the above can be turned on and off and can be made to blink.
 
+sysfs notes:
+
+The ThinkPad LED sysfs interface is described in detail by the LED class
+documentation, in Documentation/leds-class.txt.
+
+The leds are named (in LED ID order, from 0 to 7):
+"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",
+"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt",
+"tpacpi::unknown_led", "tpacpi::standby".
+
+Due to limitations in the sysfs LED class, if the status of the LED
+indicators cannot be read due to an error, thinkpad-acpi will report it as
+a brightness of zero (same as LED off).
+
+If the thinkpad firmware doesn't support reading the current status,
+trying to read the current LED brightness will just return whatever
+brightness was last written to that attribute.
+
+These LEDs can blink using hardware acceleration.  To request that a
+ThinkPad indicator LED should blink in hardware accelerated mode, use the
+"timer" trigger, and leave the delay_on and delay_off parameters set to
+zero (to request hardware acceleration autodetection).
+
 ACPI sounds -- /proc/acpi/ibm/beep
 ----------------------------------
 
@@ -1090,6 +1186,15 @@ it there will be the following attributes:
                 dim the display.
 
 
+WARNING:
+
+    Whatever you do, do NOT ever call thinkpad-acpi backlight-level change
+    interface and the ACPI-based backlight level change interface
+    (available on newer BIOSes, and driven by the Linux ACPI video driver)
+    at the same time.  The two will interact in bad ways, do funny things,
+    and maybe reduce the life of the backlight lamps by needlessly kicking
+    its level up and down at every change.
+
 Volume control -- /proc/acpi/ibm/volume
 ---------------------------------------
 
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt
index 56757c751d6f..18860ad9935a 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds-class.txt
@@ -19,6 +19,12 @@ optimises away.
 
 Complex triggers whilst available to all LEDs have LED specific
 parameters and work on a per LED basis. The timer trigger is an example.
+The timer trigger will periodically change the LED brightness between
+LED_OFF and the current brightness setting. The "on" and "off" time can
+be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
+You can change the brightness value of a LED independently of the timer
+trigger. However, if you set the brightness value to LED_OFF it will
+also disable the timer trigger.
 
 You can change triggers in a similar manner to the way an IO scheduler
 is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
@@ -63,9 +69,9 @@ value if it is called with *delay_on==0 && *delay_off==0 parameters. In
 this case the driver should give back the chosen value through delay_on
 and delay_off parameters to the leds subsystem.
 
-Any call to the brightness_set() callback function should cancel the
-previously programmed hardware blinking function so setting the brightness
-to 0 can also cancel the blinking of the LED.
+Setting the brightness to zero with brightness_set() callback function
+should completely turn off the LED and cancel the previously programmed
+hardware blinking function, if any.
 
 
 Known Issues
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
index bec5a32e4095..82fafe0429fe 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -1,7 +1,7 @@
 /*P:100 This is the Launcher code, a simple program which lays out the
- * "physical" memory for the new Guest by mapping the kernel image and the
- * virtual devices, then reads repeatedly from /dev/lguest to run the Guest.
-:*/
+ * "physical" memory for the new Guest by mapping the kernel image and
+ * the virtual devices, then opens /dev/lguest to tell the kernel
+ * about the Guest and control it. :*/
 #define _LARGEFILE64_SOURCE
 #define _GNU_SOURCE
 #include <stdio.h>
@@ -43,7 +43,7 @@
 #include "linux/virtio_console.h"
 #include "linux/virtio_ring.h"
 #include "asm-x86/bootparam.h"
-/*L:110 We can ignore the 38 include files we need for this program, but I do
+/*L:110 We can ignore the 39 include files we need for this program, but I do
  * want to draw attention to the use of kernel-style types.
  *
  * As Linus said, "C is a Spartan language, and so should your naming be."  I
@@ -131,6 +131,9 @@ struct device
         /* Any queues attached to this device */
         struct virtqueue *vq;
 
+        /* Handle status being finalized (ie. feature bits stable). */
+        void (*ready)(struct device *me);
+
         /* Device-specific data. */
         void *priv;
 };
@@ -154,6 +157,9 @@ struct virtqueue
 
         /* The routine to call when the Guest pings us. */
         void (*handle_output)(int fd, struct virtqueue *me);
+
+        /* Outstanding buffers */
+        unsigned int inflight;
 };
 
 /* Remember the arguments to the program so we can "reboot" */
@@ -320,7 +326,7 @@ static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr)
                 err(1, "Reading program headers");
 
         /* Try all the headers: there are usually only three.  A read-only one,
-         * a read-write one, and a "note" section which isn't loadable. */
+         * a read-write one, and a "note" section which we don't load. */
         for (i = 0; i < ehdr->e_phnum; i++) {
                 /* If this isn't a loadable segment, we ignore it */
                 if (phdr[i].p_type != PT_LOAD)
@@ -387,7 +393,7 @@ static unsigned long load_kernel(int fd)
         if (memcmp(hdr.e_ident, ELFMAG, SELFMAG) == 0)
                 return map_elf(fd, &hdr);
 
-        /* Otherwise we assume it's a bzImage, and try to unpack it */
+        /* Otherwise we assume it's a bzImage, and try to load it. */
         return load_bzimage(fd);
 }
 
@@ -433,12 +439,12 @@ static unsigned long load_initrd(const char *name, unsigned long mem)
         return len;
 }
 
-/* Once we know how much memory we have, we can construct simple linear page
+/* Once we know how much memory we have we can construct simple linear page
  * tables which set virtual == physical which will get the Guest far enough
  * into the boot to create its own.
  *
  * We lay them out of the way, just below the initrd (which is why we need to
- * know its size). */
+ * know its size here). */
 static unsigned long setup_pagetables(unsigned long mem,
                                       unsigned long initrd_size)
 {
@@ -699,6 +705,7 @@ static unsigned get_vq_desc(struct virtqueue *vq,
                         errx(1, "Looped descriptor");
         } while ((i = next_desc(vq, i)) != vq->vring.num);
 
+        vq->inflight++;
         return head;
 }
 
@@ -716,6 +723,7 @@ static void add_used(struct virtqueue *vq, unsigned int head, int len)
         /* Make sure buffer is written before we update index. */
         wmb();
         vq->vring.used->idx++;
+        vq->inflight--;
 }
 
 /* This actually sends the interrupt for this virtqueue */
@@ -723,8 +731,9 @@ static void trigger_irq(int fd, struct virtqueue *vq)
 {
         unsigned long buf[] = { LHREQ_IRQ, vq->config.irq };
 
-        /* If they don't want an interrupt, don't send one. */
-        if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+        /* If they don't want an interrupt, don't send one, unless empty. */
+        if ((vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+            && vq->inflight)
                 return;
 
         /* Send the Guest an interrupt tell them we used something up. */
@@ -850,7 +859,8 @@ static void handle_console_output(int fd, struct virtqueue *vq)
  *
  * Handling output for network is also simple: we get all the output buffers
  * and write them (ignoring the first element) to this device's file descriptor
- * (stdout). */
+ * (/dev/net/tun).
+ */
 static void handle_net_output(int fd, struct virtqueue *vq)
 {
         unsigned int head, out, in;
@@ -924,24 +934,40 @@ static void enable_fd(int fd, struct virtqueue *vq)
         write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd));
 }
 
-/* Resetting a device is fairly easy. */
-static void reset_device(struct device *dev)
+/* When the Guest tells us they updated the status field, we handle it. */
+static void update_device_status(struct device *dev)
 {
         struct virtqueue *vq;
 
-        verbose("Resetting device %s\n", dev->name);
-        /* Clear the status. */
-        dev->desc->status = 0;
+        /* This is a reset. */
+        if (dev->desc->status == 0) {
+                verbose("Resetting device %s\n", dev->name);
 
-        /* Clear any features they've acked. */
-        memset(get_feature_bits(dev) + dev->desc->feature_len, 0,
-               dev->desc->feature_len);
+                /* Clear any features they've acked. */
+                memset(get_feature_bits(dev) + dev->desc->feature_len, 0,
+                       dev->desc->feature_len);
 
-        /* Zero out the virtqueues. */
-        for (vq = dev->vq; vq; vq = vq->next) {
-                memset(vq->vring.desc, 0,
-                       vring_size(vq->config.num, getpagesize()));
-                vq->last_avail_idx = 0;
+                /* Zero out the virtqueues. */
+                for (vq = dev->vq; vq; vq = vq->next) {
+                        memset(vq->vring.desc, 0,
+                               vring_size(vq->config.num, getpagesize()));
+                        vq->last_avail_idx = 0;
+                }
+        } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
+                warnx("Device %s configuration FAILED", dev->name);
+        } else if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) {
+                unsigned int i;
+
+                verbose("Device %s OK: offered", dev->name);
+                for (i = 0; i < dev->desc->feature_len; i++)
+                        verbose(" %08x", get_feature_bits(dev)[i]);
+                verbose(", accepted");
+                for (i = 0; i < dev->desc->feature_len; i++)
+                        verbose(" %08x", get_feature_bits(dev)
+                                [dev->desc->feature_len+i]);
+
+                if (dev->ready)
+                        dev->ready(dev);
         }
 }
 
@@ -953,9 +979,9 @@ static void handle_output(int fd, unsigned long addr)
 
         /* Check each device and virtqueue. */
         for (i = devices.dev; i; i = i->next) {
-                /* Notifications to device descriptors reset the device. */
+                /* Notifications to device descriptors update device status. */
                 if (from_guest_phys(addr) == i->desc) {
-                        reset_device(i);
+                        update_device_status(i);
                         return;
                 }
 
@@ -1003,8 +1029,8 @@ static void handle_input(int fd)
                 if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0)
                         break;
 
-                /* Otherwise, call the device(s) which have readable
-                 * file descriptors and a method of handling them.  */
+                /* Otherwise, call the device(s) which have readable file
+                 * descriptors and a method of handling them.  */
                 for (i = devices.dev; i; i = i->next) {
                         if (i->handle_input && FD_ISSET(i->fd, &fds)) {
                                 int dev_fd;
@@ -1015,8 +1041,7 @@ static void handle_input(int fd)
                                  * should no longer service it.  Networking and
                                  * console do this when there's no input
                                  * buffers to deliver into.  Console also uses
-                                 * it when it discovers that stdin is
-                                 * closed. */
+                                 * it when it discovers that stdin is closed. */
                                 FD_CLR(i->fd, &devices.infds);
                                 /* Tell waker to ignore it too, by sending a
                                  * negative fd number (-1, since 0 is a valid
@@ -1033,7 +1058,8 @@ static void handle_input(int fd)
  *
  * All devices need a descriptor so the Guest knows it exists, and a "struct
  * device" so the Launcher can keep track of it.  We have common helper
- * routines to allocate and manage them. */
+ * routines to allocate and manage them.
+ */
 
 /* The layout of the device page is a "struct lguest_device_desc" followed by a
  * number of virtqueue descriptors, then two sets of feature bits, then an
@@ -1078,7 +1104,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
         struct virtqueue **i, *vq = malloc(sizeof(*vq));
         void *p;
 
-        /* First we need some pages for this virtqueue. */
+        /* First we need some memory for this virtqueue. */
         pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1)
                 / getpagesize();
         p = get_pages(pages);
@@ -1087,6 +1113,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
         vq->next = NULL;
         vq->last_avail_idx = 0;
         vq->dev = dev;
+        vq->inflight = 0;
 
         /* Initialize the configuration. */
         vq->config.num = num_descs;
@@ -1122,7 +1149,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 }
 
 /* The first half of the feature bitmask is for us to advertise features.  The
- * second half if for the Guest to accept features. */
+ * second half is for the Guest to accept features. */
 static void add_feature(struct device *dev, unsigned bit)
 {
         u8 *features = get_feature_bits(dev);
@@ -1151,7 +1178,9 @@ static void set_config(struct device *dev, unsigned len, const void *conf)
 }
 
 /* This routine does all the creation and setup of a new device, including
- * calling new_dev_desc() to allocate the descriptor and device memory. */
+ * calling new_dev_desc() to allocate the descriptor and device memory.
+ *
+ * See what I mean about userspace being boring? */
 static struct device *new_device(const char *name, u16 type, int fd,
                                  bool (*handle_input)(int, struct device *))
 {
@@ -1167,6 +1196,7 @@ static struct device *new_device(const char *name, u16 type, int fd,
         dev->handle_input = handle_input;
         dev->name = name;
         dev->vq = NULL;
+        dev->ready = NULL;
 
         /* Append to device list.  Prepending to a single-linked list is
          * easier, but the user expects the devices to be arranged on the bus
@@ -1345,6 +1375,7 @@ static void setup_tun_net(const char *arg)
 
         /* Tell Guest what MAC address to use. */
         add_feature(dev, VIRTIO_NET_F_MAC);
+        add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
         set_config(dev, sizeof(conf), &conf);
 
         /* We don't need the socket any more; setup is done. */
@@ -1383,7 +1414,6 @@ struct vblk_info
          * Launcher triggers interrupt to Guest. */
         int done_fd;
 };
-/*:*/
 
 /*L:210
  * The Disk
@@ -1396,7 +1426,7 @@ static bool service_io(struct device *dev)
         struct vblk_info *vblk = dev->priv;
         unsigned int head, out_num, in_num, wlen;
         int ret;
-        struct virtio_blk_inhdr *in;
+        u8 *in;
         struct virtio_blk_outhdr *out;
         struct iovec iov[dev->vq->vring.num];
         off64_t off;
@@ -1414,7 +1444,7 @@ static bool service_io(struct device *dev)
                      head, out_num, in_num);
 
         out = convert(&iov[0], struct virtio_blk_outhdr);
-        in = convert(&iov[out_num+in_num-1], struct virtio_blk_inhdr);
+        in = convert(&iov[out_num+in_num-1], u8);
         off = out->sector * 512;
 
         /* The block device implements "barriers", where the Guest indicates
@@ -1428,7 +1458,7 @@ static bool service_io(struct device *dev)
          * It'd be nice if we supported eject, for example, but we don't. */
         if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
                 fprintf(stderr, "Scsi commands unsupported\n");
-                in->status = VIRTIO_BLK_S_UNSUPP;
+                *in = VIRTIO_BLK_S_UNSUPP;
                 wlen = sizeof(*in);
         } else if (out->type & VIRTIO_BLK_T_OUT) {
                 /* Write */
@@ -1451,7 +1481,7 @@ static bool service_io(struct device *dev)
                         errx(1, "Write past end %llu+%u", off, ret);
                 }
                 wlen = sizeof(*in);
-                in->status = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
+                *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
         } else {
                 /* Read */
 
@@ -1464,10 +1494,10 @@ static bool service_io(struct device *dev)
                 verbose("READ from sector %llu: %i\n", out->sector, ret);
                 if (ret >= 0) {
                         wlen = sizeof(*in) + ret;
-                        in->status = VIRTIO_BLK_S_OK;
+                        *in = VIRTIO_BLK_S_OK;
                 } else {
                         wlen = sizeof(*in);
-                        in->status = VIRTIO_BLK_S_IOERR;
+                        *in = VIRTIO_BLK_S_IOERR;
                 }
         }
 
@@ -1493,7 +1523,10 @@ static int io_thread(void *_dev)
         while (read(vblk->workpipe[0], &c, 1) == 1) {
                 /* We acknowledge each request immediately to reduce latency,
                  * rather than waiting until we've done them all.  I haven't
-                 * measured to see if it makes any difference. */
+                 * measured to see if it makes any difference.
+                 *
+                 * That would be an interesting test, wouldn't it?  You could
+                 * also try having more than one I/O thread. */
                 while (service_io(dev))
                         write(vblk->done_fd, &c, 1);
         }
@@ -1501,7 +1534,7 @@ static int io_thread(void *_dev)
 }
 
 /* Now we've seen the I/O thread, we return to the Launcher to see what happens
- * when the thread tells us it's completed some I/O. */
+ * when that thread tells us it's completed some I/O. */
 static bool handle_io_finish(int fd, struct device *dev)
 {
         char c;
@@ -1573,11 +1606,12 @@ static void setup_block_file(const char *filename)
          * more work. */
         pipe(vblk->workpipe);
 
-        /* Create stack for thread and run it */
+        /* Create stack for thread and run it.  Since stack grows upwards, we
+         * point the stack pointer to the end of this region. */
         stack = malloc(32768);
         /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from
          * becoming a zombie. */
-        if (clone(io_thread, stack + 32768,  CLONE_VM | SIGCHLD, dev) == -1)
+        if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1)
                 err(1, "Creating clone");
 
         /* We don't need to keep the I/O thread's end of the pipes open. */
@@ -1587,14 +1621,14 @@ static void setup_block_file(const char *filename)
         verbose("device %u: virtblock %llu sectors\n",
                 devices.device_num, le64_to_cpu(conf.capacity));
 }
-/* That's the end of device setup. :*/
+/* That's the end of device setup. */
 
-/* Reboot */
+/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
 static void __attribute__((noreturn)) restart_guest(void)
 {
         unsigned int i;
 
-        /* Closing pipes causes the waker thread and io_threads to die, and
+        /* Closing pipes causes the Waker thread and io_threads to die, and
          * closing /dev/lguest cleans up the Guest.  Since we don't track all
          * open fds, we simply close everything beyond stderr. */
         for (i = 3; i < FD_SETSIZE; i++)
@@ -1603,7 +1637,7 @@ static void __attribute__((noreturn)) restart_guest(void)
         err(1, "Could not exec %s", main_args[0]);
 }
 
-/*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves
+/*L:220 Finally we reach the core of the Launcher which runs the Guest, serves
  * its input and output, and finally, lays it to rest. */
 static void __attribute__((noreturn)) run_guest(int lguest_fd)
 {
@@ -1644,7 +1678,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
                         err(1, "Resetting break");
         }
 }
-/*
+/*L:240
  * This is the end of the Launcher.  The good news: we are over halfway
  * through!  The bad news: the most fiendish part of the code still lies ahead
  * of us.
@@ -1691,8 +1725,8 @@ int main(int argc, char *argv[])
          * device receive input from a file descriptor, we keep an fdset
          * (infds) and the maximum fd number (max_infd) with the head of the
          * list.  We also keep a pointer to the last device.  Finally, we keep
-         * the next interrupt number to hand out (1: remember that 0 is used by
-         * the timer). */
+         * the next interrupt number to use for devices (1: remember that 0 is
+         * used by the timer). */
         FD_ZERO(&devices.infds);
         devices.max_infd = -1;
         devices.lastdev = NULL;
@@ -1793,8 +1827,8 @@ int main(int argc, char *argv[])
         lguest_fd = tell_kernel(pgdir, start);
 
         /* We fork off a child process, which wakes the Launcher whenever one
-         * of the input file descriptors needs attention.  Otherwise we would
-         * run the Guest until it tries to output something. */
+         * of the input file descriptors needs attention.  We call this the
+         * Waker, and we'll cover it in a moment. */
         waker_fd = setup_waker(lguest_fd);
 
         /* Finally, run the Guest.  This doesn't return. */
diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt
index 722d4e7fbebe..29510dc51510 100644
--- a/Documentation/lguest/lguest.txt
+++ b/Documentation/lguest/lguest.txt
@@ -1,6 +1,7 @@
-Rusty's Remarkably Unreliable Guide to Lguest
-        - or, A Young Coder's Illustrated Hypervisor
-http://lguest.ozlabs.org
+      __
+ (___()'`;  Rusty's Remarkably Unreliable Guide to Lguest
+ /,    /`      - or, A Young Coder's Illustrated Hypervisor
+ \\"--\\    http://lguest.ozlabs.org
 
 Lguest is designed to be a minimal hypervisor for the Linux kernel, for
 Linux developers and users to experiment with virtualization with the
@@ -41,12 +42,16 @@ Running Lguest:
          CONFIG_PHYSICAL_ALIGN=0x100000)
 
   "Device Drivers":
+     "Block devices"
+        "Virtio block driver (EXPERIMENTAL)" = M/Y
      "Network device support"
         "Universal TUN/TAP device driver support" = M/Y
-           (CONFIG_TUN=m)
-     "Virtualization"
-        "Linux hypervisor example code" = M/Y
-           (CONFIG_LGUEST=m)
+        "Virtio network driver (EXPERIMENTAL)" = M/Y
+           (CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m and CONFIG_TUN=m)
+
+  "Virtualization"
+     "Linux hypervisor example code" = M/Y
+        (CONFIG_LGUEST=m)
 
 - A tool called "lguest" is available in this directory: type "make"
   to build it.  If you didn't build your kernel in-tree, use "make
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index bd450e797558..95070028d15e 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@@ -95,7 +95,6 @@ RFCOMM_TTY_MAGIC      0x6d02                        net/bluetooth/rfcomm/tty.c
 USB_SERIAL_PORT_MAGIC 0x7301      usb_serial_port   drivers/usb/serial/usb-serial.h
 CG_MAGIC              0x00090255  ufs_cylinder_group include/linux/ufs_fs.h
 A2232_MAGIC           0x000a2232  gs_port           drivers/char/ser_a2232.h
-SOLARIS_SOCKET_MAGIC  0x000ADDED  sol_socket_struct arch/sparc64/solaris/socksys.h
 RPORT_MAGIC           0x00525001  r_port            drivers/char/rocket_int.h
 LSEMAGIC              0x05091998  lse               drivers/fc4/fc.c
 GDTIOCTL_MAGIC        0x06030f07  gdth_iowr_str     drivers/scsi/gdth_ioctl.h
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 396cdd982c26..a8b430627473 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -450,3 +450,9 @@ These currently include
       there are upper and lower limits (32768, 16).  Default is 128.
   strip_cache_active (currently raid5 only)
       number of active entries in the stripe cache
+  preread_bypass_threshold (currently raid5 only)
+      number of times a stripe requiring preread will be bypassed by
+      a stripe that does not require preread.  For fairness defaults
+      to 1.  Setting this to 0 disables bypass accounting and
+      requires preread stripes to wait until all full-width stripe-
+      writes are complete.  Valid values are 0 to stripe_cache_size.
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1f506f7830ec..f5b7127f54ac 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -430,8 +430,8 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
 
         [*] For information on bus mastering DMA and coherency please read:
 
-            Documentation/pci.txt
-            Documentation/DMA-mapping.txt
+            Documentation/PCI/pci.txt
+            Documentation/PCI/PCI-DMA-mapping.txt
             Documentation/DMA-API.txt
 
 
@@ -994,7 +994,17 @@ The Linux kernel has eight basic CPU memory barriers:
         DATA DEPENDENCY read_barrier_depends()  smp_read_barrier_depends()
 
 
-All CPU memory barriers unconditionally imply compiler barriers.
+All memory barriers except the data dependency barriers imply a compiler
+barrier. Data dependencies do not impose any additional compiler ordering.
+
+Aside: In the case of data dependencies, the compiler would be expected to
+issue the loads in the correct order (eg. `a[b]` would have to load the value
+of b before loading a[b]), however there is no guarantee in the C specification
+that the compiler may not speculate the value of b (eg. is equal to 1) and load
+a before b (eg. tmp = a[1]; if (b != 1) tmp = a[b]; ). There is also the
+problem of a compiler reloading b after having loaded a[b], thus having a newer
+copy of b than a[b]. A consensus has not yet been reached about these problems,
+however the ACCESS_ONCE macro is a good place to start looking.
 
 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
 systems because it is assumed that a CPU will appear to be self-consistent,
diff --git a/Documentation/mips/AU1xxx_IDE.README b/Documentation/mips/AU1xxx_IDE.README
index 5c8334123f4f..25a6ed1aaa5b 100644
--- a/Documentation/mips/AU1xxx_IDE.README
+++ b/Documentation/mips/AU1xxx_IDE.README
@@ -46,8 +46,6 @@ Two files are introduced:
 
   a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
      containes : struct _auide_hwif
-                 struct drive_list_entry dma_white_list
-                 struct drive_list_entry dma_black_list
                  timing parameters for PIO mode 0/1/2/3/4
                  timing parameters for MWDMA 0/1/2
 
@@ -63,12 +61,6 @@ Four configs variables are introduced:
   CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size
                                            per descriptor
 
-If MWDMA is enabled and the connected hard disc is not on the white list, the
-kernel switches to a "safe mwdma mode" at boot time. In this mode the IDE
-performance is substantial slower then in full speed mwdma. In this case
-please add your hard disc to the white list (follow instruction from 'ADD NEW
-HARD DISC TO WHITE OR BLACK LIST' section).
-
 
 SUPPORTED IDE MODES
 -------------------
@@ -120,44 +112,6 @@ CONFIG_IDEDMA_AUTO=y
 Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
 disable the burst support on DBDMA controller.
 
-ADD NEW HARD DISC TO WHITE OR BLACK LIST
-----------------------------------------
-
-Step 1 : detect the model name of your hard disc
-
-  a) connect your hard disc to the AU1XXX
-
-  b) boot your kernel and get the hard disc model.
-
-     Example boot log:
-
-     --snipped--
-     Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
-     ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
-     Au1xxx IDE(builtin) configured for MWDMA2
-     Probing IDE interface ide0...
-     hda: Maxtor 6E040L0, ATA DISK drive
-     ide0 at 0xac800000-0xac800007,0xac8001c0 on irq 64
-     hda: max request size: 64KiB
-     hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
-     --snipped--
-
-     In this example 'Maxtor 6E040L0'.
-
-Step  2 : edit 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
-
-  Add your hard disc to the dma_white_list or dma_black_list structur.
-
-Step 3 : Recompile the kernel
-
-  Enable MWDMA support in the kernel configuration. Recompile the kernel and
-  reboot.
-
-Step 4 : Tests
-
-  If you have add a hard disc to the white list, please run some stress tests
-  for verification.
-
 
 ACKNOWLEDGMENTS
 ---------------
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 02e56d447a8f..1634c6dcecae 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -84,9 +84,6 @@ policy-routing.txt
         - IP policy-based routing
 ray_cs.txt
         - Raylink Wireless LAN card driver info.
-sk98lin.txt
-        - Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
-          Ethernet Adapter family driver info
 skfp.txt
         - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
 smc9.txt
@@ -103,8 +100,6 @@ tuntap.txt
         - TUN/TAP device driver, allowing user space Rx/Tx of packets.
 vortex.txt
         - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
-wan-router.txt
-        - WAN router documentation
 wavelan.txt
         - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
 x25.txt
diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt
index 770fc41a78e8..796012540386 100644
--- a/Documentation/networking/arcnet.txt
+++ b/Documentation/networking/arcnet.txt
@@ -46,7 +46,7 @@ These are the ARCnet drivers for Linux.
 
 
 This new release (2.91) has been put together by David Woodhouse 
-<dwmw2@cam.ac.uk>, in an attempt to tidy up the driver after adding support 
+<dwmw2@infradead.org>, in an attempt to tidy up the driver after adding support
 for yet another chipset. Now the generic support has been separated from the
 individual chipset drivers, and the source files aren't quite so packed with
 #ifdefs! I've changed this file a bit, but kept it in the first person from
diff --git a/Documentation/networking/bcm43xx.txt b/Documentation/networking/bcm43xx.txt
deleted file mode 100644
index d602c8d6ff3e..000000000000
--- a/Documentation/networking/bcm43xx.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-
-                        BCM43xx Linux Driver Project
-                        ============================
-
-Introduction
-------------
-
-Many of the wireless devices found in modern notebook computers are
-based on the wireless chips produced by Broadcom. These devices have
-been a problem for Linux users as there is no open-source driver
-available. In addition, Broadcom has not released specifications
-for the device, and driver availability has been limited to the
-binary-only form used in the GPL versions of AP hardware such as the
-Linksys WRT54G, and the Windows and OS X drivers.  Before this project
-began, the only way to use these devices were to use the Windows or
-OS X drivers with either the Linuxant or ndiswrapper modules. There
-is a strong penalty if this method is used as loading the binary-only
-module "taints" the kernel, and no kernel developer will help diagnose
-any kernel problems.
-
-Development
------------
-
-This driver has been developed using
-a clean-room technique that is described at
-http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess. For legal
-reasons, none of the clean-room crew works on the on the Linux driver,
-and none of the Linux developers sees anything but the specifications,
-which are the ultimate product of the reverse-engineering group.
-
-Software
---------
-
-Since the release of the 2.6.17 kernel, the bcm43xx driver has been
-distributed with the kernel source, and is prebuilt in most, if not
-all, distributions.  There is, however, additional software that is
-required. The firmware used by the chip is the intellectual property
-of Broadcom and they have not given the bcm43xx team redistribution
-rights to this firmware.  Since we cannot legally redistribute
-the firmware we cannot include it with the driver. Furthermore, it
-cannot be placed in the downloadable archives of any distributing
-organization; therefore, the user is responsible for obtaining the
-firmware and placing it in the appropriate location so that the driver
-can find it when initializing.
-
-To help with this process, the bcm43xx developers provide a separate
-program named bcm43xx-fwcutter to "cut" the firmware out of a
-Windows or OS X driver and write the extracted files to the proper
-location. This program is usually provided with the distribution;
-however, it may be downloaded from
-
-http://developer.berlios.de/project/showfiles.php?group_id=4547
-
-The firmware is available in two versions. V3 firmware is used with
-the in-kernel bcm43xx driver that uses a software MAC layer called
-SoftMAC, and will have a microcode revision of 0x127 or smaller. The
-V4 firmware is used by an out-of-kernel driver employing a variation of
-the Devicescape MAC layer known as d80211. Once bcm43xx-d80211 reaches
-a satisfactory level of development, it will replace bcm43xx-softmac
-in the kernel as it is much more flexible and powerful.
-
-A source for the latest V3 firmware is
-
-http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o
-
-Once this file is downloaded, the command
-'bcm43xx-fwcutter -w <dir> <filename>'
-will extract the microcode and write it to directory
-<dir>. The correct directory will depend on your distribution;
-however, most use '/lib/firmware'. Once this step is completed,
-the bcm3xx driver should load when the system is booted. To see
-any messages relating to the driver, issue the command 'dmesg |
-grep bcm43xx' from a terminal window. If there are any problems,
-please send that output to Bcm43xx-dev@lists.berlios.de.
-
-Although the driver has been in-kernel since 2.6.17, the earliest
-version is quite limited in its capability. Patches that include
-all features of later versions are available for the stable kernel
-versions from 2.6.18. These will be needed if you use a BCM4318,
-or a PCI Express version (BCM4311 and BCM4312). In addition, if you
-have an early BCM4306 and more than 1 GB RAM, your kernel will need
-to be patched.  These patches, which are being updated regularly,
-are available at ftp://lwfinger.dynalias.org/patches. Look for
-combined_2.6.YY.patch. Of course you will need kernel source downloaded
-from kernel.org, or the source from your distribution.
-
-If you build your own kernel, please enable CONFIG_BCM43XX_DEBUG
-and CONFIG_IEEE80211_SOFTMAC_DEBUG. The log information provided is
-essential for solving any problems.
diff --git a/Documentation/networking/bridge.txt b/Documentation/networking/bridge.txt
index bdae2db4119c..bec69a8a1697 100644
--- a/Documentation/networking/bridge.txt
+++ b/Documentation/networking/bridge.txt
@@ -1,6 +1,6 @@
 In order to use the Ethernet bridging functionality, you'll need the
 userspace tools. These programs and documentation are available
-at http://bridge.sourceforge.net.  The download page is
+at http://www.linux-foundation.org/en/Net:Bridge.  The download page is
 http://prdownloads.sourceforge.net/bridge.
 
 If you still have questions, don't hesitate to post to the mailing list 
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index f1b2de170929..641d2afacffa 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -281,10 +281,10 @@ solution for a couple of reasons:
             sa_family_t can_family;
             int         can_ifindex;
             union {
-                    struct { canid_t rx_id, tx_id; } tp16;
-                    struct { canid_t rx_id, tx_id; } tp20;
-                    struct { canid_t rx_id, tx_id; } mcnet;
-                    struct { canid_t rx_id, tx_id; } isotp;
+                    /* transport protocol class address info (e.g. ISOTP) */
+                    struct { canid_t rx_id, tx_id; } tp;
+
+                    /* reserved for future CAN protocols address information */
             } can_addr;
     };
 
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 17a6e46fbd43..17f1f91af35c 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -81,23 +81,23 @@ inet_peer_minttl - INTEGER
         Minimum time-to-live of entries.  Should be enough to cover fragment
         time-to-live on the reassembling side.  This minimum time-to-live  is
         guaranteed if the pool size is less than inet_peer_threshold.
-        Measured in jiffies(1).
+        Measured in seconds.
 
 inet_peer_maxttl - INTEGER
         Maximum time-to-live of entries.  Unused entries will expire after
         this period of time if there is no memory pressure on the pool (i.e.
         when the number of entries in the pool is very small).
-        Measured in jiffies(1).
+        Measured in seconds.
 
 inet_peer_gc_mintime - INTEGER
         Minimum interval between garbage collection passes.  This interval is
         in effect under high memory pressure on the pool.
-        Measured in jiffies(1).
+        Measured in seconds.
 
 inet_peer_gc_maxtime - INTEGER
         Minimum interval between garbage collection passes.  This interval is
         in effect under low (or absent) memory pressure on the pool.
-        Measured in jiffies(1).
+        Measured in seconds.
 
 TCP variables: 
 
@@ -794,10 +794,6 @@ tag - INTEGER
         Allows you to write a number, which can be used as required.
         Default value is 0.
 
-(1) Jiffie: internal timeunit for the kernel. On the i386 1/100s, on the
-Alpha 1/1024s. See the HZ define in /usr/include/asm/param.h for the exact
-value on your system. 
-
 Alexey Kuznetsov.
 kuznet@ms2.inr.ac.ru
 
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 0bc95eab1512..8df6a7b0e66c 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -1,7 +1,7 @@
 
 -------
 PHY Abstraction Layer
-(Updated 2006-11-30)
+(Updated 2008-04-08)
 
 Purpose
 
@@ -291,3 +291,39 @@ Writing a PHY driver
  Feel free to look at the Marvell, Cicada, and Davicom drivers in
  drivers/net/phy/ for examples (the lxt and qsemi drivers have
  not been tested as of this writing)
+
+Board Fixups
+
+ Sometimes the specific interaction between the platform and the PHY requires
+ special handling.  For instance, to change where the PHY's clock input is,
+ or to add a delay to account for latency issues in the data path.  In order
+ to support such contingencies, the PHY Layer allows platform code to register
+ fixups to be run when the PHY is brought up (or subsequently reset).
+
+ When the PHY Layer brings up a PHY it checks to see if there are any fixups
+ registered for it, matching based on UID (contained in the PHY device's phy_id
+ field) and the bus identifier (contained in phydev->dev.bus_id).  Both must
+ match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
+ wildcards for the bus ID and UID, respectively.
+
+ When a match is found, the PHY layer will invoke the run function associated
+ with the fixup.  This function is passed a pointer to the phy_device of
+ interest.  It should therefore only operate on that PHY.
+
+ The platform code can either register the fixup using phy_register_fixup():
+
+        int phy_register_fixup(const char *phy_id,
+                u32 phy_uid, u32 phy_uid_mask,
+                int (*run)(struct phy_device *));
+
+ Or using one of the two stubs, phy_register_fixup_for_uid() and
+ phy_register_fixup_for_id():
+
+ int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
+                int (*run)(struct phy_device *));
+ int phy_register_fixup_for_id(const char *phy_id,
+                int (*run)(struct phy_device *));
+
+ The stubs set one of the two matching criteria, and set the other one to
+ match anything.
+
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
index 4bde53e85f3f..1e28e2ddb90a 100644
--- a/Documentation/networking/s2io.txt
+++ b/Documentation/networking/s2io.txt
@@ -83,9 +83,9 @@ Valid range: Limited by memory on system
 Default: 30 
 
 e. intr_type
-Specifies interrupt type. Possible values 1(INTA), 2(MSI), 3(MSI-X)
-Valid range: 1-3
-Default: 1 
+Specifies interrupt type. Possible values 0(INTA), 2(MSI-X)
+Valid values: 0, 2
+Default: 2
 
 5.  Performance suggestions
 General:
diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt
deleted file mode 100644
index 8590a954df1d..000000000000
--- a/Documentation/networking/sk98lin.txt
+++ /dev/null
@@ -1,568 +0,0 @@
-(C)Copyright 1999-2004 Marvell(R).
-All rights reserved
-===========================================================================
-
-sk98lin.txt created 13-Feb-2004
-
-Readme File for sk98lin v6.23
-Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX
-
-This file contains
- 1  Overview
- 2  Required Files
- 3  Installation
-    3.1  Driver Installation
-    3.2  Inclusion of adapter at system start
- 4  Driver Parameters
-    4.1  Per-Port Parameters
-    4.2  Adapter Parameters
- 5  Large Frame Support
- 6  VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
- 7  Troubleshooting
-
-===========================================================================
-
-
-1  Overview
-===========
-
-The sk98lin driver supports the Marvell Yukon and SysKonnect 
-SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has 
-been tested with Linux on Intel/x86 machines.
-***
-
-
-2  Required Files
-=================
-
-The linux kernel source.
-No additional files required.
-***
-
-
-3  Installation
-===============
-
-It is recommended to download the latest version of the driver from the 
-SysKonnect web site www.syskonnect.com. If you have downloaded the latest
-driver, the Linux kernel has to be patched before the driver can be 
-installed. For details on how to patch a Linux kernel, refer to the 
-patch.txt file.
-
-3.1  Driver Installation
-------------------------
-
-The following steps describe the actions that are required to install
-the driver and to start it manually. These steps should be carried
-out for the initial driver setup. Once confirmed to be ok, they can
-be included in the system start.
-
-NOTE 1: To perform the following tasks you need 'root' access.
-
-NOTE 2: In case of problems, please read the section "Troubleshooting" 
-        below.
-
-The driver can either be integrated into the kernel or it can be compiled 
-as a module. Select the appropriate option during the kernel 
-configuration.
-
-Compile/use the driver as a module
-----------------------------------
-To compile the driver, go to the directory /usr/src/linux and
-execute the command "make menuconfig" or "make xconfig" and proceed as 
-follows:
-
-To integrate the driver permanently into the kernel, proceed as follows:
-
-1. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
-2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" 
-   with (*) 
-3. Build a new kernel when the configuration of the above options is 
-   finished.
-4. Install the new kernel.
-5. Reboot your system.
-
-To use the driver as a module, proceed as follows:
-
-1. Enable 'loadable module support' in the kernel.
-2. For automatic driver start, enable the 'Kernel module loader'.
-3. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
-4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" 
-   with (M)
-5. Execute the command "make modules".
-6. Execute the command "make modules_install".
-   The appropriate modules will be installed.
-7. Reboot your system.
-
-
-Load the module manually
-------------------------
-To load the module manually, proceed as follows:
-
-1. Enter "modprobe sk98lin".
-2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in 
-   your computer and you have a /proc file system, execute the command:
-   "ls /proc/net/sk98lin/" 
-   This should produce an output containing a line with the following 
-   format:
-   eth0   eth1  ...
-   which indicates that your adapter has been found and initialized.
-   
-   NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx 
-           adapter installed, the adapters will be listed as 'eth0', 
-                   'eth1', 'eth2', etc.
-                   For each adapter, repeat steps 3 and 4 below.
-
-   NOTE 2: If you have other Ethernet adapters installed, your Marvell
-           Yukon or SysKonnect SK-98xx adapter will be mapped to the 
-                   next available number, e.g. 'eth1'. The mapping is executed 
-                   automatically.
-           The module installation message (displayed either in a system
-           log file or on the console) prints a line for each adapter 
-           found containing the corresponding 'ethX'.
-
-3. Select an IP address and assign it to the respective adapter by 
-   entering:
-   ifconfig eth0 <ip-address>
-   With this command, the adapter is connected to the Ethernet. 
-   
-   SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter 
-   is now active, the link status LED of the primary port is active and 
-   the link status LED of the secondary port (on dual port adapters) is 
-   blinking (if the ports are connected to a switch or hub).
-   SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active.
-   In addition, you will receive a status message on the console stating
-   "ethX: network connection up using port Y" and showing the selected 
-   connection parameters (x stands for the ethernet device number 
-   (0,1,2, etc), y stands for the port name (A or B)).
-
-   NOTE: If you are in doubt about IP addresses, ask your network
-         administrator for assistance.
-  
-4. Your adapter should now be fully operational.
-   Use 'ping <otherstation>' to verify the connection to other computers 
-   on your network.
-5. To check the adapter configuration view /proc/net/sk98lin/[devicename].
-   For example by executing:    
-   "cat /proc/net/sk98lin/eth0" 
-
-Unload the module
------------------
-To stop and unload the driver modules, proceed as follows:
-
-1. Execute the command "ifconfig eth0 down".
-2. Execute the command "rmmod sk98lin".
-
-3.2  Inclusion of adapter at system start
------------------------------------------
-
-Since a large number of different Linux distributions are 
-available, we are unable to describe a general installation procedure
-for the driver module.
-Because the driver is now integrated in the kernel, installation should
-be easy, using the standard mechanism of your distribution.
-Refer to the distribution's manual for installation of ethernet adapters.
-
-***
-
-4  Driver Parameters
-====================
-
-Parameters can be set at the command line after the module has been 
-loaded with the command 'modprobe'.
-In some distributions, the configuration tools are able to pass parameters
-to the driver module.
-
-If you use the kernel module loader, you can set driver parameters
-in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier).
-To set the driver parameters in this file, proceed as follows:
-
-1. Insert a line of the form :
-   options sk98lin ...
-   For "...", the same syntax is required as described for the command
-   line parameters of modprobe below.
-2. To activate the new parameters, either reboot your computer
-   or 
-   unload and reload the driver.
-   The syntax of the driver parameters is:
-
-        modprobe sk98lin parameter=value1[,value2[,value3...]]
-
-   where value1 refers to the first adapter, value2 to the second etc.
-
-NOTE: All parameters are case sensitive. Write them exactly as shown 
-      below.
-
-Example:
-Suppose you have two adapters. You want to set auto-negotiation
-on the first adapter to ON and on the second adapter to OFF.
-You also want to set DuplexCapabilities on the first adapter
-to FULL, and on the second adapter to HALF.
-Then, you must enter:
-
-        modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half
-
-NOTE: The number of adapters that can be configured this way is
-      limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM).
-      The current limit is 16. If you happen to install
-      more adapters, adjust this and recompile.
-
-
-4.1  Per-Port Parameters
-------------------------
-
-These settings are available for each port on the adapter.
-In the following description, '?' stands for the port for
-which you set the parameter (A or B).
-
-Speed
------
-Parameter:    Speed_?
-Values:       10, 100, 1000, Auto
-Default:      Auto
-
-This parameter is used to set the speed capabilities. It is only valid 
-for the SK-98xx V2.0 copper adapters.
-Usually, the speed is negotiated between the two ports during link 
-establishment. If this fails, a port can be forced to a specific setting
-with this parameter.
-
-Auto-Negotiation
-----------------
-Parameter:    AutoNeg_?
-Values:       On, Off, Sense
-Default:      On
-  
-The "Sense"-mode automatically detects whether the link partner supports
-auto-negotiation or not.
-
-Duplex Capabilities
--------------------
-Parameter:    DupCap_?
-Values:       Half, Full, Both
-Default:      Both
-
-This parameters is only relevant if auto-negotiation for this port is 
-not set to "Sense". If auto-negotiation is set to "On", all three values
-are possible. If it is set to "Off", only "Full" and "Half" are allowed.
-This parameter is useful if your link partner does not support all
-possible combinations.
-
-Flow Control
-------------
-Parameter:    FlowCtrl_?
-Values:       Sym, SymOrRem, LocSend, None
-Default:      SymOrRem
-
-This parameter can be used to set the flow control capabilities the 
-port reports during auto-negotiation. It can be set for each port 
-individually.
-Possible modes:
-   -- Sym      = Symmetric: both link partners are allowed to send 
-                  PAUSE frames
-   -- SymOrRem = SymmetricOrRemote: both or only remote partner 
-                  are allowed to send PAUSE frames
-   -- LocSend  = LocalSend: only local link partner is allowed 
-                  to send PAUSE frames
-   -- None     = no link partner is allowed to send PAUSE frames
-  
-NOTE: This parameter is ignored if auto-negotiation is set to "Off".
-
-Role in Master-Slave-Negotiation (1000Base-T only)
---------------------------------------------------
-Parameter:    Role_?
-Values:       Auto, Master, Slave
-Default:      Auto
-
-This parameter is only valid for the SK-9821 and SK-9822 adapters.
-For two 1000Base-T ports to communicate, one must take the role of the
-master (providing timing information), while the other must be the 
-slave. Usually, this is negotiated between the two ports during link 
-establishment. If this fails, a port can be forced to a specific setting
-with this parameter.
-
-
-4.2  Adapter Parameters
------------------------
-
-Connection Type (SK-98xx V2.0 copper adapters only)
----------------
-Parameter:    ConType
-Values:       Auto, 100FD, 100HD, 10FD, 10HD
-Default:      Auto
-
-The parameter 'ConType' is a combination of all five per-port parameters
-within one single parameter. This simplifies the configuration of both ports
-of an adapter card! The different values of this variable reflect the most 
-meaningful combinations of port parameters.
-
-The following table shows the values of 'ConType' and the corresponding
-combinations of the per-port parameters:
-
-    ConType   |  DupCap   AutoNeg   FlowCtrl   Role             Speed
-    ----------+------------------------------------------------------
-    Auto      |  Both     On        SymOrRem   Auto             Auto
-    100FD     |  Full     Off       None       Auto (ignored)   100
-    100HD     |  Half     Off       None       Auto (ignored)   100
-    10FD      |  Full     Off       None       Auto (ignored)   10
-    10HD      |  Half     Off       None       Auto (ignored)   10
-
-Stating any other port parameter together with this 'ConType' variable
-will result in a merged configuration of those settings. This due to 
-the fact, that the per-port parameters (e.g. Speed_? ) have a higher
-priority than the combined variable 'ConType'.
-
-NOTE: This parameter is always used on both ports of the adapter card.
-
-Interrupt Moderation
---------------------
-Parameter:    Moderation
-Values:       None, Static, Dynamic
-Default:      None
-
-Interrupt moderation is employed to limit the maximum number of interrupts
-the driver has to serve. That is, one or more interrupts (which indicate any
-transmit or receive packet to be processed) are queued until the driver 
-processes them. When queued interrupts are to be served, is determined by the
-'IntsPerSec' parameter, which is explained later below.
-
-Possible modes:
-
-   -- None - No interrupt moderation is applied on the adapter card. 
-      Therefore, each transmit or receive interrupt is served immediately
-      as soon as it appears on the interrupt line of the adapter card.
-
-   -- Static - Interrupt moderation is applied on the adapter card. 
-      All transmit and receive interrupts are queued until a complete
-      moderation interval ends. If such a moderation interval ends, all
-      queued interrupts are processed in one big bunch without any delay.
-      The term 'static' reflects the fact, that interrupt moderation is
-      always enabled, regardless how much network load is currently 
-      passing via a particular interface. In addition, the duration of
-      the moderation interval has a fixed length that never changes while
-      the driver is operational.
-
-   -- Dynamic - Interrupt moderation might be applied on the adapter card,
-      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 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
-interfaces with a high network load, which - as a consequence - leads also to a
-high CPU utilization. When moderation is applied in such high network load 
-situations, CPU load might be reduced by 20-30%.
-
-NOTE: The drawback of using interrupt moderation is an increase of the round-
-trip-time (RTT), due to the queueing and serving of interrupts at dedicated
-moderation times.
-
-Interrupts per second
----------------------
-Parameter:    IntsPerSec
-Values:       30...40000 (interrupts per second)
-Default:      2000
-
-This parameter is only used if either static or dynamic interrupt moderation
-is used on a network adapter card. Using this parameter if no moderation is
-applied will lead to no action performed.
-
-This parameter determines the length of any interrupt moderation interval. 
-Assuming that static interrupt moderation is to be used, an 'IntsPerSec' 
-parameter value of 2000 will lead to an interrupt moderation interval of
-500 microseconds. 
-
-NOTE: The duration of the moderation interval is to be chosen with care.
-At first glance, selecting a very long duration (e.g. only 100 interrupts per 
-second) seems to be meaningful, but the increase of packet-processing delay 
-is tremendous. On the other hand, selecting a very short moderation time might
-compensate the use of any moderation being applied.
-
-
-Preferred Port
---------------
-Parameter:    PrefPort
-Values:       A, B
-Default:      A
-
-This is used to force the preferred port to A or B (on dual-port network 
-adapters). The preferred port is the one that is used if both are detected
-as fully functional.
-
-RLMT Mode (Redundant Link Management Technology)
-------------------------------------------------
-Parameter:    RlmtMode
-Values:       CheckLinkState,CheckLocalPort, CheckSeg, DualNet
-Default:      CheckLinkState
-
-RLMT monitors the status of the port. If the link of the active port 
-fails, RLMT switches immediately to the standby link. The virtual link is 
-maintained as long as at least one 'physical' link is up. 
-
-Possible modes:
-
-   -- CheckLinkState - Check link state only: RLMT uses the link state
-      reported by the adapter hardware for each individual port to 
-      determine whether a port can be used for all network traffic or 
-      not.
-
-   -- CheckLocalPort - In this mode, RLMT monitors the network path 
-      between the two ports of an adapter by regularly exchanging packets
-      between them. This mode requires a network configuration in which 
-      the two ports are able to "see" each other (i.e. there must not be 
-      any router between the ports).
-
-   -- CheckSeg - Check local port and segmentation: This mode supports the
-      same functions as the CheckLocalPort mode and additionally checks 
-      network segmentation between the ports. Therefore, this mode is only
-      to be used if Gigabit Ethernet switches are installed on the network
-      that have been configured to use the Spanning Tree protocol. 
-
-   -- DualNet - In this mode, ports A and B are used as separate devices. 
-      If you have a dual port adapter, port A will be configured as eth0 
-      and port B as eth1. Both ports can be used independently with 
-      distinct IP addresses. The preferred port setting is not used. 
-      RLMT is turned off.
-   
-NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations 
-      where a network path between the ports on one adapter exists. 
-      Moreover, they are not designed to work where adapters are connected
-      back-to-back.
-***
-
-
-5  Large Frame Support
-======================
-
-The driver supports large frames (also called jumbo frames). Using large 
-frames can result in an improved throughput if transferring large amounts 
-of data.
-To enable large frames, set the MTU (maximum transfer unit) of the 
-interface to the desired value (up to 9000), execute the following 
-command:
-      ifconfig eth0 mtu 9000
-This will only work if you have two adapters connected back-to-back
-or if you use a switch that supports large frames. When using a switch, 
-it should be configured to allow large frames and auto-negotiation should  
-be set to OFF. The setting must be configured on all adapters that can be 
-reached by the large frames. If one adapter is not set to receive large 
-frames, it will simply drop them.
-
-You can switch back to the standard ethernet frame size by executing the 
-following command:
-      ifconfig eth0 mtu 1500
-
-To permanently configure this setting, add a script with the 'ifconfig' 
-line to the system startup sequence (named something like "S99sk98lin" 
-in /etc/rc.d/rc2.d).
-***
-
-
-6  VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
-==================================================================
-
-The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and 
-Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad. 
-These features are only available after installation of open source 
-modules available on the Internet:
-For VLAN go to: http://www.candelatech.com/~greear/vlan.html
-For Link Aggregation go to: http://www.st.rim.or.jp/~yumo
-
-NOTE: SysKonnect GmbH does not offer any support for these open source 
-      modules and does not take the responsibility for any kind of 
-      failures or problems arising in connection with these modules.
-
-NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may 
-      cause problems when unloading the driver.
-
-
-7  Troubleshooting
-==================
-
-If any problems occur during the installation process, check the 
-following list:
-
-
-Problem:  The SK-98xx adapter cannot be found by the driver.
-Solution: In /proc/pci search for the following entry:
-             'Ethernet controller: SysKonnect SK-98xx ...'
-          If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has 
-          been found by the system and should be operational.
-          If this entry does not exist or if the file '/proc/pci' is not 
-          found, there may be a hardware problem or the PCI support may 
-          not be enabled in your kernel.
-          The adapter can be checked using the diagnostics program which 
-          is available on the SysKonnect web site:
-          www.syskonnect.com
-          
-          Some COMPAQ machines have problems dealing with PCI under Linux.
-          This problem is described in the 'PCI howto' document
-          (included in some distributions or available from the
-          web, e.g. at 'www.linux.org'). 
-
-
-Problem:  Programs such as 'ifconfig' or 'route' cannot be found or the 
-          error message 'Operation not permitted' is displayed.
-Reason:   You are not logged in as user 'root'.
-Solution: Logout and login as 'root' or change to 'root' via 'su'.
-
-
-Problem:  Upon use of the command 'ping <address>' the message
-          "ping: sendto: Network is unreachable" is displayed.
-Reason:   Your route is not set correctly.
-Solution: If you are using RedHat, you probably forgot to set up the 
-          route in the 'network configuration'.
-          Check the existing routes with the 'route' command and check 
-          if an entry for 'eth0' exists, and if so, if it is set correctly.
-
-
-Problem:  The driver can be started, the adapter is connected to the 
-          network, but you cannot receive or transmit any packets; 
-          e.g. 'ping' does not work.
-Reason:   There is an incorrect route in your routing table.
-Solution: Check the routing table with the command 'route' and read the 
-          manual help pages dealing with routes (enter 'man route').
-
-NOTE: Although the 2.2.x kernel versions generate the routing entry 
-      automatically, problems of this kind may occur here as well. We've 
-      come across a situation in which the driver started correctly at 
-      system start, but after the driver has been removed and reloaded,
-      the route of the adapter's network pointed to the 'dummy0'device 
-      and had to be corrected manually.
-
-
-Problem:  Your computer should act as a router between multiple 
-          IP subnetworks (using multiple adapters), but computers in 
-          other subnetworks cannot be reached.
-Reason:   Either the router's kernel is not configured for IP forwarding 
-          or the routing table and gateway configuration of at least one 
-          computer is not working.
-
-Problem:  Upon driver start, the following error message is displayed:
-          "eth0: -- ERROR --
-          Class: internal Software error
-          Nr:    0xcc
-          Msg:   SkGeInitPort() cannot init running ports"
-Reason:   You are using a driver compiled for single processor machines 
-          on a multiprocessor machine with SMP (Symmetric MultiProcessor) 
-          kernel.
-Solution: Configure your kernel appropriately and recompile the kernel or
-          the modules.
-
-
-
-If your problem is not listed here, please contact SysKonnect's technical
-support for help (linux@syskonnect.de).
-When contacting our technical support, please ensure that the following 
-information is available:
-- System Manufacturer and HW Informations (CPU, Memory... )
-- PCI-Boards in your system
-- Distribution
-- Kernel version
-- Driver version
-***
-
-
-
-***End of Readme File***
diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt
deleted file mode 100644
index bc2ab419a74a..000000000000
--- a/Documentation/networking/wan-router.txt
+++ /dev/null
@@ -1,621 +0,0 @@
-------------------------------------------------------------------------------
-Linux WAN Router Utilities Package
-------------------------------------------------------------------------------
-Version 2.2.1 
-Mar 28, 2001
-Author: Nenad Corbic <ncorbic@sangoma.com>
-Copyright (c) 1995-2001 Sangoma Technologies Inc.
-------------------------------------------------------------------------------
-
-INTRODUCTION
-
-Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
-and/or stand-alone hosts over vast distances with data transfer rates
-significantly higher than those achievable with commonly used dial-up
-connections.
-
-Usually an external device called `WAN router' sitting on your local network
-or connected to your machine's serial port provides physical connection to
-WAN.  Although router's job may be as simple as taking your local network
-traffic, converting it to WAN format and piping it through the WAN link, these
-devices are notoriously expensive, with prices as much as 2 - 5 times higher
-then the price of a typical PC box.
-
-Alternatively, considering robustness and multitasking capabilities of Linux,
-an internal router can be built (most routers use some sort of stripped down
-Unix-like operating system anyway). With a number of relatively inexpensive WAN
-interface cards available on the market, a perfectly usable router can be
-built for less than half a price of an external router.  Yet a Linux box
-acting as a router can still be used for other purposes, such as fire-walling,
-running FTP, WWW or DNS server, etc.
-
-This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
-operating system and provides generic hardware-independent services for such
-drivers.  Why can existing Linux network device interface not be used for
-this purpose?  Well, it can.  However, there are a few key differences between
-a typical network interface (e.g. Ethernet) and a WAN link.
-
-Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
-connections (known as `virtual circuits' in X.25 terminology) over a single
-physical link.  Each such virtual circuit may (and almost always does) lead
-to a different geographical location and, therefore, different network.  As a
-result, it is the virtual circuit, not the physical link, that represents a
-route and, therefore, a network interface in Linux terms.
-
-To further complicate things, virtual circuits are usually volatile in nature
-(excluding so called `permanent' virtual circuits or PVCs).  With almost no
-time required to set up and tear down a virtual circuit, it is highly desirable
-to implement on-demand connections in order to minimize network charges.  So
-unlike a typical network driver, the WAN driver must be able to handle multiple
-network interfaces and cope as multiple virtual circuits come into existence
-and go away dynamically.
- 
-Last, but not least, WAN configuration is much more complex than that of say
-Ethernet and may well amount to several dozens of parameters.  Some of them
-are "link-wide"  while others are virtual circuit-specific.  The same holds
-true for WAN statistics which is by far more extensive and extremely useful
-when troubleshooting WAN connections.  Extending the ifconfig utility to suit
-these needs may be possible, but does not seem quite reasonable.  Therefore, a
-WAN configuration utility and corresponding application programmer's interface
-is needed for this purpose.
-
-Most of these problems are taken care of by this module.  Its goal is to
-provide a user with more-or-less standard look and feel for all WAN devices and
-assist a WAN device driver writer by providing common services, such as:
-
- o User-level interface via /proc file system
- o Centralized configuration
- o Device management (setup, shutdown, etc.)
- o Network interface management (dynamic creation/destruction)
- o Protocol encapsulation/decapsulation
-
-To ba able to use the Linux WAN Router you will also need a WAN Tools package
-available from
-
-        ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
-
-where vX.Y.Z represent the wanpipe version number.
-
-For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
-For general inquiries please contact Sangoma Technologies Inc. by
-
-        Hotline:        1-800-388-2475  (USA and Canada, toll free)
-        Phone:          (905) 474-1990  ext: 106
-        Fax:            (905) 474-9223
-        E-mail:         dm@sangoma.com  (David Mandelstam)
-        WWW:            http://www.sangoma.com
-
-
-INSTALLATION
-
-Please read the WanpipeForLinux.pdf manual on how to 
-install the WANPIPE tools and drivers properly. 
-
-
-After installing wanpipe package: /usr/local/wanrouter/doc. 
-On the ftp.sangoma.com : /linux/current_wanpipe/doc
-
-
-COPYRIGHT AND LICENSING INFORMATION
-
-This program is free software; you can redistribute it and/or modify it under
-the terms of the GNU General Public License as published by the Free Software
-Foundation; either version 2, or (at your option) any later version.
-
-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.
-
-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., 675 Mass
-Ave, Cambridge, MA 02139, USA.
-
-
-
-ACKNOWLEDGEMENTS
-
-This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
-by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x.  Success of the WANPIPE
-together with the next major release of Linux kernel in summer 1996 commanded
-adequate changes to the WANPIPE code to take full advantage of new Linux
-features.
-
-Instead of continuing developing proprietary interface tied to Sangoma WAN
-cards, we decided to separate all hardware-independent code into a separate
-module and defined two levels of interfaces - one for user-level applications
-and another for kernel-level WAN drivers.  WANPIPE is now implemented as a
-WAN driver compliant with the WAN Link Driver interface.  Also a general
-purpose WAN configuration utility and a set of shell scripts was developed to 
-support WAN router at the user level.
-
-Many useful ideas concerning hardware-independent interface implementation
-were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
-of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
-
-With the new implementation of the APIs being incorporated into the WANPIPE,
-a special thank goes to Alan Cox in providing insight into BSD sockets.
-
-Special thanks to all the WANPIPE users who performed field-testing, reported
-bugs and made valuable comments and suggestions that help us to improve this
-product.
-
-
-
-NEW IN THIS RELEASE
-
-        o Updated the WANCFG utility
-                Calls the pppconfig to configure the PPPD
-                for async connections.
-
-        o Added the PPPCONFIG utility
-                Used to configure the PPPD daemon for the
-                WANPIPE Async PPP and standard serial port.
-                The wancfg calls the pppconfig to configure
-                the pppd.
-
-        o Fixed the PCI autodetect feature.  
-                The SLOT 0 was used as an autodetect option
-                however, some high end PC's slot numbers start
-                from 0. 
-
-        o This release has been tested with the new backupd
-          daemon release.
-        
-
-PRODUCT COMPONENTS AND RELATED FILES
-
-/etc: (or user defined)
-        wanpipe1.conf   default router configuration file
-
-/lib/modules/X.Y.Z/misc:
-        wanrouter.o     router kernel loadable module
-        af_wanpipe.o    wanpipe api socket module
-
-/lib/modules/X.Y.Z/net:
-        sdladrv.o       Sangoma SDLA support module
-        wanpipe.o       Sangoma WANPIPE(tm) driver module
-
-/proc/net/wanrouter
-        Config          reads current router configuration
-        Status          reads current router status
-        {name}          reads WAN driver statistics
-
-/usr/sbin:
-        wanrouter       wanrouter start-up script
-        wanconfig       wanrouter configuration utility
-        sdladump        WANPIPE adapter memory dump utility
-        fpipemon        Monitor for Frame Relay
-        cpipemon        Monitor for Cisco HDLC
-        ppipemon        Monitor for PPP
-        xpipemon        Monitor for X25
-        wpkbdmon        WANPIPE keyboard led monitor/debugger
-
-/usr/local/wanrouter:
-        README          this file
-        COPYING         GNU General Public License
-        Setup           installation script
-        Filelist        distribution definition file
-        wanrouter.rc    meta-configuration file 
-                        (used by the Setup and wanrouter script)
-
-/usr/local/wanrouter/doc:
-        wanpipeForLinux.pdf     WAN Router User's Manual
-
-/usr/local/wanrouter/patches:
-        wanrouter-v2213.gz      patch for Linux kernels 2.2.11 up to 2.2.13.
-        wanrouter-v2214.gz      patch for Linux kernel 2.2.14. 
-        wanrouter-v2215.gz      patch for Linux kernels 2.2.15 to 2.2.17.
-        wanrouter-v2218.gz      patch for Linux kernels 2.2.18 and up.
-        wanrouter-v240.gz       patch for Linux kernel 2.4.0.  
-        wanrouter-v242.gz       patch for Linux kernel 2.4.2 and up.
-        wanrouter-v2034.gz      patch for Linux kernel 2.0.34
-        wanrouter-v2036.gz      patch for Linux kernel 2.0.36 and up. 
-
-/usr/local/wanrouter/patches/kdrivers:
-        Sources of the latest WANPIPE device drivers.
-        These are used to UPGRADE the linux kernel to the newest
-        version if the kernel source has already been patched with
-        WANPIPE drivers.
-
-/usr/local/wanrouter/samples:
-        interface       sample interface configuration file
-        wanpipe1.cpri   CHDLC primary port
-        wanpipe2.csec   CHDLC secondary port
-        wanpipe1.fr     Frame Relay protocol
-        wanpipe1.ppp    PPP protocol ) 
-        wanpipe1.asy    CHDLC ASYNC protocol
-        wanpipe1.x25    X25 protocol
-        wanpipe1.stty   Sync TTY driver (Used by Kernel PPPD daemon)
-        wanpipe1.atty   Async TTY driver (Used by Kernel PPPD daemon)
-        wanrouter.rc    sample meta-configuration file
-
-/usr/local/wanrouter/util:
-        *               wan-tools utilities source code
-
-/usr/local/wanrouter/api/x25:
-        *               x25 api sample programs.
-/usr/local/wanrouter/api/chdlc:
-        *               chdlc api sample programs.
-/usr/local/wanrouter/api/fr:
-        *               fr api sample programs.
-/usr/local/wanrouter/config/wancfg:
-        wancfg          WANPIPE GUI configuration program.
-                        Creates wanpipe#.conf files. 
-/usr/local/wanrouter/config/cfgft1:
-        cfgft1          GUI CSU/DSU configuration program.
-
-/usr/include/linux:
-        wanrouter.h     router API definitions
-        wanpipe.h       WANPIPE API definitions
-        sdladrv.h       SDLA support module API definitions
-        sdlasfm.h       SDLA firmware module definitions
-        if_wanpipe.h    WANPIPE Socket definitions
-        sdlapci.h       WANPIPE PCI definitions
-        
-
-/usr/src/linux/net/wanrouter:
-        *               wanrouter source code
-
-/var/log:
-        wanrouter       wanrouter start-up log (created by the Setup script)
-
-/var/lock:  (or /var/lock/subsys for RedHat)
-        wanrouter       wanrouter lock file (created by the Setup script)
-
-/usr/local/wanrouter/firmware:
-        fr514.sfm       Frame relay firmware for Sangoma S508/S514 card
-        cdual514.sfm    Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
-        ppp514.sfm      PPP Firmware for Sangoma S508 and S514 cards
-        x25_508.sfm     X25 Firmware for Sangoma S508 card.
-
-
-REVISION HISTORY
-
-1.0.0   December 31, 1996       Initial version
-
-1.0.1   January 30, 1997        Status and statistics can be read via /proc
-                                filesystem entries.
-
-1.0.2   April 30, 1997          Added UDP management via monitors.
-
-1.0.3   June 3, 1997            UDP management for multiple boards using Frame
-                                Relay and PPP
-                                Enabled continuous transmission of Configure 
-                                Request Packet for PPP (for 508 only)
-                                Connection Timeout for PPP changed from 900 to 0
-                                Flow Control Problem fixed for Frame Relay
-
-1.0.4   July 10, 1997           S508/FT1 monitoring capability in fpipemon and
-                                ppipemon utilities.
-                                Configurable TTL for UDP packets.
-                                Multicast and Broadcast IP source addresses are
-                                silently discarded.
-
-1.0.5   July 28, 1997           Configurable T391,T392,N391,N392,N393 for Frame
-                                Relay in router.conf.
-                                Configurable Memory Address through router.conf 
-                                for Frame Relay, PPP and X.25. (commenting this
-                                out enables auto-detection).
-                                Fixed freeing up received buffers using kfree()
-                                for Frame Relay and X.25.
-                                Protect sdla_peek() by calling save_flags(),
-                                cli() and restore_flags().
-                                Changed number of Trace elements from 32 to 20
-                                Added DLCI specific data monitoring in FPIPEMON. 
-2.0.0   Nov 07, 1997            Implemented protection of RACE conditions by 
-                                critical flags for FRAME RELAY and PPP.
-                                DLCI List interrupt mode implemented.
-                                IPX support in FRAME RELAY and PPP.
-                                IPX Server Support (MARS)
-                                More driver specific stats included in FPIPEMON
-                                and PIPEMON.
-
-2.0.1   Nov 28, 1997            Bug Fixes for version 2.0.0.
-                                Protection of "enable_irq()" while 
-                                "disable_irq()" has been enabled from any other
-                                routine (for Frame Relay, PPP and X25).
-                                Added additional Stats for Fpipemon and Ppipemon
-                                Improved Load Sharing for multiple boards
-
-2.0.2   Dec 09, 1997            Support for PAP and CHAP for ppp has been
-                                implemented.
-
-2.0.3   Aug 15, 1998            New release supporting Cisco HDLC, CIR for Frame
-                                relay, Dynamic IP assignment for PPP and Inverse
-                                Arp support for Frame-relay.  Man Pages are 
-                                included for better support and a new utility
-                                for configuring FT1 cards.
-
-2.0.4   Dec 09, 1998            Dual Port support for Cisco HDLC.
-                                Support for HDLC (LAPB) API.
-                                Supports BiSync Streaming code for S502E 
-                                and S503 cards.
-                                Support for Streaming HDLC API.
-                                Provides a BSD socket interface for 
-                                creating applications using BiSync
-                                streaming.        
-
-2.0.5   Aug 04, 1999            CHDLC initialization bug fix.
-                                PPP interrupt driven driver: 
-                                Fix to the PPP line hangup problem.
-                                New PPP firmware
-                                Added comments to the startup SYSTEM ERROR messages
-                                Xpipemon debugging application for the X25 protocol
-                                New USER_MANUAL.txt
-                                Fixed the odd boundary 4byte writes to the board.
-                                BiSync Streaming code has been taken out.  
-                                 Available as a patch.
-                                Streaming HDLC API has been taken out.  
-                                 Available as a patch.                 
-
-2.0.6   Aug 17, 1999            Increased debugging in statup scripts
-                                Fixed installation bugs from 2.0.5
-                                Kernel patch works for both 2.2.10 and 2.2.11 kernels.
-                                There is no functional difference between the two packages         
-
-2.0.7   Aug 26, 1999            o  Merged X25API code into WANPIPE.
-                                o  Fixed a memory leak for X25API
-                                o  Updated the X25API code for 2.2.X kernels.
-                                o  Improved NEM handling.   
-
-2.1.0   Oct 25, 1999            o New code for S514 PCI Card
-                                o New CHDLC and Frame Relay drivers
-                                o PPP and X25 are not supported in this release    
-
-2.1.1   Nov 30, 1999            o PPP support for S514 PCI Cards
-
-2.1.3   Apr 06, 2000            o Socket based x25api 
-                                o Socket based chdlc api
-                                o Socket based fr api
-                                o Dual Port Receive only CHDLC support.
-                                o Asynchronous CHDLC support (Secondary Port)
-                                o cfgft1 GUI csu/dsu configurator
-                                o wancfg GUI configuration file 
-                                  configurator.
-                                o Architectural directory changes.
-
-beta-2.1.4 Jul 2000             o Dynamic interface configuration:
-                                        Network interfaces reflect the state
-                                        of protocol layer.  If the protocol becomes
-                                        disconnected, driver will bring down
-                                        the interface.  Once the protocol reconnects
-                                        the interface will be brought up. 
-                                        
-                                        Note: This option is turned off by default.
-
-                                o Dynamic wanrouter setup using 'wanconfig':
-                                        wanconfig utility can be used to
-                                        shutdown,restart,start or reconfigure 
-                                        a virtual circuit dynamically.
-                                     
-                                        Frame Relay:  Each DLCI can be: 
-                                                      created,stopped,restarted and reconfigured
-                                                      dynamically using wanconfig.
-                                        
-                                                      ex: wanconfig card wanpipe1 dev wp1_fr16 up
-                                  
-                                o Wanrouter startup via command line arguments:
-                                        wanconfig also supports wanrouter startup via command line
-                                        arguments.  Thus, there is no need to create a wanpipe#.conf
-                                        configuration file.  
-
-                                o Socket based x25api update/bug fixes.
-                                        Added support for LCN numbers greater than 255.
-                                        Option to pass up modem messages.
-                                        Provided a PCI IRQ check, so a single S514
-                                        card is guaranteed to have a non-sharing interrupt.
-
-                                o Fixes to the wancfg utility.
-                                o New FT1 debugging support via *pipemon utilities.
-                                o Frame Relay ARP support Enabled.
-
-beta3-2.1.4 Jul 2000            o X25 M_BIT Problem fix.
-                                o Added the Multi-Port PPP
-                                  Updated utilities for the Multi-Port PPP.
-
-2.1.4   Aut 2000
-                                o In X25API:
-                                        Maximum packet an application can send
-                                        to the driver has been extended to 4096 bytes.
-
-                                        Fixed the x25 startup bug. Enable 
-                                        communications only after all interfaces
-                                        come up.  HIGH SVC/PVC is used to calculate
-                                        the number of channels.
-                                        Enable protocol only after all interfaces
-                                        are enabled.
-
-                                o Added an extra state to the FT1 config, kernel module.
-                                o Updated the pipemon debuggers.
-
-                                o Blocked the Multi-Port PPP from running on kernels
-                                  2.2.16 or greater, due to syncppp kernel module
-                                  change. 
-          
-beta1-2.1.5     Nov 15 2000
-                                o Fixed the MultiPort PPP Support for kernels 2.2.16 and above.
-                                  2.2.X kernels only
-
-                                o Secured the driver UDP debugging calls
-                                        - All illegal network debugging calls are reported to
-                                          the log.
-                                        - Defined a set of allowed commands, all other denied.
-                                        
-                                o Cpipemon
-                                        - Added set FT1 commands to the cpipemon. Thus CSU/DSU
-                                          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 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)
-                                        CAPS_LOCK   = Tx data     (On=transmitting, Off=no tx data)
-                                        SCROLL_LOCK = Rx data     (On=receiving,    Off=no rx data
-                                        
-                                o Hardware probe on module load and dynamic device allocation
-                                        - During WANPIPE module load, all Sangoma cards are probed
-                                          and found information is printed in the /var/log/messages.
-                                        - If no cards are found, the module load fails.
-                                        - Appropriate number of devices are dynamically loaded 
-                                          based on the number of Sangoma cards found.
-
-                                          Note: The kernel configuration option 
-                                                CONFIG_WANPIPE_CARDS has been taken out.
-                                        
-                                o Fixed the Frame Relay and Chdlc network interfaces so they are
-                                  compatible with libpcap libraries.  Meaning, tcpdump, snort,
-                                  ethereal, and all other packet sniffers and debuggers work on
-                                  all WANPIPE network interfaces.
-                                        - Set the network interface encoding type to ARPHRD_PPP.
-                                          This tell the sniffers that data obtained from the
-                                          network interface is in pure IP format.
-                                  Fix for 2.2.X kernels only.
-                                
-                                o True interface encoding option for Frame Relay and CHDLC
-                                        - The above fix sets the network interface encoding
-                                          type to ARPHRD_PPP, however some customers use
-                                          the encoding interface type to determine the
-                                          protocol running.  Therefore, the TURE ENCODING
-                                          option will set the interface type back to the
-                                          original value.  
-
-                                          NOTE: If this option is used with Frame Relay and CHDLC
-                                                libpcap library support will be broken.  
-                                                i.e. tcpdump will not work.
-                                        Fix for 2.2.x Kernels only.
-                                                
-                                o Ethernet Bridgind over Frame Relay
-                                        - The Frame Relay bridging has been developed by 
-                                          Kristian Hoffmann and Mark Wells.  
-                                        - The Linux kernel bridge is used to send ethernet 
-                                          data over the frame relay links.
-                                        For 2.2.X Kernels only.
-
-                                o Added extensive 2.0.X support. Most new features of
-                                  2.1.5 for protocols Frame Relay, PPP and CHDLC are
-                                  supported under 2.0.X kernels. 
-
-beta1-2.2.0     Dec 30 2000
-                                o Updated drivers for 2.4.X kernels.
-                                o Updated drivers for SMP support.
-                                o X25API is now able to share PCI interrupts.
-                                o Took out a general polling routine that was used
-                                  only by X25API. 
-                                o Added appropriate locks to the dynamic reconfiguration
-                                  code.
-                                o Fixed a bug in the keyboard debug monitor.
-
-beta2-2.2.0     Jan 8 2001
-                                o Patches for 2.4.0 kernel
-                                o Patches for 2.2.18 kernel
-                                o Minor updates to PPP and CHLDC drivers.
-                                  Note: No functional difference.
-
-beta3-2.2.9     Jan 10 2001
-                                o I missed the 2.2.18 kernel patches in beta2-2.2.0
-                                  release.  They are included in this release.
-
-Stable Release
-2.2.0           Feb 01 2001
-                                o Bug fix in wancfg GUI configurator.
-                                        The edit function didn't work properly.
-
-
-bata1-2.2.1     Feb 09 2001
-                        o WANPIPE TTY Driver emulation. 
-                          Two modes of operation Sync and Async.
-                                Sync: Using the PPPD daemon, kernel SyncPPP layer
-                                      and the Wanpipe sync TTY driver: a PPP protocol 
-                                      connection can be established via Sangoma adapter, over
-                                      a T1 leased line.
-                        
-                                      The 2.4.0 kernel PPP layer supports MULTILINK
-                                      protocol, that can be used to bundle any number of Sangoma
-                                      adapters (T1 lines) into one, under a single IP address.
-                                      Thus, efficiently obtaining multiple T1 throughput. 
-
-                                      NOTE: The remote side must also implement MULTILINK PPP
-                                            protocol.
-
-                                Async:Using the PPPD daemon, kernel AsyncPPP layer
-                                      and the WANPIPE async TTY driver: a PPP protocol
-                                      connection can be established via Sangoma adapter and
-                                      a modem, over a telephone line.
-
-                                      Thus, the WANPIPE async TTY driver simulates a serial
-                                      TTY driver that would normally be used to interface the 
-                                      MODEM to the linux kernel.
-                                
-                        o WANPIPE PPP Backup Utility
-                                This utility will monitor the state of the PPP T1 line.
-                                In case of failure, a dial up connection will be established
-                                via pppd daemon, ether via a serial tty driver (serial port), 
-                                or a WANPIPE async TTY driver (in case serial port is unavailable).
-                                
-                                Furthermore, while in dial up mode, the primary PPP T1 link
-                                will be monitored for signs of life.  
-
-                                If the PPP T1 link comes back to life, the dial up connection
-                                will be shutdown and T1 line re-established.
-                        
-
-                        o New Setup installation script.
-                                Option to UPGRADE device drivers if the kernel source has
-                                already been patched with WANPIPE.
-
-                                Option to COMPILE WANPIPE modules against the currently 
-                                running kernel, thus no need for manual kernel and module
-                                re-compilation.
-                        
-                        o Updates and Bug Fixes to wancfg utility.
-
-bata2-2.2.1     Feb 20 2001
-
-                        o Bug fixes to the CHDLC device drivers.
-                                The driver had compilation problems under kernels
-                                2.2.14 or lower.
-
-                        o Bug fixes to the Setup installation script.
-                                The device drivers compilation options didn't work
-                                properly.
-
-                        o Update to the wpbackupd daemon.  
-                                Optimized the cross-over times, between the primary
-                                link and the backup dialup.
-
-beta3-2.2.1     Mar 02 2001
-                        o Patches for 2.4.2 kernel.
-
-                        o Bug fixes to util/ make files.
-                        o Bug fixes to the Setup installation script.
-
-                        o Took out the backupd support and made it into
-                          as separate package.
-                          
-beta4-2.2.1     Mar 12 2001
-
-                o Fix to the Frame Relay Device driver.
-                        IPSAC sends a packet of zero length
-                        header to the frame relay driver.  The
-                        driver tries to push its own 2 byte header
-                        into the packet, which causes the driver to
-                        crash.
-
-                o Fix the WANPIPE re-configuration code.
-                        Bug was found by trying to run  the cfgft1 while the
-                        interface was already running.  
-
-                o Updates to cfgft1.
-                        Writes a wanpipe#.cfgft1 configuration file
-                        once the CSU/DSU is configured. This file can
-                        holds the current CSU/DSU configuration.
-
-
-
->>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-
-
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt
index c025a4561c10..757c729ee42e 100644
--- a/Documentation/nmi_watchdog.txt
+++ b/Documentation/nmi_watchdog.txt
@@ -23,8 +23,7 @@ kernel debugging options, such as Kernel Stack Meter or Kernel Tracer,
 may implicitly disable the NMI watchdog.]
 
 For x86-64, the needed APIC is always compiled in, and the NMI watchdog is
-always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC
-mode (nmi_watchdog=2) does not work on x86-64.
+always enabled with I/O-APIC mode (nmi_watchdog=1).
 
 Using local APIC (nmi_watchdog=2) needs the first performance register, so
 you can't use it for other purposes (such as high precision performance
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 7f60dfe642ca..b152e81da592 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -253,6 +253,10 @@ characters, each representing a particular tainted value.
 
   8: 'D' if the kernel has died recently, i.e. there was an OOPS or BUG.
 
+  9: 'A' if the ACPI table has been overridden.
+
+ 10: 'W' if a warning has previously been issued by the kernel.
+
 The primary reason for the 'Tainted: ' string is to tell kernel
 debuggers if this is a clean kernel or if anything unusual has
 occurred.  Tainting is permanent: even if an offending module is
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 461e4f1dbec4..421e7d00ffd0 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -196,6 +196,11 @@ its parent; and can't be removed or suspended after that parent.
 
 The policy is that the device tree should match hardware bus topology.
 (Or at least the control bus, for devices which use multiple busses.)
+In particular, this means that a device registration may fail if the parent of
+the device is suspending (ie. has been chosen by the PM core as the next
+device to suspend) or has already suspended, as well as after all of the other
+devices have been suspended.  Device drivers must be prepared to cope with such
+situations.
 
 
 Suspending Devices
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 7b4e8a70882c..1d2a772506cf 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -59,12 +59,39 @@ Table of Contents
       p) Freescale Synchronous Serial Interface
           q) USB EHCI controllers
 
-  VII - Specifying interrupt information for devices
+  VII - Marvell Discovery mv64[345]6x System Controller chips
+    1) The /system-controller node
+    2) Child nodes of /system-controller
+      a) Marvell Discovery MDIO bus
+      b) Marvell Discovery ethernet controller
+      c) Marvell Discovery PHY nodes
+      d) Marvell Discovery SDMA nodes
+      e) Marvell Discovery BRG nodes
+      f) Marvell Discovery CUNIT nodes
+      g) Marvell Discovery MPSCROUTING nodes
+      h) Marvell Discovery MPSCINTR nodes
+      i) Marvell Discovery MPSC nodes
+      j) Marvell Discovery Watch Dog Timer nodes
+      k) Marvell Discovery I2C nodes
+      l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
+      m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
+      n) Marvell Discovery GPP (General Purpose Pins) nodes
+      o) Marvell Discovery PCI host bridge node
+      p) Marvell Discovery CPU Error nodes
+      q) Marvell Discovery SRAM Controller nodes
+      r) Marvell Discovery PCI Error Handler nodes
+      s) Marvell Discovery Memory Controller nodes
+
+  VIII - Specifying interrupt information for devices
     1) interrupts property
     2) interrupt-parent property
     3) OpenPIC Interrupt Controllers
     4) ISA Interrupt Controllers
 
+  VIII - Specifying GPIO information for devices
+    1) gpios property
+    2) gpio-controller nodes
+
   Appendix A - Sample SOC node for MPC8540
 
 
@@ -1269,10 +1296,6 @@ platforms are moved over to use the flattened-device-tree model.
 
   Recommended properties:
 
-    - linux,network-index : This is the intended "index" of this
-      network device.  This is used by the bootwrapper to interpret
-      MAC addresses passed by the firmware when no information other
-      than indices is available to associate an address with a device.
     - phy-connection-type : a string naming the controller/PHY interface type,
       i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
       "tbi", or "rtbi".  This property is only really needed if the connection
@@ -1622,8 +1645,7 @@ platforms are moved over to use the flattened-device-tree model.
    - device_type : should be "network", "hldc", "uart", "transparent"
      "bisync", "atm", or "serial".
    - compatible : could be "ucc_geth" or "fsl_atm" and so on.
-   - model : should be "UCC".
-   - device-id : the ucc number(1-8), corresponding to UCCx in UM.
+   - cell-index : the ucc number(1-8), corresponding to UCCx in UM.
    - reg : Offset and length of the register set for the device
    - interrupts : <a b> where a is the interrupt number and b is a
      field that represents an encoding of the sense and level
@@ -1667,10 +1689,6 @@ platforms are moved over to use the flattened-device-tree model.
    - phy-handle : The phandle for the PHY connected to this controller.
 
    Recommended properties:
-   - linux,network-index : This is the intended "index" of this
-     network device.  This is used by the bootwrapper to interpret
-     MAC addresses passed by the firmware when no information other
-     than indices is available to associate an address with a device.
    - phy-connection-type : a string naming the controller/PHY interface type,
      i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
      Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
@@ -1680,8 +1698,7 @@ platforms are moved over to use the flattened-device-tree model.
         ucc@2000 {
                 device_type = "network";
                 compatible = "ucc_geth";
-                model = "UCC";
-                device-id = <1>;
+                cell-index = <1>;
                 reg = <2000 200>;
                 interrupts = <a0 0>;
                 interrupt-parent = <700>;
@@ -1995,7 +2012,6 @@ platforms are moved over to use the flattened-device-tree model.
                 interrupts = <20 8>;
                 interrupt-parent = <&PIC>;
                 phy-handle = <&PHY0>;
-                linux,network-index = <0>;
                 fsl,cpm-command = <12000300>;
         };
 
@@ -2217,12 +2233,6 @@ platforms are moved over to use the flattened-device-tree model.
                           EMAC, that is the content of the current (bogus) "phy-port"
                           property.
 
-    Recommended properties:
-    - linux,network-index : This is the intended "index" of this
-      network device.  This is used by the bootwrapper to interpret
-      MAC addresses passed by the firmware when no information other
-      than indices is available to associate an address with a device.
-
     Optional properties:
     - phy-address       : 1 cell, optional, MDIO address of the PHY. If absent,
                           a search is performed.
@@ -2246,7 +2256,6 @@ platforms are moved over to use the flattened-device-tree model.
     Example:
 
         EMAC0: ethernet@40000800 {
-                linux,network-index = <0>;
                 device_type = "network";
                 compatible = "ibm,emac-440gp", "ibm,emac";
                 interrupt-parent = <&UIC1>;
@@ -2592,6 +2601,17 @@ platforms are moved over to use the flattened-device-tree model.
                       differ between different families.  May be
                       'virtex2p', 'virtex4', or 'virtex5'.
 
+      vi) Xilinx Uart 16550
+
+      Xilinx UART 16550 devices are very similar to the NS16550 but with
+      different register spacing and an offset from the base address.
+
+      Requred properties:
+       - clock-frequency : Frequency of the clock input
+       - reg-offset : A value of 3 is required
+       - reg-shift : A value of 2 is required
+
+
     p) Freescale Synchronous Serial Interface
 
        The SSI is a serial device that communicates with audio codecs.  It can
@@ -2816,10 +2836,562 @@ platforms are moved over to use the flattened-device-tree model.
                    big-endian;
            };
 
+    r) Freescale Display Interface Unit
+
+    The Freescale DIU is a LCD controller, with proper hardware, it can also
+    drive DVI monitors.
+
+    Required properties:
+    - compatible : should be "fsl-diu".
+    - reg : should contain at least address and length of the DIU register
+      set.
+    - Interrupts : one DIU interrupt should be describe here.
+
+    Example (MPC8610HPCD)
+        display@2c000 {
+                compatible = "fsl,diu";
+                reg = <0x2c000 100>;
+                interrupts = <72 2>;
+                interrupt-parent = <&mpic>;
+        };
+
+    s) Freescale on board FPGA
+
+    This is the memory-mapped registers for on board FPGA.
+
+    Required properities:
+    - compatible : should be "fsl,fpga-pixis".
+    - reg : should contain the address and the lenght of the FPPGA register
+      set.
+
+    Example (MPC8610HPCD)
+        board-control@e8000000 {
+                compatible = "fsl,fpga-pixis";
+                reg = <0xe8000000 32>;
+        };
+
+VII - Marvell Discovery mv64[345]6x System Controller chips
+===========================================================
+
+The Marvell mv64[345]60 series of system controller chips contain
+many of the peripherals needed to implement a complete computer
+system.  In this section, we define device tree nodes to describe
+the system controller chip itself and each of the peripherals
+which it contains.  Compatible string values for each node are
+prefixed with the string "marvell,", for Marvell Technology Group Ltd.
+
+1) The /system-controller node
+
+  This node is used to represent the system-controller and must be
+  present when the system uses a system contller chip. The top-level
+  system-controller node contains information that is global to all
+  devices within the system controller chip. The node name begins
+  with "system-controller" followed by the unit address, which is
+  the base address of the memory-mapped register set for the system
+  controller chip.
+
+  Required properties:
+
+    - ranges : Describes the translation of system controller addresses
+      for memory mapped registers.
+    - clock-frequency: Contains the main clock frequency for the system
+      controller chip.
+    - reg : This property defines the address and size of the
+      memory-mapped registers contained within the system controller
+      chip.  The address specified in the "reg" property should match
+      the unit address of the system-controller node.
+    - #address-cells : Address representation for system controller
+      devices.  This field represents the number of cells needed to
+      represent the address of the memory-mapped registers of devices
+      within the system controller chip.
+    - #size-cells : Size representation for for the memory-mapped
+      registers within the system controller chip.
+    - #interrupt-cells : Defines the width of cells used to represent
+      interrupts.
+
+  Optional properties:
+
+    - model : The specific model of the system controller chip.  Such
+      as, "mv64360", "mv64460", or "mv64560".
+    - compatible : A string identifying the compatibility identifiers
+      of the system controller chip.
+
+  The system-controller node contains child nodes for each system
+  controller device that the platform uses.  Nodes should not be created
+  for devices which exist on the system controller chip but are not used
+
+  Example Marvell Discovery mv64360 system-controller node:
+
+    system-controller@f1000000 { /* Marvell Discovery mv64360 */
+            #address-cells = <1>;
+            #size-cells = <1>;
+            model = "mv64360";                      /* Default */
+            compatible = "marvell,mv64360";
+            clock-frequency = <133333333>;
+            reg = <0xf1000000 0x10000>;
+            virtual-reg = <0xf1000000>;
+            ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
+                    0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
+                    0xa0000000 0xa0000000 0x4000000 /* User FLASH */
+                    0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
+                    0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
+
+            [ child node definitions... ]
+    }
+
+2) Child nodes of /system-controller
+
+   a) Marvell Discovery MDIO bus
+
+   The MDIO is a bus to which the PHY devices are connected.  For each
+   device that exists on this bus, a child node should be created.  See
+   the definition of the PHY node below for an example of how to define
+   a PHY.
+
+   Required properties:
+     - #address-cells : Should be <1>
+     - #size-cells : Should be <0>
+     - device_type : Should be "mdio"
+     - compatible : Should be "marvell,mv64360-mdio"
+
+   Example:
+
+     mdio {
+             #address-cells = <1>;
+             #size-cells = <0>;
+             device_type = "mdio";
+             compatible = "marvell,mv64360-mdio";
+
+             ethernet-phy@0 {
+                     ......
+             };
+     };
+
+
+   b) Marvell Discovery ethernet controller
+
+   The Discover ethernet controller is described with two levels
+   of nodes.  The first level describes an ethernet silicon block
+   and the second level describes up to 3 ethernet nodes within
+   that block.  The reason for the multiple levels is that the
+   registers for the node are interleaved within a single set
+   of registers.  The "ethernet-block" level describes the
+   shared register set, and the "ethernet" nodes describe ethernet
+   port-specific properties.
+
+   Ethernet block node
+
+   Required properties:
+     - #address-cells : <1>
+     - #size-cells : <0>
+     - compatible : "marvell,mv64360-eth-block"
+     - reg : Offset and length of the register set for this block
+
+   Example Discovery Ethernet block node:
+     ethernet-block@2000 {
+             #address-cells = <1>;
+             #size-cells = <0>;
+             compatible = "marvell,mv64360-eth-block";
+             reg = <0x2000 0x2000>;
+             ethernet@0 {
+                     .......
+             };
+     };
+
+   Ethernet port node
+
+   Required properties:
+     - device_type : Should be "network".
+     - compatible : Should be "marvell,mv64360-eth".
+     - reg : Should be <0>, <1>, or <2>, according to which registers
+       within the silicon block the device uses.
+     - interrupts : <a> where a is the interrupt number for the port.
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+     - phy : the phandle for the PHY connected to this ethernet
+       controller.
+     - local-mac-address : 6 bytes, MAC address
+
+   Example Discovery Ethernet port node:
+     ethernet@0 {
+             device_type = "network";
+             compatible = "marvell,mv64360-eth";
+             reg = <0>;
+             interrupts = <32>;
+             interrupt-parent = <&PIC>;
+             phy = <&PHY0>;
+             local-mac-address = [ 00 00 00 00 00 00 ];
+     };
+
+
+
+   c) Marvell Discovery PHY nodes
+
+   Required properties:
+     - device_type : Should be "ethernet-phy"
+     - interrupts : <a> where a is the interrupt number for this phy.
+     - interrupt-parent : the phandle for the interrupt controller that
+       services interrupts for this device.
+     - reg : The ID number for the phy, usually a small integer
 
-   More devices will be defined as this spec matures.
+   Example Discovery PHY node:
+     ethernet-phy@1 {
+             device_type = "ethernet-phy";
+             compatible = "broadcom,bcm5421";
+             interrupts = <76>;      /* GPP 12 */
+             interrupt-parent = <&PIC>;
+             reg = <1>;
+     };
 
-VII - Specifying interrupt information for devices
+
+   d) Marvell Discovery SDMA nodes
+
+   Represent DMA hardware associated with the MPSC (multiprotocol
+   serial controllers).
+
+   Required properties:
+     - compatible : "marvell,mv64360-sdma"
+     - reg : Offset and length of the register set for this device
+     - interrupts : <a> where a is the interrupt number for the DMA
+       device.
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery SDMA node:
+     sdma@4000 {
+             compatible = "marvell,mv64360-sdma";
+             reg = <0x4000 0xc18>;
+             virtual-reg = <0xf1004000>;
+             interrupts = <36>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   e) Marvell Discovery BRG nodes
+
+   Represent baud rate generator hardware associated with the MPSC
+   (multiprotocol serial controllers).
+
+   Required properties:
+     - compatible : "marvell,mv64360-brg"
+     - reg : Offset and length of the register set for this device
+     - clock-src : A value from 0 to 15 which selects the clock
+       source for the baud rate generator.  This value corresponds
+       to the CLKS value in the BRGx configuration register.  See
+       the mv64x60 User's Manual.
+     - clock-frequence : The frequency (in Hz) of the baud rate
+       generator's input clock.
+     - current-speed : The current speed setting (presumably by
+       firmware) of the baud rate generator.
+
+   Example Discovery BRG node:
+     brg@b200 {
+             compatible = "marvell,mv64360-brg";
+             reg = <0xb200 0x8>;
+             clock-src = <8>;
+             clock-frequency = <133333333>;
+             current-speed = <9600>;
+     };
+
+
+   f) Marvell Discovery CUNIT nodes
+
+   Represent the Serial Communications Unit device hardware.
+
+   Required properties:
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery CUNIT node:
+     cunit@f200 {
+             reg = <0xf200 0x200>;
+     };
+
+
+   g) Marvell Discovery MPSCROUTING nodes
+
+   Represent the Discovery's MPSC routing hardware
+
+   Required properties:
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery CUNIT node:
+     mpscrouting@b500 {
+             reg = <0xb400 0xc>;
+     };
+
+
+   h) Marvell Discovery MPSCINTR nodes
+
+   Represent the Discovery's MPSC DMA interrupt hardware registers
+   (SDMA cause and mask registers).
+
+   Required properties:
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery MPSCINTR node:
+     mpsintr@b800 {
+             reg = <0xb800 0x100>;
+     };
+
+
+   i) Marvell Discovery MPSC nodes
+
+   Represent the Discovery's MPSC (Multiprotocol Serial Controller)
+   serial port.
+
+   Required properties:
+     - device_type : "serial"
+     - compatible : "marvell,mv64360-mpsc"
+     - reg : Offset and length of the register set for this device
+     - sdma : the phandle for the SDMA node used by this port
+     - brg : the phandle for the BRG node used by this port
+     - cunit : the phandle for the CUNIT node used by this port
+     - mpscrouting : the phandle for the MPSCROUTING node used by this port
+     - mpscintr : the phandle for the MPSCINTR node used by this port
+     - cell-index : the hardware index of this cell in the MPSC core
+     - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
+       register
+     - interrupts : <a> where a is the interrupt number for the MPSC.
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery MPSCINTR node:
+     mpsc@8000 {
+             device_type = "serial";
+             compatible = "marvell,mv64360-mpsc";
+             reg = <0x8000 0x38>;
+             virtual-reg = <0xf1008000>;
+             sdma = <&SDMA0>;
+             brg = <&BRG0>;
+             cunit = <&CUNIT>;
+             mpscrouting = <&MPSCROUTING>;
+             mpscintr = <&MPSCINTR>;
+             cell-index = <0>;
+             max_idle = <40>;
+             interrupts = <40>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   j) Marvell Discovery Watch Dog Timer nodes
+
+   Represent the Discovery's watchdog timer hardware
+
+   Required properties:
+     - compatible : "marvell,mv64360-wdt"
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery Watch Dog Timer node:
+     wdt@b410 {
+             compatible = "marvell,mv64360-wdt";
+             reg = <0xb410 0x8>;
+     };
+
+
+   k) Marvell Discovery I2C nodes
+
+   Represent the Discovery's I2C hardware
+
+   Required properties:
+     - device_type : "i2c"
+     - compatible : "marvell,mv64360-i2c"
+     - reg : Offset and length of the register set for this device
+     - interrupts : <a> where a is the interrupt number for the I2C.
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery I2C node:
+             compatible = "marvell,mv64360-i2c";
+             reg = <0xc000 0x20>;
+             virtual-reg = <0xf100c000>;
+             interrupts = <37>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
+
+   Represent the Discovery's PIC hardware
+
+   Required properties:
+     - #interrupt-cells : <1>
+     - #address-cells : <0>
+     - compatible : "marvell,mv64360-pic"
+     - reg : Offset and length of the register set for this device
+     - interrupt-controller
+
+   Example Discovery PIC node:
+     pic {
+             #interrupt-cells = <1>;
+             #address-cells = <0>;
+             compatible = "marvell,mv64360-pic";
+             reg = <0x0 0x88>;
+             interrupt-controller;
+     };
+
+
+   m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
+
+   Represent the Discovery's MPP hardware
+
+   Required properties:
+     - compatible : "marvell,mv64360-mpp"
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery MPP node:
+     mpp@f000 {
+             compatible = "marvell,mv64360-mpp";
+             reg = <0xf000 0x10>;
+     };
+
+
+   n) Marvell Discovery GPP (General Purpose Pins) nodes
+
+   Represent the Discovery's GPP hardware
+
+   Required properties:
+     - compatible : "marvell,mv64360-gpp"
+     - reg : Offset and length of the register set for this device
+
+   Example Discovery GPP node:
+     gpp@f000 {
+             compatible = "marvell,mv64360-gpp";
+             reg = <0xf100 0x20>;
+     };
+
+
+   o) Marvell Discovery PCI host bridge node
+
+   Represents the Discovery's PCI host bridge device.  The properties
+   for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
+   1275-1994.  A typical value for the compatible property is
+   "marvell,mv64360-pci".
+
+   Example Discovery PCI host bridge node
+     pci@80000000 {
+             #address-cells = <3>;
+             #size-cells = <2>;
+             #interrupt-cells = <1>;
+             device_type = "pci";
+             compatible = "marvell,mv64360-pci";
+             reg = <0xcf8 0x8>;
+             ranges = <0x01000000 0x0        0x0
+                             0x88000000 0x0 0x01000000
+                       0x02000000 0x0 0x80000000
+                             0x80000000 0x0 0x08000000>;
+             bus-range = <0 255>;
+             clock-frequency = <66000000>;
+             interrupt-parent = <&PIC>;
+             interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+             interrupt-map = <
+                     /* IDSEL 0x0a */
+                     0x5000 0 0 1 &PIC 80
+                     0x5000 0 0 2 &PIC 81
+                     0x5000 0 0 3 &PIC 91
+                     0x5000 0 0 4 &PIC 93
+
+                     /* IDSEL 0x0b */
+                     0x5800 0 0 1 &PIC 91
+                     0x5800 0 0 2 &PIC 93
+                     0x5800 0 0 3 &PIC 80
+                     0x5800 0 0 4 &PIC 81
+
+                     /* IDSEL 0x0c */
+                     0x6000 0 0 1 &PIC 91
+                     0x6000 0 0 2 &PIC 93
+                     0x6000 0 0 3 &PIC 80
+                     0x6000 0 0 4 &PIC 81
+
+                     /* IDSEL 0x0d */
+                     0x6800 0 0 1 &PIC 93
+                     0x6800 0 0 2 &PIC 80
+                     0x6800 0 0 3 &PIC 81
+                     0x6800 0 0 4 &PIC 91
+             >;
+     };
+
+
+   p) Marvell Discovery CPU Error nodes
+
+   Represent the Discovery's CPU error handler device.
+
+   Required properties:
+     - compatible : "marvell,mv64360-cpu-error"
+     - reg : Offset and length of the register set for this device
+     - interrupts : the interrupt number for this device
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery CPU Error node:
+     cpu-error@0070 {
+             compatible = "marvell,mv64360-cpu-error";
+             reg = <0x70 0x10 0x128 0x28>;
+             interrupts = <3>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   q) Marvell Discovery SRAM Controller nodes
+
+   Represent the Discovery's SRAM controller device.
+
+   Required properties:
+     - compatible : "marvell,mv64360-sram-ctrl"
+     - reg : Offset and length of the register set for this device
+     - interrupts : the interrupt number for this device
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery SRAM Controller node:
+     sram-ctrl@0380 {
+             compatible = "marvell,mv64360-sram-ctrl";
+             reg = <0x380 0x80>;
+             interrupts = <13>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   r) Marvell Discovery PCI Error Handler nodes
+
+   Represent the Discovery's PCI error handler device.
+
+   Required properties:
+     - compatible : "marvell,mv64360-pci-error"
+     - reg : Offset and length of the register set for this device
+     - interrupts : the interrupt number for this device
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery PCI Error Handler node:
+     pci-error@1d40 {
+             compatible = "marvell,mv64360-pci-error";
+             reg = <0x1d40 0x40 0xc28 0x4>;
+             interrupts = <12>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+   s) Marvell Discovery Memory Controller nodes
+
+   Represent the Discovery's memory controller device.
+
+   Required properties:
+     - compatible : "marvell,mv64360-mem-ctrl"
+     - reg : Offset and length of the register set for this device
+     - interrupts : the interrupt number for this device
+     - interrupt-parent : the phandle for the interrupt controller
+       that services interrupts for this device.
+
+   Example Discovery Memory Controller node:
+     mem-ctrl@1400 {
+             compatible = "marvell,mv64360-mem-ctrl";
+             reg = <0x1400 0x60>;
+             interrupts = <17>;
+             interrupt-parent = <&PIC>;
+     };
+
+
+VIII - Specifying interrupt information for devices
 ===================================================
 
 The device tree represents the busses and devices of a hardware
@@ -2905,6 +3477,54 @@ encodings listed below:
         2 =  high to low edge sensitive type enabled
         3 =  low to high edge sensitive type enabled
 
+VIII - Specifying GPIO information for devices
+==============================================
+
+1) gpios property
+-----------------
+
+Nodes that makes use of GPIOs should define them using `gpios' property,
+format of which is: <&gpio-controller1-phandle gpio1-specifier
+                     &gpio-controller2-phandle gpio2-specifier
+                     0 /* holes are permitted, means no GPIO 3 */
+                     &gpio-controller4-phandle gpio4-specifier
+                     ...>;
+
+Note that gpio-specifier length is controller dependent.
+
+gpio-specifier may encode: bank, pin position inside the bank,
+whether pin is open-drain and whether pin is logically inverted.
+
+Example of the node using GPIOs:
+
+        node {
+                gpios = <&qe_pio_e 18 0>;
+        };
+
+In this example gpio-specifier is "18 0" and encodes GPIO pin number,
+and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+
+2) gpio-controller nodes
+------------------------
+
+Every GPIO controller node must have #gpio-cells property defined,
+this information will be used to translate gpio-specifiers.
+
+Example of two SOC GPIO banks defined as gpio-controller nodes:
+
+        qe_pio_a: gpio-controller@1400 {
+                #gpio-cells = <2>;
+                compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
+                reg = <0x1400 0x18>;
+                gpio-controller;
+        };
+
+        qe_pio_e: gpio-controller@1460 {
+                #gpio-cells = <2>;
+                compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+                reg = <0x1460 0x18>;
+                gpio-controller;
+        };
 
 Appendix A - Sample SOC node for MPC8540
 ========================================
diff --git a/Documentation/powerpc/kvm_440.txt b/Documentation/powerpc/kvm_440.txt
new file mode 100644
index 000000000000..c02a003fa03a
--- /dev/null
+++ b/Documentation/powerpc/kvm_440.txt
@@ -0,0 +1,41 @@
+Hollis Blanchard <hollisb@us.ibm.com>
+15 Apr 2008
+
+Various notes on the implementation of KVM for PowerPC 440:
+
+To enforce isolation, host userspace, guest kernel, and guest userspace all
+run at user privilege level. Only the host kernel runs in supervisor mode.
+Executing privileged instructions in the guest traps into KVM (in the host
+kernel), where we decode and emulate them. Through this technique, unmodified
+440 Linux kernels can be run (slowly) as guests. Future performance work will
+focus on reducing the overhead and frequency of these traps.
+
+The usual code flow is started from userspace invoking an "run" ioctl, which
+causes KVM to switch into guest context. We use IVPR to hijack the host
+interrupt vectors while running the guest, which allows us to direct all
+interrupts to kvmppc_handle_interrupt(). At this point, we could either
+- handle the interrupt completely (e.g. emulate "mtspr SPRG0"), or
+- let the host interrupt handler run (e.g. when the decrementer fires), or
+- return to host userspace (e.g. when the guest performs device MMIO)
+
+Address spaces: We take advantage of the fact that Linux doesn't use the AS=1
+address space (in host or guest), which gives us virtual address space to use
+for guest mappings. While the guest is running, the host kernel remains mapped
+in AS=0, but the guest can only use AS=1 mappings.
+
+TLB entries: The TLB entries covering the host linear mapping remain
+present while running the guest. This reduces the overhead of lightweight
+exits, which are handled by KVM running in the host kernel. We keep three
+copies of the TLB:
+ - guest TLB: contents of the TLB as the guest sees it
+ - shadow TLB: the TLB that is actually in hardware while guest is running
+ - host TLB: to restore TLB state when context switching guest -> host
+When a TLB miss occurs because a mapping was not present in the shadow TLB,
+but was present in the guest TLB, KVM handles the fault without invoking the
+guest. Large guest pages are backed by multiple 4KB shadow pages through this
+mechanism.
+
+IO: MMIO and DCR accesses are emulated by userspace. We use virtio for network
+and block IO, so those drivers must be enabled in the guest. It's possible
+that some qemu device emulation (e.g. e1000 or rtl8139) may also work with
+little effort.
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index 5e03610e186f..6f12f1c79c0c 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -186,6 +186,12 @@ Recommended soc5200 child nodes; populate as needed for your board
 name            device_type     compatible        Description
 ----            -----------     ----------        -----------
 gpt@<addr>      gpt             fsl,mpc5200-gpt   General purpose timers
+gpt@<addr>      gpt             fsl,mpc5200-gpt-gpio    General purpose
+                                                        timers in GPIO mode
+gpio@<addr>                     fsl,mpc5200-gpio        MPC5200 simple gpio
+                                                        controller
+gpio@<addr>                     fsl,mpc5200-gpio-wkup   MPC5200 wakeup gpio
+                                                        controller
 rtc@<addr>      rtc             mpc5200-rtc       Real time clock
 mscan@<addr>    mscan           mpc5200-mscan     CAN bus controller
 pci@<addr>      pci             mpc5200-pci       PCI bridge
@@ -225,6 +231,23 @@ PSC in i2s mode:  The mpc5200 and mpc5200b PSCs are not compatible when in
 i2s mode.  An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
 compatible field.
 
+7) GPIO controller nodes
+Each GPIO controller node should have the empty property gpio-controller and
+#gpio-cells set to 2. First cell is the GPIO number which is interpreted
+according to the bit numbers in the GPIO control registers. The second cell
+is for flags which is currently unsused.
+
+8) FEC nodes
+The FEC node can specify one of the following properties to configure
+the MII link:
+"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire
+                    mode instead of MII
+"current-speed"   - Specifies that the MII should be configured for a fixed
+                    speed.  This property should contain two cells.  The
+                    first cell specifies the speed in Mbps and the second
+                    should be '0' for half duplex and '1' for full duplex
+"phy-handle"      - Contains a phandle to an Ethernet PHY.
+
 IV - Extra Notes
 ================
 
diff --git a/Documentation/powerpc/phyp-assisted-dump.txt b/Documentation/powerpc/phyp-assisted-dump.txt
new file mode 100644
index 000000000000..c4682b982a2e
--- /dev/null
+++ b/Documentation/powerpc/phyp-assisted-dump.txt
@@ -0,0 +1,127 @@
+
+                   Hypervisor-Assisted Dump
+                   ------------------------
+                       November 2007
+
+The goal of hypervisor-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+
+As compared to kdump or other strategies, hypervisor-assisted
+dump offers several strong, practical advantages:
+
+-- Unlike kdump, the system has been reset, and loaded
+   with a fresh copy of the kernel.  In particular,
+   PCI and I/O devices have been reinitialized and are
+   in a clean, consistent state.
+-- As the dump is performed, the dumped memory becomes
+   immediately available to the system for normal use.
+-- After the dump is completed, no further reboots are
+   required; the system will be fully usable, and running
+   in it's normal, production mode on it normal kernel.
+
+The above can only be accomplished by coordination with,
+and assistance from the hypervisor. The procedure is
+as follows:
+
+-- When a system crashes, the hypervisor will save
+   the low 256MB of RAM to a previously registered
+   save region. It will also save system state, system
+   registers, and hardware PTE's.
+
+-- After the low 256MB area has been saved, the
+   hypervisor will reset PCI and other hardware state.
+   It will *not* clear RAM. It will then launch the
+   bootloader, as normal.
+
+-- The freshly booted kernel will notice that there
+   is a new node (ibm,dump-kernel) in the device tree,
+   indicating that there is crash data available from
+   a previous boot. It will boot into only 256MB of RAM,
+   reserving the rest of system memory.
+
+-- Userspace tools will parse /sys/kernel/release_region
+   and read /proc/vmcore to obtain the contents of memory,
+   which holds the previous crashed kernel. The userspace
+   tools may copy this info to disk, or network, nas, san,
+   iscsi, etc. as desired.
+
+   For Example: the values in /sys/kernel/release-region
+   would look something like this (address-range pairs).
+   CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: /
+   DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A
+
+-- As the userspace tools complete saving a portion of
+   dump, they echo an offset and size to
+   /sys/kernel/release_region to release the reserved
+   memory back to general use.
+
+   An example of this is:
+     "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
+   which will release 256MB at the 1GB boundary.
+
+Please note that the hypervisor-assisted dump feature
+is only available on Power6-based systems with recent
+firmware versions.
+
+Implementation details:
+----------------------
+
+During boot, a check is made to see if firmware supports
+this feature on this particular machine. If it does, then
+we check to see if a active dump is waiting for us. If yes
+then everything but 256 MB of RAM is reserved during early
+boot. This area is released once we collect a dump from user
+land scripts that are run. If there is dump data, then
+the /sys/kernel/release_region file is created, and
+the reserved memory is held.
+
+If there is no waiting dump data, then only the highest
+256MB of the ram is reserved as a scratch area. This area
+is *not* released: this region will be kept permanently
+reserved, so that it can act as a receptacle for a copy
+of the low 256MB in the case a crash does occur. See,
+however, "open issues" below, as to whether
+such a reserved region is really needed.
+
+Currently the dump will be copied from /proc/vmcore to a
+a new file upon user intervention. The starting address
+to be read and the range for each data point in provided
+in /sys/kernel/release_region.
+
+The tools to examine the dump will be same as the ones
+used for kdump.
+
+General notes:
+--------------
+Security: please note that there are potential security issues
+with any sort of dump mechanism. In particular, plaintext
+(unencrypted) data, and possibly passwords, may be present in
+the dump data. Userspace tools must take adequate precautions to
+preserve security.
+
+Open issues/ToDo:
+------------
+ o The various code paths that tell the hypervisor that a crash
+   occurred, vs. it simply being a normal reboot, should be
+   reviewed, and possibly clarified/fixed.
+
+ o Instead of using /sys/kernel, should there be a /sys/dump
+   instead? There is a dump_subsys being created by the s390 code,
+   perhaps the pseries code should use a similar layout as well.
+
+ o Is reserving a 256MB region really required? The goal of
+   reserving a 256MB scratch area is to make sure that no
+   important crash data is clobbered when the hypervisor
+   save low mem to the scratch area. But, if one could assure
+   that nothing important is located in some 256MB area, then
+   it would not need to be reserved. Something that can be
+   improved in subsequent versions.
+
+ o Still working the kdump team to integrate this with kdump,
+   some work remains but this would not affect the current
+   patches.
+
+ o Still need to write a shell script, to copy the dump away.
+   Currently I am parsing it manually.
diff --git a/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
new file mode 100644
index 000000000000..f8e8e95e81fd
--- /dev/null
+++ b/Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c
@@ -0,0 +1,96 @@
+/*
+ * Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
+ *
+ * Tests if the control register is updated correctly
+ * at context switches
+ *
+ * Warning: this test will cause a very high load for a few seconds
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <wait.h>
+
+
+#include <sys/prctl.h>
+#include <linux/prctl.h>
+
+/* Get/set the process' ability to use the timestamp counter instruction */
+#ifndef PR_GET_TSC
+#define PR_GET_TSC 25
+#define PR_SET_TSC 26
+# define PR_TSC_ENABLE          1   /* allow the use of the timestamp counter */
+# define PR_TSC_SIGSEGV         2   /* throw a SIGSEGV instead of reading the TSC */
+#endif
+
+uint64_t rdtsc() {
+uint32_t lo, hi;
+/* We cannot use "=A", since this would use %rax on x86_64 */
+__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
+return (uint64_t)hi << 32 | lo;
+}
+
+void sigsegv_expect(int sig)
+{
+        /* */
+}
+
+void segvtask(void)
+{
+        if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0)
+        {
+                perror("prctl");
+                exit(0);
+        }
+        signal(SIGSEGV, sigsegv_expect);
+        alarm(10);
+        rdtsc();
+        fprintf(stderr, "FATAL ERROR, rdtsc() succeeded while disabled\n");
+        exit(0);
+}
+
+
+void sigsegv_fail(int sig)
+{
+        fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n");
+        exit(0);
+}
+
+void rdtsctask(void)
+{
+        if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0)
+        {
+                perror("prctl");
+                exit(0);
+        }
+        signal(SIGSEGV, sigsegv_fail);
+        alarm(10);
+        for(;;) rdtsc();
+}
+
+
+int main(int argc, char **argv)
+{
+        int n_tasks = 100, i;
+
+        fprintf(stderr, "[No further output means we're allright]\n");
+
+        for (i=0; i<n_tasks; i++)
+                if (fork() == 0)
+                {
+                        if (i & 1)
+                                segvtask();
+                        else
+                                rdtsctask();
+                }
+
+        for (i=0; i<n_tasks; i++)
+                wait(NULL);
+
+        exit(0);
+}
+
diff --git a/Documentation/prctl/disable-tsc-on-off-stress-test.c b/Documentation/prctl/disable-tsc-on-off-stress-test.c
new file mode 100644
index 000000000000..1fcd91445375
--- /dev/null
+++ b/Documentation/prctl/disable-tsc-on-off-stress-test.c
@@ -0,0 +1,95 @@
+/*
+ * Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
+ *
+ * Tests if the control register is updated correctly
+ * when set with prctl()
+ *
+ * Warning: this test will cause a very high load for a few seconds
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+#include <wait.h>
+
+
+#include <sys/prctl.h>
+#include <linux/prctl.h>
+
+/* Get/set the process' ability to use the timestamp counter instruction */
+#ifndef PR_GET_TSC
+#define PR_GET_TSC 25
+#define PR_SET_TSC 26
+# define PR_TSC_ENABLE          1   /* allow the use of the timestamp counter */
+# define PR_TSC_SIGSEGV         2   /* throw a SIGSEGV instead of reading the TSC */
+#endif
+
+/* snippet from wikipedia :-) */
+
+uint64_t rdtsc() {
+uint32_t lo, hi;
+/* We cannot use "=A", since this would use %rax on x86_64 */
+__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
+return (uint64_t)hi << 32 | lo;
+}
+
+int should_segv = 0;
+
+void sigsegv_cb(int sig)
+{
+        if (!should_segv)
+        {
+                fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n");
+                exit(0);
+        }
+        if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0)
+        {
+                perror("prctl");
+                exit(0);
+        }
+        should_segv = 0;
+
+        rdtsc();
+}
+
+void task(void)
+{
+        signal(SIGSEGV, sigsegv_cb);
+        alarm(10);
+        for(;;)
+        {
+                rdtsc();
+                if (should_segv)
+                {
+                        fprintf(stderr, "FATAL ERROR, rdtsc() succeeded while disabled\n");
+                        exit(0);
+                }
+                if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0)
+                {
+                        perror("prctl");
+                        exit(0);
+                }
+                should_segv = 1;
+        }
+}
+
+
+int main(int argc, char **argv)
+{
+        int n_tasks = 100, i;
+
+        fprintf(stderr, "[No further output means we're allright]\n");
+
+        for (i=0; i<n_tasks; i++)
+                if (fork() == 0)
+                        task();
+
+        for (i=0; i<n_tasks; i++)
+                wait(NULL);
+
+        exit(0);
+}
+
diff --git a/Documentation/prctl/disable-tsc-test.c b/Documentation/prctl/disable-tsc-test.c
new file mode 100644
index 000000000000..843c81eac235
--- /dev/null
+++ b/Documentation/prctl/disable-tsc-test.c
@@ -0,0 +1,94 @@
+/*
+ * Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
+ *
+ * Basic test to test behaviour of PR_GET_TSC and PR_SET_TSC
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <inttypes.h>
+
+
+#include <sys/prctl.h>
+#include <linux/prctl.h>
+
+/* Get/set the process' ability to use the timestamp counter instruction */
+#ifndef PR_GET_TSC
+#define PR_GET_TSC 25
+#define PR_SET_TSC 26
+# define PR_TSC_ENABLE          1   /* allow the use of the timestamp counter */
+# define PR_TSC_SIGSEGV         2   /* throw a SIGSEGV instead of reading the TSC */
+#endif
+
+const char *tsc_names[] =
+{
+        [0] = "[not set]",
+        [PR_TSC_ENABLE] = "PR_TSC_ENABLE",
+        [PR_TSC_SIGSEGV] = "PR_TSC_SIGSEGV",
+};
+
+uint64_t rdtsc() {
+uint32_t lo, hi;
+/* We cannot use "=A", since this would use %rax on x86_64 */
+__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
+return (uint64_t)hi << 32 | lo;
+}
+
+void sigsegv_cb(int sig)
+{
+        int tsc_val = 0;
+
+        printf("[ SIG_SEGV ]\n");
+        printf("prctl(PR_GET_TSC, &tsc_val); ");
+        fflush(stdout);
+
+        if ( prctl(PR_GET_TSC, &tsc_val) == -1)
+                perror("prctl");
+
+        printf("tsc_val == %s\n", tsc_names[tsc_val]);
+        printf("prctl(PR_SET_TSC, PR_TSC_ENABLE)\n");
+        fflush(stdout);
+        if ( prctl(PR_SET_TSC, PR_TSC_ENABLE) == -1)
+                perror("prctl");
+
+        printf("rdtsc() == ");
+}
+
+int main(int argc, char **argv)
+{
+        int tsc_val = 0;
+
+        signal(SIGSEGV, sigsegv_cb);
+
+        printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
+        printf("prctl(PR_GET_TSC, &tsc_val); ");
+        fflush(stdout);
+
+        if ( prctl(PR_GET_TSC, &tsc_val) == -1)
+                perror("prctl");
+
+        printf("tsc_val == %s\n", tsc_names[tsc_val]);
+        printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
+        printf("prctl(PR_SET_TSC, PR_TSC_ENABLE)\n");
+        fflush(stdout);
+
+        if ( prctl(PR_SET_TSC, PR_TSC_ENABLE) == -1)
+                perror("prctl");
+
+        printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
+        printf("prctl(PR_SET_TSC, PR_TSC_SIGSEGV)\n");
+        fflush(stdout);
+
+        if ( prctl(PR_SET_TSC, PR_TSC_SIGSEGV) == -1)
+                perror("prctl");
+
+        printf("rdtsc() == ");
+        fflush(stdout);
+        printf("%llu\n", (unsigned long long)rdtsc());
+        fflush(stdout);
+
+        exit(EXIT_SUCCESS);
+}
+
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index 8fbc0a852870..bf0baa19ec24 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -8,17 +8,6 @@ Command line parameters
 
   Enable logging of debug information in case of ccw device timeouts.
 
-
-* cio_msg = yes | no
-  
-  Determines whether information on found devices and sensed device 
-  characteristics should be shown during startup or when new devices are
-  found, i. e. messages of the types "Detected device 0.0.4711 on subchannel
-  0.0.0042" and "SenseID: Device 0.0.4711 reports: ...".
-
-  Default is off.
-
-
 * cio_ignore = {all} |
                {<device> | <range of devices>} |
                {!<device> | !<range of devices>}
diff --git a/Documentation/s390/kvm.txt b/Documentation/s390/kvm.txt
new file mode 100644
index 000000000000..6f5ceb0f09fc
--- /dev/null
+++ b/Documentation/s390/kvm.txt
@@ -0,0 +1,125 @@
+*** BIG FAT WARNING ***
+The kvm module is currently in EXPERIMENTAL state for s390. This means that
+the interface to the module is not yet considered to remain stable. Thus, be
+prepared that we keep breaking your userspace application and guest
+compatibility over and over again until we feel happy with the result. Make sure
+your guest kernel, your host kernel, and your userspace launcher are in a
+consistent state.
+
+This Documentation describes the unique ioctl calls to /dev/kvm, the resulting
+kvm-vm file descriptors, and the kvm-vcpu file descriptors that differ from x86.
+
+1. ioctl calls to /dev/kvm
+KVM does support the following ioctls on s390 that are common with other
+architectures and do behave the same:
+KVM_GET_API_VERSION
+KVM_CREATE_VM           (*) see note
+KVM_CHECK_EXTENSION
+KVM_GET_VCPU_MMAP_SIZE
+
+Notes:
+* KVM_CREATE_VM may fail on s390, if the calling process has multiple
+threads and has not called KVM_S390_ENABLE_SIE before.
+
+In addition, on s390 the following architecture specific ioctls are supported:
+ioctl:          KVM_S390_ENABLE_SIE
+args:           none
+see also:       include/linux/kvm.h
+This call causes the kernel to switch on PGSTE in the user page table. This
+operation is needed in order to run a virtual machine, and it requires the
+calling process to be single-threaded. Note that the first call to KVM_CREATE_VM
+will implicitly try to switch on PGSTE if the user process has not called
+KVM_S390_ENABLE_SIE before. User processes that want to launch multiple threads
+before creating a virtual machine have to call KVM_S390_ENABLE_SIE, or will
+observe an error calling KVM_CREATE_VM. Switching on PGSTE is a one-time
+operation, is not reversible, and will persist over the entire lifetime of
+the calling process. It does not have any user-visible effect other than a small
+performance penalty.
+
+2. ioctl calls to the kvm-vm file descriptor
+KVM does support the following ioctls on s390 that are common with other
+architectures and do behave the same:
+KVM_CREATE_VCPU
+KVM_SET_USER_MEMORY_REGION      (*) see note
+KVM_GET_DIRTY_LOG               (**) see note
+
+Notes:
+*  kvm does only allow exactly one memory slot on s390, which has to start
+   at guest absolute address zero and at a user address that is aligned on any
+   page boundary. This hardware "limitation" allows us to have a few unique
+   optimizations. The memory slot doesn't have to be filled
+   with memory actually, it may contain sparse holes. That said, with different
+   user memory layout this does still allow a large flexibility when
+   doing the guest memory setup.
+** KVM_GET_DIRTY_LOG doesn't work properly yet. The user will receive an empty
+log. This ioctl call is only needed for guest migration, and we intend to
+implement this one in the future.
+
+In addition, on s390 the following architecture specific ioctls for the kvm-vm
+file descriptor are supported:
+ioctl:          KVM_S390_INTERRUPT
+args:           struct kvm_s390_interrupt *
+see also:       include/linux/kvm.h
+This ioctl is used to submit a floating interrupt for a virtual machine.
+Floating interrupts may be delivered to any virtual cpu in the configuration.
+Only some interrupt types defined in include/linux/kvm.h make sense when
+submitted as floating interrupts. The following interrupts are not considered
+to be useful as floating interrupts, and a call to inject them will result in
+-EINVAL error code: program interrupts and interprocessor signals. Valid
+floating interrupts are:
+KVM_S390_INT_VIRTIO
+KVM_S390_INT_SERVICE
+
+3. ioctl calls to the kvm-vcpu file descriptor
+KVM does support the following ioctls on s390 that are common with other
+architectures and do behave the same:
+KVM_RUN
+KVM_GET_REGS
+KVM_SET_REGS
+KVM_GET_SREGS
+KVM_SET_SREGS
+KVM_GET_FPU
+KVM_SET_FPU
+
+In addition, on s390 the following architecture specific ioctls for the
+kvm-vcpu file descriptor are supported:
+ioctl:          KVM_S390_INTERRUPT
+args:           struct kvm_s390_interrupt *
+see also:       include/linux/kvm.h
+This ioctl is used to submit an interrupt for a specific virtual cpu.
+Only some interrupt types defined in include/linux/kvm.h make sense when
+submitted for a specific cpu. The following interrupts are not considered
+to be useful, and a call to inject them will result in -EINVAL error code:
+service processor calls and virtio interrupts. Valid interrupt types are:
+KVM_S390_PROGRAM_INT
+KVM_S390_SIGP_STOP
+KVM_S390_RESTART
+KVM_S390_SIGP_SET_PREFIX
+KVM_S390_INT_EMERGENCY
+
+ioctl:          KVM_S390_STORE_STATUS
+args:           unsigned long
+see also:       include/linux/kvm.h
+This ioctl stores the state of the cpu at the guest real address given as
+argument, unless one of the following values defined in include/linux/kvm.h
+is given as arguement:
+KVM_S390_STORE_STATUS_NOADDR - the CPU stores its status to the save area in
+absolute lowcore as defined by the principles of operation
+KVM_S390_STORE_STATUS_PREFIXED - the CPU stores its status to the save area in
+its prefix page just like the dump tool that comes with zipl. This is useful
+to create a system dump for use with lkcdutils or crash.
+
+ioctl:          KVM_S390_SET_INITIAL_PSW
+args:           struct kvm_s390_psw *
+see also:       include/linux/kvm.h
+This ioctl can be used to set the processor status word (psw) of a stopped cpu
+prior to running it with KVM_RUN. Note that this call is not required to modify
+the psw during sie intercepts that fall back to userspace because struct kvm_run
+does contain the psw, and this value is evaluated during reentry of KVM_RUN
+after the intercept exit was recognized.
+
+ioctl:          KVM_S390_INITIAL_RESET
+args:           none
+see also:       include/linux/kvm.h
+This ioctl can be used to perform an initial cpu reset as defined by the
+principles of operation. The target cpu has to be in stopped state.
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index 0eb7c58916de..e05420973698 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -115,6 +115,27 @@ Return Value: Handle for generated debug area
 Description:  Allocates memory for a debug log     
               Must not be called within an interrupt handler 
 
+----------------------------------------------------------------------------
+debug_info_t *debug_register_mode(char *name, int pages, int nr_areas,
+                                  int buf_size, mode_t mode, uid_t uid,
+                                  gid_t gid);
+
+Parameter:    name:        Name of debug log (e.g. used for debugfs entry)
+              pages:       Number of pages, which will be allocated per area
+              nr_areas:    Number of debug areas
+              buf_size:    Size of data area in each debug entry
+              mode:        File mode for debugfs files. E.g. S_IRWXUGO
+              uid:         User ID for debugfs files. Currently only 0 is
+                           supported.
+              gid:         Group ID for debugfs files. Currently only 0 is
+                           supported.
+
+Return Value: Handle for generated debug area
+              NULL if register failed
+
+Description:  Allocates memory for a debug log
+              Must not be called within an interrupt handler
+
 ---------------------------------------------------------------------------
 void debug_unregister (debug_info_t * id);
 
diff --git a/Documentation/sched-rt-group.txt b/Documentation/sched-rt-group.txt
deleted file mode 100644
index 1c6332f4543c..000000000000
--- a/Documentation/sched-rt-group.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-
-
-Real-Time group scheduling.
-
-The problem space:
-
-In order to schedule multiple groups of realtime tasks each group must
-be assigned a fixed portion of the CPU time available. Without a minimum
-guarantee a realtime group can obviously fall short. A fuzzy upper limit
-is of no use since it cannot be relied upon. Which leaves us with just
-the single fixed portion.
-
-CPU time is divided by means of specifying how much time can be spent
-running in a given period. Say a frame fixed realtime renderer must
-deliver 25 frames a second, which yields a period of 0.04s. Now say
-it will also have to play some music and respond to input, leaving it
-with around 80% for the graphics. We can then give this group a runtime
-of 0.8 * 0.04s = 0.032s.
-
-This way the graphics group will have a 0.04s period with a 0.032s runtime
-limit.
-
-Now if the audio thread needs to refill the DMA buffer every 0.005s, but
-needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s
-= 0.00015s.
-
-
-The Interface:
-
-system wide:
-
-/proc/sys/kernel/sched_rt_period_ms
-/proc/sys/kernel/sched_rt_runtime_us
-
-CONFIG_FAIR_USER_SCHED
-
-/sys/kernel/uids/<uid>/cpu_rt_runtime_us
-
-or
-
-CONFIG_FAIR_CGROUP_SCHED
-
-/cgroup/<cgroup>/cpu.rt_runtime_us
-
-[ time is specified in us because the interface is s32; this gives an
-  operating range of ~35m to 1us ]
-
-The period takes values in [ 1, INT_MAX ], runtime in [ -1, INT_MAX - 1 ].
-
-A runtime of -1 specifies runtime == period, ie. no limit.
-
-New groups get the period from /proc/sys/kernel/sched_rt_period_us and
-a runtime of 0.
-
-Settings are constrained to:
-
-   \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
-
-in order to keep the configuration schedulable.
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index b5f5ca069b2d..fc234d093fbf 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -12,5 +12,7 @@ sched-domains.txt
         - information on scheduling domains.
 sched-nice-design.txt
         - How and why the scheduler's nice levels are implemented.
+sched-rt-group.txt
+        - real-time group scheduling.
 sched-stats.txt
         - information on schedstats (Linux Scheduler Statistics).
diff --git a/Documentation/scheduler/sched-design.txt b/Documentation/scheduler/sched-design.txt
deleted file mode 100644
index 1605bf0cba8b..000000000000
--- a/Documentation/scheduler/sched-design.txt
+++ /dev/null
@@ -1,165 +0,0 @@
-                   Goals, Design and Implementation of the
-                      new ultra-scalable O(1) scheduler
-
-
-  This is an edited version of an email Ingo Molnar sent to
-  lkml on 4 Jan 2002.  It describes the goals, design, and
-  implementation of Ingo's new ultra-scalable O(1) scheduler.
-  Last Updated: 18 April 2002.
-
-
-Goal
-====
-
-The main goal of the new scheduler is to keep all the good things we know
-and love about the current Linux scheduler:
-
- - good interactive performance even during high load: if the user
-   types or clicks then the system must react instantly and must execute
-   the user tasks smoothly, even during considerable background load.
-
- - good scheduling/wakeup performance with 1-2 runnable processes.
-
- - fairness: no process should stay without any timeslice for any
-   unreasonable amount of time. No process should get an unjustly high
-   amount of CPU time.
-
- - priorities: less important tasks can be started with lower priority,
-   more important tasks with higher priority.
-
- - SMP efficiency: no CPU should stay idle if there is work to do.
-
- - SMP affinity: processes which run on one CPU should stay affine to
-   that CPU. Processes should not bounce between CPUs too frequently.
-
- - plus additional scheduler features: RT scheduling, CPU binding.
-
-and the goal is also to add a few new things:
-
- - fully O(1) scheduling. Are you tired of the recalculation loop
-   blowing the L1 cache away every now and then? Do you think the goodness
-   loop is taking a bit too long to finish if there are lots of runnable
-   processes? This new scheduler takes no prisoners: wakeup(), schedule(),
-   the timer interrupt are all O(1) algorithms. There is no recalculation
-   loop. There is no goodness loop either.
-
- - 'perfect' SMP scalability. With the new scheduler there is no 'big'
-   runqueue_lock anymore - it's all per-CPU runqueues and locks - two
-   tasks on two separate CPUs can wake up, schedule and context-switch
-   completely in parallel, without any interlocking. All
-   scheduling-relevant data is structured for maximum scalability.
-
- - better SMP affinity. The old scheduler has a particular weakness that
-   causes the random bouncing of tasks between CPUs if/when higher
-   priority/interactive tasks, this was observed and reported by many
-   people. The reason is that the timeslice recalculation loop first needs
-   every currently running task to consume its timeslice. But when this
-   happens on eg. an 8-way system, then this property starves an
-   increasing number of CPUs from executing any process. Once the last
-   task that has a timeslice left has finished using up that timeslice,
-   the recalculation loop is triggered and other CPUs can start executing
-   tasks again - after having idled around for a number of timer ticks.
-   The more CPUs, the worse this effect.
-
-   Furthermore, this same effect causes the bouncing effect as well:
-   whenever there is such a 'timeslice squeeze' of the global runqueue,
-   idle processors start executing tasks which are not affine to that CPU.
-   (because the affine tasks have finished off their timeslices already.)
-
-   The new scheduler solves this problem by distributing timeslices on a
-   per-CPU basis, without having any global synchronization or
-   recalculation.
-
- - batch scheduling. A significant proportion of computing-intensive tasks
-   benefit from batch-scheduling, where timeslices are long and processes
-   are roundrobin scheduled. The new scheduler does such batch-scheduling
-   of the lowest priority tasks - so nice +19 jobs will get
-   'batch-scheduled' automatically. With this scheduler, nice +19 jobs are
-   in essence SCHED_IDLE, from an interactiveness point of view.
-
- - handle extreme loads more smoothly, without breakdown and scheduling
-   storms.
-
- - O(1) RT scheduling. For those RT folks who are paranoid about the
-   O(nr_running) property of the goodness loop and the recalculation loop.
-
- - run fork()ed children before the parent. Andrea has pointed out the
-   advantages of this a few months ago, but patches for this feature
-   do not work with the old scheduler as well as they should,
-   because idle processes often steal the new child before the fork()ing
-   CPU gets to execute it.
-
-
-Design
-======
-
-The core of the new scheduler contains the following mechanisms:
-
- - *two* priority-ordered 'priority arrays' per CPU. There is an 'active'
-   array and an 'expired' array. The active array contains all tasks that
-   are affine to this CPU and have timeslices left. The expired array
-   contains all tasks which have used up their timeslices - but this array
-   is kept sorted as well. The active and expired array is not accessed
-   directly, it's accessed through two pointers in the per-CPU runqueue
-   structure. If all active tasks are used up then we 'switch' the two
-   pointers and from now on the ready-to-go (former-) expired array is the
-   active array - and the empty active array serves as the new collector
-   for expired tasks.
-
- - there is a 64-bit bitmap cache for array indices. Finding the highest
-   priority task is thus a matter of two x86 BSFL bit-search instructions.
-
-the split-array solution enables us to have an arbitrary number of active
-and expired tasks, and the recalculation of timeslices can be done
-immediately when the timeslice expires. Because the arrays are always
-access through the pointers in the runqueue, switching the two arrays can
-be done very quickly.
-
-this is a hybride priority-list approach coupled with roundrobin
-scheduling and the array-switch method of distributing timeslices.
-
- - there is a per-task 'load estimator'.
-
-one of the toughest things to get right is good interactive feel during
-heavy system load. While playing with various scheduler variants i found
-that the best interactive feel is achieved not by 'boosting' interactive
-tasks, but by 'punishing' tasks that want to use more CPU time than there
-is available. This method is also much easier to do in an O(1) fashion.
-
-to establish the actual 'load' the task contributes to the system, a
-complex-looking but pretty accurate method is used: there is a 4-entry
-'history' ringbuffer of the task's activities during the last 4 seconds.
-This ringbuffer is operated without much overhead. The entries tell the
-scheduler a pretty accurate load-history of the task: has it used up more
-CPU time or less during the past N seconds. [the size '4' and the interval
-of 4x 1 seconds was found by lots of experimentation - this part is
-flexible and can be changed in both directions.]
-
-the penalty a task gets for generating more load than the CPU can handle
-is a priority decrease - there is a maximum amount to this penalty
-relative to their static priority, so even fully CPU-bound tasks will
-observe each other's priorities, and will share the CPU accordingly.
-
-the SMP load-balancer can be extended/switched with additional parallel
-computing and cache hierarchy concepts: NUMA scheduling, multi-core CPUs
-can be supported easily by changing the load-balancer. Right now it's
-tuned for my SMP systems.
-
-i skipped the prev->mm == next->mm advantage - no workload i know of shows
-any sensitivity to this. It can be added back by sacrificing O(1)
-schedule() [the current and one-lower priority list can be searched for a
-that->mm == current->mm condition], but costs a fair number of cycles
-during a number of important workloads, so i wanted to avoid this as much
-as possible.
-
-- the SMP idle-task startup code was still racy and the new scheduler
-triggered this. So i streamlined the idle-setup code a bit. We do not call
-into schedule() before all processors have started up fully and all idle
-threads are in place.
-
-- the patch also cleans up a number of aspects of sched.c - moves code
-into other areas of the kernel where it's appropriate, and simplifies
-certain code paths and data constructs. As a result, the new scheduler's
-code is smaller than the old one.
-
-        Ingo
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
new file mode 100644
index 000000000000..14f901f639ee
--- /dev/null
+++ b/Documentation/scheduler/sched-rt-group.txt
@@ -0,0 +1,177 @@
+                                Real-Time group scheduling
+                                --------------------------
+
+CONTENTS
+========
+
+1. Overview
+  1.1 The problem
+  1.2 The solution
+2. The interface
+  2.1 System-wide settings
+  2.2 Default behaviour
+  2.3 Basis for grouping tasks
+3. Future plans
+
+
+1. Overview
+===========
+
+
+1.1 The problem
+---------------
+
+Realtime scheduling is all about determinism, a group has to be able to rely on
+the amount of bandwidth (eg. CPU time) being constant. In order to schedule
+multiple groups of realtime tasks, each group must be assigned a fixed portion
+of the CPU time available.  Without a minimum guarantee a realtime group can
+obviously fall short. A fuzzy upper limit is of no use since it cannot be
+relied upon. Which leaves us with just the single fixed portion.
+
+1.2 The solution
+----------------
+
+CPU time is divided by means of specifying how much time can be spent running
+in a given period. We allocate this "run time" for each realtime group which
+the other realtime groups will not be permitted to use.
+
+Any time not allocated to a realtime group will be used to run normal priority
+tasks (SCHED_OTHER). Any allocated run time not used will also be picked up by
+SCHED_OTHER.
+
+Let's consider an example: a frame fixed realtime renderer must deliver 25
+frames a second, which yields a period of 0.04s per frame. Now say it will also
+have to play some music and respond to input, leaving it with around 80% CPU
+time dedicated for the graphics. We can then give this group a run time of 0.8
+* 0.04s = 0.032s.
+
+This way the graphics group will have a 0.04s period with a 0.032s run time
+limit. Now if the audio thread needs to refill the DMA buffer every 0.005s, but
+needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s =
+0.00015s. So this group can be scheduled with a period of 0.005s and a run time
+of 0.00015s.
+
+The remaining CPU time will be used for user input and other tass. Because
+realtime tasks have explicitly allocated the CPU time they need to perform
+their tasks, buffer underruns in the graphocs or audio can be eliminated.
+
+NOTE: the above example is not fully implemented as of yet (2.6.25). We still
+lack an EDF scheduler to make non-uniform periods usable.
+
+
+2. The Interface
+================
+
+
+2.1 System wide settings
+------------------------
+
+The system wide settings are configured under the /proc virtual file system:
+
+/proc/sys/kernel/sched_rt_period_us:
+  The scheduling period that is equivalent to 100% CPU bandwidth
+
+/proc/sys/kernel/sched_rt_runtime_us:
+  A global limit on how much time realtime scheduling may use.  Even without
+  CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to realtime
+  processes. With CONFIG_RT_GROUP_SCHED it signifies the total bandwidth
+  available to all realtime groups.
+
+  * Time is specified in us because the interface is s32. This gives an
+    operating range from 1us to about 35 minutes.
+  * sched_rt_period_us takes values from 1 to INT_MAX.
+  * sched_rt_runtime_us takes values from -1 to (INT_MAX - 1).
+  * A run time of -1 specifies runtime == period, ie. no limit.
+
+
+2.2 Default behaviour
+---------------------
+
+The default values for sched_rt_period_us (1000000 or 1s) and
+sched_rt_runtime_us (950000 or 0.95s).  This gives 0.05s to be used by
+SCHED_OTHER (non-RT tasks). These defaults were chosen so that a run-away
+realtime tasks will not lock up the machine but leave a little time to recover
+it.  By setting runtime to -1 you'd get the old behaviour back.
+
+By default all bandwidth is assigned to the root group and new groups get the
+period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
+want to assign bandwidth to another group, reduce the root group's bandwidth
+and assign some or all of the difference to another group.
+
+Realtime group scheduling means you have to assign a portion of total CPU
+bandwidth to the group before it will accept realtime tasks. Therefore you will
+not be able to run realtime tasks as any user other than root until you have
+done that, even if the user has the rights to run processes with realtime
+priority!
+
+
+2.3 Basis for grouping tasks
+----------------------------
+
+There are two compile-time settings for allocating CPU bandwidth. These are
+configured using the "Basis for grouping tasks" multiple choice menu under
+General setup > Group CPU Scheduler:
+
+a. CONFIG_USER_SCHED (aka "Basis for grouping tasks" =  "user id")
+
+This lets you use the virtual files under
+"/sys/kernel/uids/<uid>/cpu_rt_runtime_us" to control he CPU time reserved for
+each user .
+
+The other option is:
+
+.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups")
+
+This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us"
+to control the CPU time reserved for each control group instead.
+
+For more information on working with control groups, you should read
+Documentation/cgroups.txt as well.
+
+Group settings are checked against the following limits in order to keep the configuration
+schedulable:
+
+   \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
+
+For now, this can be simplified to just the following (but see Future plans):
+
+   \Sum_{i} runtime_{i} <= global_runtime
+
+
+3. Future plans
+===============
+
+There is work in progress to make the scheduling period for each group
+("/sys/kernel/uids/<uid>/cpu_rt_period_us" or
+"/cgroup/<cgroup>/cpu.rt_period_us" respectively) configurable as well.
+
+The constraint on the period is that a subgroup must have a smaller or
+equal period to its parent. But realistically its not very useful _yet_
+as its prone to starvation without deadline scheduling.
+
+Consider two sibling groups A and B; both have 50% bandwidth, but A's
+period is twice the length of B's.
+
+* group A: period=100000us, runtime=10000us
+        - this runs for 0.01s once every 0.1s
+
+* group B: period= 50000us, runtime=10000us
+        - this runs for 0.01s twice every 0.1s (or once every 0.05 sec).
+
+This means that currently a while (1) loop in A will run for the full period of
+B and can starve B's tasks (assuming they are of lower priority) for a whole
+period.
+
+The next project will be SCHED_EDF (Earliest Deadline First scheduling) to bring
+full deadline scheduling to the linux kernel. Deadline scheduling the above
+groups and treating end of the period as a deadline will ensure that they both
+get their allocated time.
+
+Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
+the biggest challenge as the current linux PI infrastructure is geared towards
+the limited static priority levels 0-139. With deadline scheduling you need to
+do deadline inheritance (since priority is inversely proportional to the
+deadline delta (deadline - now).
+
+This means the whole PI machinery will have to be reworked - and that is one of
+the most complex pieces of code we have.
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index 91c81db0ba71..716fcc1cafb5 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,25 @@
+1 Release Date    : Mon. March 10 11:02:31 PDT 2008 -
+                        (emaild-id:megaraidlinux@lsi.com)
+                        Sumant Patro
+                        Bo Yang
+
+2 Current Version : 00.00.03.20-RC1
+3 Older Version   : 00.00.03.16
+
+1. Rollback the sense info implementation
+        Sense buffer ptr data type in the ioctl path is reverted back
+        to u32 * as in previous versions of driver.
+
+2. Fixed the driver frame count.
+        When Driver sent wrong frame count to firmware.  As this
+        particular command is sent to drive, FW is seeing continuous
+        chip resets and so the command will timeout.
+
+3. Add the new controller(1078DE) support to the driver
+        and Increase the max_wait to 60 from 10 in the controller
+        operational status.  With this max_wait increase, driver will
+        make sure the FW will   finish the pending cmd for KDUMP case.
+
 1 Release Date    : Thur. Nov. 07 16:30:43 PST 2007 -
                         (emaild-id:megaraidlinux@lsi.com)
                         Sumant Patro
diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt
index b7be95b5bd24..40752602c050 100644
--- a/Documentation/scsi/st.txt
+++ b/Documentation/scsi/st.txt
@@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver.
 The driver is currently maintained by Kai Mäkisara (email
 Kai.Makisara@kolumbus.fi)
 
-Last modified: Mon Mar  7 21:14:44 2005 by kai.makisara
+Last modified: Sun Feb 24 21:59:07 2008 by kai.makisara
 
 
 BASICS
@@ -133,6 +133,11 @@ the defaults set by the user. The value -1 means the default is not set. The
 file 'dev' contains the device numbers corresponding to this device. The links
 'device' and 'driver' point to the SCSI device and driver entries.
 
+Each directory also contains the entry 'options' which shows the currently
+enabled driver and mode options. The value in the file is a bit mask where the
+bit definitions are the same as those used with MTSETDRVBUFFER in setting the
+options.
+
 A link named 'tape' is made from the SCSI device directory to the class
 directory corresponding to the mode 0 auto-rewind device (e.g., st0). 
 
@@ -372,6 +377,11 @@ MTSETDRVBUFFER
              MT_ST_SYSV sets the SYSV semantics (mode)
              MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
                 the command to finish) for some commands (e.g., rewind)
+             MT_ST_SILI enables setting the SILI bit in SCSI commands when
+                reading in variable block mode to enhance performance when
+                reading blocks shorter than the byte count; set this only
+                if you are sure that the drive supports SILI and the HBA
+                correctly returns transfer residuals
              MT_ST_DEBUGGING debugging (global; debugging must be
                 compiled into the driver)
         MT_ST_SETBOOLEANS
diff --git a/Documentation/smart-config.txt b/Documentation/smart-config.txt
deleted file mode 100644
index 8467447b5a87..000000000000
--- a/Documentation/smart-config.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-Smart CONFIG_* Dependencies
-1 August 1999
-
-Michael Chastain   <mec@shout.net>
-Werner Almesberger <almesber@lrc.di.epfl.ch>
-Martin von Loewis  <martin@mira.isdn.cs.tu-berlin.de>
-
-Here is the problem:
-
-    Suppose that drivers/net/foo.c has the following lines:
-
-        #include <linux/config.h>
-
-        ...
-
-        #ifdef CONFIG_FOO_AUTOFROB
-            /* Code for auto-frobbing */
-        #else
-            /* Manual frobbing only */
-        #endif
-
-        ...
-
-        #ifdef CONFIG_FOO_MODEL_TWO
-            /* Code for model two */
-        #endif
-
-    Now suppose the user (the person building kernels) reconfigures the
-    kernel to change some unrelated setting.  This will regenerate the
-    file include/linux/autoconf.h, which will cause include/linux/config.h
-    to be out of date, which will cause drivers/net/foo.c to be recompiled.
-
-    Most kernel sources, perhaps 80% of them, have at least one CONFIG_*
-    dependency somewhere.  So changing _any_ CONFIG_* setting requires
-    almost _all_ of the kernel to be recompiled.
-
-Here is the solution:
-
-    We've made the dependency generator, mkdep.c, smarter.  Instead of
-    generating this dependency:
-
-        drivers/net/foo.c: include/linux/config.h
-
-    It now generates these dependencies:
-
-        drivers/net/foo.c: \
-            include/config/foo/autofrob.h \
-            include/config/foo/model/two.h
-
-    So drivers/net/foo.c depends only on the CONFIG_* lines that
-    it actually uses.
-
-    A new program, split-include.c, runs at the beginning of
-    compilation (make bzImage or make zImage).  split-include reads
-    include/linux/autoconf.h and updates the include/config/ tree,
-    writing one file per option.  It updates only the files for options
-    that have changed.
-
-Flag Dependencies
-
-    Martin Von Loewis contributed another feature to this patch:
-    'flag dependencies'.  The idea is that a .o file depends on
-    the compilation flags used to build it.  The file foo.o has
-    its flags stored in .flags.foo.o.
-
-    Suppose the user changes the foo driver from resident to modular.
-    'make' will notice that the current foo.o was not compiled with
-    -DMODULE and will recompile foo.c.
-
-    All .o files made from C source have flag dependencies.  So do .o
-    files made with ld, and .a files made with ar.  However, .o files
-    made from assembly source do not have flag dependencies (nobody
-    needs this yet, but it would be good to fix).
-
-Per-source-file Flags
-
-    Flag dependencies also work with per-source-file flags.
-    You can specify compilation flags for individual source files
-    like this:
-
-        CFLAGS_foo.o = -DSPECIAL_FOO_DEFINE
-
-    This helps clean up drivers/net/Makefile, drivers/scsi/Makefile,
-    and several other Makefiles.
-
-Credit
-
-    Werner Almesberger had the original idea and wrote the first
-    version of this patch.
-    
-    Michael Chastain picked it up and continued development.  He is
-    now the principal author and maintainer.  Please report any bugs
-    to him.
-
-    Martin von Loewis wrote flag dependencies, with some modifications
-    by Michael Chastain.
-
-    Thanks to all of the beta testers.
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index e985cf5e0410..0bbee38acd26 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -284,6 +284,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
            control correctly. If you have problems regarding this, try
            another ALSA compliant mixer (alsamixer works).
 
+  Module snd-aw2
+  --------------
+
+    Module for Audiowerk2 sound card
+
+    This module supports multiple cards.
+
   Module snd-azt2320
   ------------------
 
@@ -788,6 +795,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           lg-lw         LG LW20/LW25 laptop
           tcl           TCL S700
           clevo         Clevo laptops (m520G, m665n)
+          medion        Medion Rim 2150
           test          for testing/debugging purpose, almost all controls can be
                         adjusted.  Appearing only when compiled with
                         $CONFIG_SND_DEBUG=y
@@ -818,19 +826,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           hippo_1       Hippo (Benq) with jack detection
           sony-assamd   Sony ASSAMD
           ultra         Samsung Q1 Ultra Vista model
+          lenovo-3000   Lenovo 3000 y410
           basic         fixed pin assignment w/o SPDIF
           auto          auto-config reading BIOS (default)
 
-        ALC268
+        ALC267/268
+          quanta-il1    Quanta IL1 mini-notebook
           3stack        3-stack model
           toshiba       Toshiba A205
           acer          Acer laptops
           dell          Dell OEM laptops (Vostro 1200)
+          zepto         Zepto laptops
           test          for testing/debugging purpose, almost all controls can
                         adjusted.  Appearing only when compiled with
                         $CONFIG_SND_DEBUG=y
           auto          auto-config reading BIOS (default)
 
+        ALC269
+          basic         Basic preset
+
         ALC662
           3stack-dig    3-stack (2-channel) with SPDIF
           3stack-6ch     3-stack (6-channel)
@@ -871,10 +885,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           lenovo-nb0763 Lenovo NB0763
           lenovo-ms7195-dig Lenovo MS7195
           haier-w66     Haier W66
-          6stack-hp     HP machines with 6stack (Nettle boards)
           3stack-hp     HP machines with 3stack (Lucknow, Samba boards)
           6stack-dell   Dell machines with 6stack (Inspiron 530)
           mitac         Mitac 8252D
+          clevo-m720    Clevo M720 laptop series
+          fujitsu-pi2515 Fujitsu AMILO Pi2515
           auto          auto-config reading BIOS (default)
 
         ALC861/660
@@ -911,6 +926,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           3stack        3-stack mode (default)
           6stack        6-stack mode
 
+        AD1884A / AD1883 / AD1984A / AD1984B
+          desktop       3-stack desktop (default)
+          laptop        laptop with HP jack sensing
+          mobile        mobile devices with HP jack sensing
+          thinkpad      Lenovo Thinkpad X300
+
         AD1884
           N/A
 
@@ -936,7 +957,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100)
           ultra         2-channel with EAPD (Samsung Ultra tablet PC)
 
-        AD1988
+        AD1988/AD1988B/AD1989A/AD1989B
           6stack        6-jack
           6stack-dig    ditto with SPDIF
           3stack        3-jack
@@ -979,6 +1000,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           dell-m26      Dell Inspiron 1501
           dell-m27      Dell Inspiron E1705/9400
           gateway       Gateway laptops with EAPD control
+          panasonic     Panasonic CF-74
 
         STAC9205/9254
           ref           Reference board
@@ -1017,6 +1039,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
           3stack        D965 3stack
           5stack        D965 5stack + SPDIF
           dell-3stack   Dell Dimension E520
+          dell-bios     Fixes with Dell BIOS setup
+
+        STAC92HD71B*
+          ref           Reference board
+          dell-m4-1     Dell desktops
+          dell-m4-2     Dell desktops
+
+        STAC92HD73*
+          ref           Reference board
+          dell-m6       Dell desktops
 
         STAC9872
           vaio          Setup for VAIO FE550G/SZ110
@@ -1590,6 +1622,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     Power management is _not_ supported.
 
+  Module snd-pcsp
+  -----------------
+
+    Module for internal PC-Speaker.
+
+    nforce_wa   - enable NForce chipset workaround. Expect bad sound.
+
+    This module supports system beeps, some kind of PCM playback and
+    even a few mixer controls.
+
   Module snd-pcxhr
   ----------------
 
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 8861e47e5a2d..6d5f18143c50 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -116,6 +116,13 @@ low order bit.  So when a chip's timing diagram shows the clock
 starting low (CPOL=0) and data stabilized for sampling during the
 trailing clock edge (CPHA=1), that's SPI mode 1.
 
+Note that the clock mode is relevant as soon as the chipselect goes
+active.  So the master must set the clock to inactive before selecting
+a slave, and the slave can tell the chosen polarity by sampling the
+clock level when its select line goes active.  That's why many devices
+support for example both modes 0 and 3:  they don't care about polarity,
+and alway clock data in/out on rising clock edges.
+
 
 How do these driver programming interfaces work?
 ------------------------------------------------
@@ -379,8 +386,14 @@ any more such messages.
       + when bidirectional reads and writes start ... by how its
         sequence of spi_transfer requests is arranged;
 
+      + which I/O buffers are used ... each spi_transfer wraps a
+        buffer for each transfer direction, supporting full duplex
+        (two pointers, maybe the same one in both cases) and half
+        duplex (one pointer is NULL) transfers;
+
       + optionally defining short delays after transfers ... using
-        the spi_transfer.delay_usecs setting;
+        the spi_transfer.delay_usecs setting (this delay can be the
+        only protocol effect, if the buffer length is zero);
 
       + whether the chipselect becomes inactive after a transfer and
         any delay ... by using the spi_transfer.cs_change flag;
diff --git a/Documentation/spi/spidev b/Documentation/spi/spidev
index 5c8e1b988a08..ed2da5e5b28a 100644
--- a/Documentation/spi/spidev
+++ b/Documentation/spi/spidev
@@ -126,8 +126,8 @@ NOTES:
 FULL DUPLEX CHARACTER DEVICE API
 ================================
 
-See the sample program below for one example showing the use of the full
-duplex programming interface.  (Although it doesn't perform a full duplex
+See the spidev_fdx.c sample program for one example showing the use of the
+full duplex programming interface.  (Although it doesn't perform a full duplex
 transfer.)  The model is the same as that used in the kernel spi_sync()
 request; the individual transfers offer the same capabilities as are
 available to kernel drivers (except that it's not asynchronous).
@@ -141,167 +141,3 @@ and bitrate for each transfer segment.)
 
 To make a full duplex request, provide both rx_buf and tx_buf for the
 same transfer.  It's even OK if those are the same buffer.
-
-
-SAMPLE PROGRAM
-==============
-
---------------------------------        CUT HERE
-#include <stdio.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <fcntl.h>
-#include <string.h>
-
-#include <sys/ioctl.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-
-#include <linux/types.h>
-#include <linux/spi/spidev.h>
-
-
-static int verbose;
-
-static void do_read(int fd, int len)
-{
-        unsigned char   buf[32], *bp;
-        int             status;
-
-        /* read at least 2 bytes, no more than 32 */
-        if (len < 2)
-                len = 2;
-        else if (len > sizeof(buf))
-                len = sizeof(buf);
-        memset(buf, 0, sizeof buf);
-
-        status = read(fd, buf, len);
-        if (status < 0) {
-                perror("read");
-                return;
-        }
-        if (status != len) {
-                fprintf(stderr, "short read\n");
-                return;
-        }
-
-        printf("read(%2d, %2d): %02x %02x,", len, status,
-                buf[0], buf[1]);
-        status -= 2;
-        bp = buf + 2;
-        while (status-- > 0)
-                printf(" %02x", *bp++);
-        printf("\n");
-}
-
-static void do_msg(int fd, int len)
-{
-        struct spi_ioc_transfer xfer[2];
-        unsigned char           buf[32], *bp;
-        int                     status;
-
-        memset(xfer, 0, sizeof xfer);
-        memset(buf, 0, sizeof buf);
-
-        if (len > sizeof buf)
-                len = sizeof buf;
-
-        buf[0] = 0xaa;
-        xfer[0].tx_buf = (__u64) buf;
-        xfer[0].len = 1;
-
-        xfer[1].rx_buf = (__u64) buf;
-        xfer[1].len = len;
-
-        status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
-        if (status < 0) {
-                perror("SPI_IOC_MESSAGE");
-                return;
-        }
-
-        printf("response(%2d, %2d): ", len, status);
-        for (bp = buf; len; len--)
-                printf(" %02x", *bp++);
-        printf("\n");
-}
-
-static void dumpstat(const char *name, int fd)
-{
-        __u8    mode, lsb, bits;
-        __u32   speed;
-
-        if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
-                perror("SPI rd_mode");
-                return;
-        }
-        if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
-                perror("SPI rd_lsb_fist");
-                return;
-        }
-        if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
-                perror("SPI bits_per_word");
-                return;
-        }
-        if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
-                perror("SPI max_speed_hz");
-                return;
-        }
-
-        printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
-                name, mode, bits, lsb ? "(lsb first) " : "", speed);
-}
-
-int main(int argc, char **argv)
-{
-        int             c;
-        int             readcount = 0;
-        int             msglen = 0;
-        int             fd;
-        const char      *name;
-
-        while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
-                switch (c) {
-                case 'm':
-                        msglen = atoi(optarg);
-                        if (msglen < 0)
-                                goto usage;
-                        continue;
-                case 'r':
-                        readcount = atoi(optarg);
-                        if (readcount < 0)
-                                goto usage;
-                        continue;
-                case 'v':
-                        verbose++;
-                        continue;
-                case 'h':
-                case '?':
-usage:
-                        fprintf(stderr,
-                                "usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
-                                argv[0]);
-                        return 1;
-                }
-        }
-
-        if ((optind + 1) != argc)
-                goto usage;
-        name = argv[optind];
-
-        fd = open(name, O_RDWR);
-        if (fd < 0) {
-                perror("open");
-                return 1;
-        }
-
-        dumpstat(name, fd);
-
-        if (msglen)
-                do_msg(fd, msglen);
-
-        if (readcount)
-                do_read(fd, readcount);
-
-        close(fd);
-        return 0;
-}
diff --git a/Documentation/spi/spidev_fdx.c b/Documentation/spi/spidev_fdx.c
new file mode 100644
index 000000000000..fc354f760384
--- /dev/null
+++ b/Documentation/spi/spidev_fdx.c
@@ -0,0 +1,158 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <fcntl.h>
+#include <string.h>
+
+#include <sys/ioctl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+
+#include <linux/types.h>
+#include <linux/spi/spidev.h>
+
+
+static int verbose;
+
+static void do_read(int fd, int len)
+{
+        unsigned char   buf[32], *bp;
+        int             status;
+
+        /* read at least 2 bytes, no more than 32 */
+        if (len < 2)
+                len = 2;
+        else if (len > sizeof(buf))
+                len = sizeof(buf);
+        memset(buf, 0, sizeof buf);
+
+        status = read(fd, buf, len);
+        if (status < 0) {
+                perror("read");
+                return;
+        }
+        if (status != len) {
+                fprintf(stderr, "short read\n");
+                return;
+        }
+
+        printf("read(%2d, %2d): %02x %02x,", len, status,
+                buf[0], buf[1]);
+        status -= 2;
+        bp = buf + 2;
+        while (status-- > 0)
+                printf(" %02x", *bp++);
+        printf("\n");
+}
+
+static void do_msg(int fd, int len)
+{
+        struct spi_ioc_transfer xfer[2];
+        unsigned char           buf[32], *bp;
+        int                     status;
+
+        memset(xfer, 0, sizeof xfer);
+        memset(buf, 0, sizeof buf);
+
+        if (len > sizeof buf)
+                len = sizeof buf;
+
+        buf[0] = 0xaa;
+        xfer[0].tx_buf = (__u64) buf;
+        xfer[0].len = 1;
+
+        xfer[1].rx_buf = (__u64) buf;
+        xfer[1].len = len;
+
+        status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
+        if (status < 0) {
+                perror("SPI_IOC_MESSAGE");
+                return;
+        }
+
+        printf("response(%2d, %2d): ", len, status);
+        for (bp = buf; len; len--)
+                printf(" %02x", *bp++);
+        printf("\n");
+}
+
+static void dumpstat(const char *name, int fd)
+{
+        __u8    mode, lsb, bits;
+        __u32   speed;
+
+        if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
+                perror("SPI rd_mode");
+                return;
+        }
+        if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
+                perror("SPI rd_lsb_fist");
+                return;
+        }
+        if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
+                perror("SPI bits_per_word");
+                return;
+        }
+        if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
+                perror("SPI max_speed_hz");
+                return;
+        }
+
+        printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
+                name, mode, bits, lsb ? "(lsb first) " : "", speed);
+}
+
+int main(int argc, char **argv)
+{
+        int             c;
+        int             readcount = 0;
+        int             msglen = 0;
+        int             fd;
+        const char      *name;
+
+        while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
+                switch (c) {
+                case 'm':
+                        msglen = atoi(optarg);
+                        if (msglen < 0)
+                                goto usage;
+                        continue;
+                case 'r':
+                        readcount = atoi(optarg);
+                        if (readcount < 0)
+                                goto usage;
+                        continue;
+                case 'v':
+                        verbose++;
+                        continue;
+                case 'h':
+                case '?':
+usage:
+                        fprintf(stderr,
+                                "usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
+                                argv[0]);
+                        return 1;
+                }
+        }
+
+        if ((optind + 1) != argc)
+                goto usage;
+        name = argv[optind];
+
+        fd = open(name, O_RDWR);
+        if (fd < 0) {
+                perror("open");
+                return 1;
+        }
+
+        dumpstat(name, fd);
+
+        if (msglen)
+                do_msg(fd, msglen);
+
+        if (readcount)
+                do_read(fd, readcount);
+
+        close(fd);
+        return 0;
+}
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 471e75389778..619699dde593 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -5,6 +5,28 @@ Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
 __SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
 initialization.
 
+Most of the time, you can simply turn:
+
+        static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
+
+into:
+
+        static DEFINE_SPINLOCK(xxx_lock);
+
+Static structure member variables go from:
+
+        struct foo bar {
+                .lock   =       SPIN_LOCK_UNLOCKED;
+        };
+
+to:
+
+        struct foo bar {
+                .lock   =       __SPIN_LOCK_UNLOCKED(bar.lock);
+        };
+
+Declaration of static rw_locks undergo a similar transformation.
+
 Dynamic initialization, when necessary, may be performed as
 demonstrated below.
 
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index 10c8f6922ef4..5ce0952aa065 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -85,6 +85,8 @@ On all -  write a character to /proc/sysrq-trigger.  e.g.:
 'k'     - Secure Access Key (SAK) Kills all programs on the current virtual
           console. NOTE: See important comments below in SAK section.
 
+'l'     - Shows a stack backtrace for all active CPUs.
+
 'm'     - Will dump current memory info to your console.
 
 'n'     - Used to make RT tasks nice-able
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index d9f28be75403..70d68ce8640a 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -108,10 +108,12 @@ and throttle appropriate devices.
 RO      read only value
 RW      read/write value
 
-All thermal sysfs attributes will be represented under /sys/class/thermal
+Thermal sysfs attributes will be represented under /sys/class/thermal.
+Hwmon sysfs I/F extension is also available under /sys/class/hwmon
+if hwmon is compiled in or built as a module.
 
 Thermal zone device sys I/F, created once it's registered:
-|thermal_zone[0-*]:
+/sys/class/thermal/thermal_zone[0-*]:
         |-----type:                     Type of the thermal zone
         |-----temp:                     Current temperature
         |-----mode:                     Working mode of the thermal zone
@@ -119,7 +121,7 @@ Thermal zone device sys I/F, created once it's registered:
         |-----trip_point_[0-*]_type:    Trip point type
 
 Thermal cooling device sys I/F, created once it's registered:
-|cooling_device[0-*]:
+/sys/class/thermal/cooling_device[0-*]:
         |-----type :                    Type of the cooling device(processor/fan/...)
         |-----max_state:                Maximum cooling state of the cooling device
         |-----cur_state:                Current cooling state of the cooling device
@@ -130,10 +132,19 @@ They represent the relationship between a thermal zone and its associated coolin
 They are created/removed for each
 thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution.
 
-|thermal_zone[0-*]
+/sys/class/thermal/thermal_zone[0-*]
         |-----cdev[0-*]:                The [0-*]th cooling device in the current thermal zone
         |-----cdev[0-*]_trip_point:     Trip point that cdev[0-*] is associated with
 
+Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
+the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of
+thermal zone device. E.g. the generic thermal driver registers one hwmon class device
+and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones.
+/sys/class/hwmon/hwmon[0-*]:
+        |-----name:                     The type of the thermal zone devices.
+        |-----temp[1-*]_input:          The current temperature of thermal zone [1-*].
+        |-----temp[1-*]_critical:       The critical trip point of thermal zone [1-*].
+Please read Documentation/hwmon/sysfs-interface for additional information.
 
 ***************************
 * Thermal zone attributes *
@@ -141,7 +152,10 @@ thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful e
 
 type                            Strings which represent the thermal zone type.
                                 This is given by thermal zone driver as part of registration.
-                                Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
+                                Eg: "acpitz" indicates it's an ACPI thermal device.
+                                In order to keep it consistent with hwmon sys attribute,
+                                this should be a short, lowercase string,
+                                not containing spaces nor dashes.
                                 RO
                                 Required
 
@@ -218,7 +232,7 @@ the sys I/F structure will be built like this:
 /sys/class/thermal:
 
 |thermal_zone1:
-        |-----type:                     ACPI thermal zone
+        |-----type:                     acpitz
         |-----temp:                     37000
         |-----mode:                     kernel
         |-----trip_point_0_temp:        100000
@@ -243,3 +257,10 @@ the sys I/F structure will be built like this:
         |-----type:                     Fan
         |-----max_state:                2
         |-----cur_state:                0
+
+/sys/class/hwmon:
+
+|hwmon0:
+        |-----name:                     acpitz
+        |-----temp1_input:              37000
+        |-----temp1_crit:               100000
diff --git a/Documentation/hrtimers/highres.txt b/Documentation/timers/highres.txt
index ce0e9a91e157..a73ecf5b4bdb 100644
--- a/Documentation/hrtimers/highres.txt
+++ b/Documentation/timers/highres.txt
@@ -98,7 +98,7 @@ System-level global event devices are used for the Linux periodic tick. Per-CPU
 event devices are used to provide local CPU functionality such as process
 accounting, profiling, and high resolution timers.
 
-The management layer assignes one or more of the folliwing functions to a clock
+The management layer assigns one or more of the following functions to a clock
 event device:
       - system global periodic tick (jiffies update)
       - cpu local update_process_times
diff --git a/Documentation/hrtimers/hrtimers.txt b/Documentation/timers/hrtimers.txt
index ce31f65e12e7..ce31f65e12e7 100644
--- a/Documentation/hrtimers/hrtimers.txt
+++ b/Documentation/timers/hrtimers.txt
diff --git a/Documentation/hrtimer/timer_stats.txt b/Documentation/timers/timer_stats.txt
index 20d368c59814..20d368c59814 100644
--- a/Documentation/hrtimer/timer_stats.txt
+++ b/Documentation/timers/timer_stats.txt
diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt
index 6223eace3c09..b0472ac5226a 100644
--- a/Documentation/unaligned-memory-access.txt
+++ b/Documentation/unaligned-memory-access.txt
@@ -57,7 +57,7 @@ here; a summary of the common scenarios is presented below:
    unaligned access to be corrected.
  - Some architectures are not capable of unaligned memory access, but will
    silently perform a different memory access to the one that was requested,
-   resulting a a subtle code bug that is hard to detect!
+   resulting in a subtle code bug that is hard to detect!
 
 It should be obvious from the above that if your code causes unaligned
 memory accesses to happen, your code will not work correctly on certain
@@ -209,7 +209,7 @@ memory and you wish to avoid unaligned access, its usage is as follows:
 
         u32 value = get_unaligned((u32 *) data);
 
-These macros work work for memory accesses of any length (not just 32 bits as
+These macros work for memory accesses of any length (not just 32 bits as
 in the examples above). Be aware that when compared to standard access of
 aligned memory, using these macros to access unaligned memory can be costly in
 terms of performance.
diff --git a/Documentation/usb/anchors.txt b/Documentation/usb/anchors.txt
new file mode 100644
index 000000000000..7304bcf5a306
--- /dev/null
+++ b/Documentation/usb/anchors.txt
@@ -0,0 +1,50 @@
+What is anchor?
+===============
+
+A USB driver needs to support some callbacks requiring
+a driver to cease all IO to an interface. To do so, a
+driver has to keep track of the URBs it has submitted
+to know they've all completed or to call usb_kill_urb
+for them. The anchor is a data structure takes care of
+keeping track of URBs and provides methods to deal with
+multiple URBs.
+
+Allocation and Initialisation
+=============================
+
+There's no API to allocate an anchor. It is simply declared
+as struct usb_anchor. init_usb_anchor() must be called to
+initialise the data structure.
+
+Deallocation
+============
+
+Once it has no more URBs associated with it, the anchor can be
+freed with normal memory management operations.
+
+Association and disassociation of URBs with anchors
+===================================================
+
+An association of URBs to an anchor is made by an explicit
+call to usb_anchor_urb(). The association is maintained until
+an URB is finished by (successfull) completion. Thus disassociation
+is automatic. A function is provided to forcibly finish (kill)
+all URBs associated with an anchor.
+Furthermore, disassociation can be made with usb_unanchor_urb()
+
+Operations on multitudes of URBs
+================================
+
+usb_kill_anchored_urbs()
+------------------------
+
+This function kills all URBs associated with an anchor. The URBs
+are called in the reverse temporal order they were submitted.
+This way no data can be reordered.
+
+usb_wait_anchor_empty_timeout()
+-------------------------------
+
+This function waits for all URBs associated with an anchor to finish
+or a timeout, whichever comes first. Its return value will tell you
+whether the timeout was reached.
diff --git a/Documentation/usb/callbacks.txt b/Documentation/usb/callbacks.txt
new file mode 100644
index 000000000000..7c812411945b
--- /dev/null
+++ b/Documentation/usb/callbacks.txt
@@ -0,0 +1,132 @@
+What callbacks will usbcore do?
+===============================
+
+Usbcore will call into a driver through callbacks defined in the driver
+structure and through the completion handler of URBs a driver submits.
+Only the former are in the scope of this document. These two kinds of
+callbacks are completely independent of each other. Information on the
+completion callback can be found in Documentation/usb/URB.txt.
+
+The callbacks defined in the driver structure are:
+
+1. Hotplugging callbacks:
+
+ * @probe: Called to see if the driver is willing to manage a particular
+ *      interface on a device.
+ * @disconnect: Called when the interface is no longer accessible, usually
+ *      because its device has been (or is being) disconnected or the
+ *      driver module is being unloaded.
+
+2. Odd backdoor through usbfs:
+
+ * @ioctl: Used for drivers that want to talk to userspace through
+ *      the "usbfs" filesystem.  This lets devices provide ways to
+ *      expose information to user space regardless of where they
+ *      do (or don't) show up otherwise in the filesystem.
+
+3. Power management (PM) callbacks:
+
+ * @suspend: Called when the device is going to be suspended.
+ * @resume: Called when the device is being resumed.
+ * @reset_resume: Called when the suspended device has been reset instead
+ *      of being resumed.
+
+4. Device level operations:
+
+ * @pre_reset: Called when the device is about to be reset.
+ * @post_reset: Called after the device has been reset
+
+The ioctl interface (2) should be used only if you have a very good
+reason. Sysfs is preferred these days. The PM callbacks are covered
+separately in Documentation/usb/power-management.txt.
+
+Calling conventions
+===================
+
+All callbacks are mutually exclusive. There's no need for locking
+against other USB callbacks. All callbacks are called from a task
+context. You may sleep. However, it is important that all sleeps have a
+small fixed upper limit in time. In particular you must not call out to
+user space and await results.
+
+Hotplugging callbacks
+=====================
+
+These callbacks are intended to associate and disassociate a driver with
+an interface. A driver's bond to an interface is exclusive.
+
+The probe() callback
+--------------------
+
+int (*probe) (struct usb_interface *intf,
+                const struct usb_device_id *id);
+
+Accept or decline an interface. If you accept the device return 0,
+otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
+genuine error occurred during initialisation which prevented a driver
+from accepting a device that would else have been accepted.
+You are strongly encouraged to use usbcore'sfacility,
+usb_set_intfdata(), to associate a data structure with an interface, so
+that you know which internal state and identity you associate with a
+particular interface. The device will not be suspended and you may do IO
+to the interface you are called for and endpoint 0 of the device. Device
+initialisation that doesn't take too long is a good idea here.
+
+The disconnect() callback
+-------------------------
+
+void (*disconnect) (struct usb_interface *intf);
+
+This callback is a signal to break any connection with an interface.
+You are not allowed any IO to a device after returning from this
+callback. You also may not do any other operation that may interfere
+with another driver bound the interface, eg. a power management
+operation.
+If you are called due to a physical disconnection, all your URBs will be
+killed by usbcore. Note that in this case disconnect will be called some
+time after the physical disconnection. Thus your driver must be prepared
+to deal with failing IO even prior to the callback.
+
+Device level callbacks
+======================
+
+pre_reset
+---------
+
+int (*pre_reset)(struct usb_interface *intf);
+
+Another driver or user space is triggering a reset on the device which
+contains the interface passed as an argument. Cease IO and save any
+device state you need to restore.
+
+If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
+are in atomic context.
+
+post_reset
+----------
+
+int (*post_reset)(struct usb_interface *intf);
+
+The reset has completed.  Restore any saved device state and begin
+using the device again.
+
+If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
+are in atomic context.
+
+Call sequences
+==============
+
+No callbacks other than probe will be invoked for an interface
+that isn't bound to your driver.
+
+Probe will never be called for an interface bound to a driver.
+Hence following a successful probe, disconnect will be called
+before there is another probe for the same interface.
+
+Once your driver is bound to an interface, disconnect can be
+called at any time except in between pre_reset and post_reset.
+pre_reset is always followed by post_reset, even if the reset
+failed or the device has been unplugged.
+
+suspend is always followed by one of: resume, reset_resume, or
+disconnect.
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt
index df54d645cbb5..d56cb1a11550 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/usb/persist.txt
@@ -2,7 +2,7 @@
 
                    Alan Stern <stern@rowland.harvard.edu>
 
-                 September 2, 2006 (Updated May 29, 2007)
+                September 2, 2006 (Updated February 25, 2008)
 
 
         What is the problem?
@@ -65,9 +65,10 @@ much better.)
 
         What is the solution?
 
-Setting CONFIG_USB_PERSIST will cause the kernel to work around these
-issues.  It enables a mode in which the core USB device data
-structures are allowed to persist across a power-session disruption.
+The kernel includes a feature called USB-persist.  It tries to work
+around these issues by allowing the core USB device data structures to
+persist across a power-session disruption.
+
 It works like this.  If the kernel sees that a USB host controller is
 not in the expected state during resume (i.e., if the controller was
 reset or otherwise had lost power) then it applies a persistence check
@@ -80,28 +81,30 @@ re-enumeration shows that the device now attached to that port has the
 same descriptors as before, including the Vendor and Product IDs, then
 the kernel continues to use the same device structure.  In effect, the
 kernel treats the device as though it had merely been reset instead of
-unplugged.
+unplugged.  The same thing happens if the host controller is in the
+expected state but a USB device was unplugged and then replugged.
 
 If no device is now attached to the port, or if the descriptors are
 different from what the kernel remembers, then the treatment is what
 you would expect.  The kernel destroys the old device structure and
 behaves as though the old device had been unplugged and a new device
-plugged in, just as it would without the CONFIG_USB_PERSIST option.
+plugged in.
 
 The end result is that the USB device remains available and usable.
 Filesystem mounts and memory mappings are unaffected, and the world is
 now a good and happy place.
 
-Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
-will be applied only to those devices for which it is enabled.  You
-can enable the feature by doing (as root):
+Note that the "USB-persist" feature will be applied only to those
+devices for which it is enabled.  You can enable the feature by doing
+(as root):
 
         echo 1 >/sys/bus/usb/devices/.../power/persist
 
 where the "..." should be filled in the with the device's ID.  Disable
 the feature by writing 0 instead of 1.  For hubs the feature is
-automatically and permanently enabled, so you only have to worry about
-setting it for devices where it really matters.
+automatically and permanently enabled and the power/persist file
+doesn't even exist, so you only have to worry about setting it for
+devices where it really matters.
 
 
         Is this the best solution?
@@ -112,19 +115,19 @@ centralized Logical Volume Manager.  Such a solution would allow you
 to plug in a USB flash device, create a persistent volume associated
 with it, unplug the flash device, plug it back in later, and still
 have the same persistent volume associated with the device.  As such
-it would be more far-reaching than CONFIG_USB_PERSIST.
+it would be more far-reaching than USB-persist.
 
 On the other hand, writing a persistent volume manager would be a big
 job and using it would require significant input from the user.  This
 solution is much quicker and easier -- and it exists now, a giant
 point in its favor!
 
-Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
+Furthermore, the USB-persist feature applies to _all_ USB devices, not
 just mass-storage devices.  It might turn out to be equally useful for
 other device types, such as network interfaces.
 
 
-        WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
+        WARNING: USB-persist can be dangerous!!
 
 When recovering an interrupted power session the kernel does its best
 to make sure the USB device hasn't been changed; that is, the same
@@ -133,10 +136,10 @@ aren't guaranteed to be 100% accurate.
 
 If you replace one USB device with another of the same type (same
 manufacturer, same IDs, and so on) there's an excellent chance the
-kernel won't detect the change.  Serial numbers and other strings are
-not compared.  In many cases it wouldn't help if they were, because
-manufacturers frequently omit serial numbers entirely in their
-devices.
+kernel won't detect the change.  The serial number string and other
+descriptors are compared with the kernel's stored values, but this
+might not help since manufacturers frequently omit serial numbers
+entirely in their devices.
 
 Furthermore it's quite possible to leave a USB device exactly the same
 while changing its media.  If you replace the flash memory card in a
@@ -152,5 +155,5 @@ but yourself.
 YOU HAVE BEEN WARNED!  USE AT YOUR OWN RISK!
 
 That having been said, most of the time there shouldn't be any trouble
-at all.  The "persist" feature can be extremely useful.  Make the most
-of it.
+at all.  The USB-persist feature can be extremely useful.  Make the
+most of it.
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 8b077e43eee7..ff2c1ff57ba2 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -192,12 +192,9 @@ Keyspan USA-series Serial Adapters
 
 FTDI Single Port Serial Driver
 
-  This is a single port DB-25 serial adapter. More information about this
-  device and the Linux driver can be found at:
-        http://reality.sgi.com/bryder_wellington/ftdi_sio/
+  This is a single port DB-25 serial adapter.
 
-  For any questions or problems with this driver, please contact Bill Ryder
-  at bryder@sgi.com
+  For any questions or problems with this driver, please contact Bill Ryder.
 
 
 ZyXEL omni.net lcd plus ISDN TA
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828
new file mode 100644
index 000000000000..86d1c8e7b18f
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.au0828
@@ -0,0 +1,4 @@
+  0 -> Unknown board                            (au0828)
+  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008]
+  2 -> Hauppauge HVR850                         (au0828)        [2040:7240]
+  3 -> DViCO FusionHDTV USB                     (au0828)        [0fe9:d620]
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index d97cf7cc6088..f32efb6fb12c 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -148,3 +148,5 @@
 147 -> VoodooTV 200 (USA)                                  [121a:3000]
 148 -> DViCO FusionHDTV 2                                  [dbc0:d200]
 149 -> Typhoon TV-Tuner PCI (50684)
+150 -> Geovision GV-600                                    [008a:763c]
+151 -> Kozumi KTV-01C
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 0924e6e142c4..191194ea1e25 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -5,3 +5,6 @@
   4 -> DViCO FusionHDTV5 Express                           [18ac:d500]
   5 -> Hauppauge WinTV-HVR1500Q                            [0070:7790,0070:7797]
   6 -> Hauppauge WinTV-HVR1500                             [0070:7710,0070:7717]
+  7 -> Hauppauge WinTV-HVR1200                             [0070:71d1,0070:71d3]
+  8 -> Hauppauge WinTV-HVR1700                             [0070:8101]
+  9 -> Hauppauge WinTV-HVR1400                             [0070:8010]
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index bc5593bd9704..7cf5685d3645 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -57,3 +57,12 @@
  56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder   [0070:9600,0070:9601,0070:9602]
  57 -> ADS Tech Instant Video PCI                          [1421:0390]
  58 -> Pinnacle PCTV HD 800i                               [11bd:0051]
+ 59 -> DViCO FusionHDTV 5 PCI nano                         [18ac:d530]
+ 60 -> Pinnacle Hybrid PCTV                                [12ab:1788]
+ 61 -> Winfast TV2000 XP Global                            [107d:6f18]
+ 62 -> PowerColor RA330                                    [14f1:ea3d]
+ 63 -> Geniatech X8000-MT DVBT                             [14f1:8852]
+ 64 -> DViCO FusionHDTV DVB-T PRO                          [18ac:db30]
+ 65 -> DViCO FusionHDTV 7 Gold                             [18ac:d610]
+ 66 -> Prolink Pixelview MPEG 8000GT                       [1554:4935]
+ 67 -> Kworld PlusTV HD PCI 120 (ATSC 120)                 [17de:08c1]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index f40e09296f30..1d6a245c828f 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -14,4 +14,4 @@
  13 -> Terratec Prodigy XS                      (em2880)        [0ccd:0047]
  14 -> Pixelview Prolink PlayTV USB 2.0         (em2820/em2840)
  15 -> V-Gear PocketTV                          (em2800)
- 16 -> Hauppauge WinTV HVR 950                  (em2880)        [2040:6513]
+ 16 -> Hauppauge WinTV HVR 950                  (em2880)        [2040:6513,2040:6517,2040:651b,2040:651f]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 0424901ebc78..67937df1e974 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -25,8 +25,8 @@
  24 -> KNC One TV-Station DVR                   [1894:a006]
  25 -> ASUS TV-FM 7133                          [1043:4843]
  26 -> Pinnacle PCTV Stereo (saa7134)           [11bd:002b]
- 27 -> Manli MuchTV M-TV002/Behold TV 403 FM
- 28 -> Manli MuchTV M-TV001/Behold TV 401
+ 27 -> Manli MuchTV M-TV002
+ 28 -> Manli MuchTV M-TV001
  29 -> Nagase Sangyo TransGear 3000TV           [1461:050c]
  30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM)  [1019:4cb4]
  31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
@@ -128,6 +128,16 @@
 127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090]
 128 -> Beholder BeholdTV Columbus TVFM          [0000:5201]
 129 -> Beholder BeholdTV 607 / BeholdTV 609     [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093]
-130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
+130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193,5ace:6191]
 131 -> Twinhan Hybrid DTV-DVB 3056 PCI          [1822:0022]
 132 -> Genius TVGO AM11MCE
+133 -> NXP Snake DVB-S reference design
+134 -> Medion/Creatix CTX953 Hybrid             [16be:0010]
+135 -> MSI TV@nywhere A/D v1.1                  [1462:8625]
+136 -> AVerMedia Cardbus TV/Radio (E506R)       [1461:f436]
+137 -> AVerMedia Hybrid TV/Radio (A16D)         [1461:f936]
+138 -> Avermedia M115                           [1461:a836]
+139 -> Compro VideoMate T750                    [185b:c900]
+140 -> Avermedia DVB-S Pro A700                 [1461:a7a1]
+141 -> Avermedia DVB-S Hybrid+FM A700           [1461:a7a2]
+142 -> Beholder BeholdTV H6                     [5ace:6290]
diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt
new file mode 100644
index 000000000000..6842c262890f
--- /dev/null
+++ b/Documentation/video4linux/cx18.txt
@@ -0,0 +1,36 @@
+Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
+encoder chip:
+
+1) The only hardware currently supported is the Hauppauge HVR-1600
+   card and the Compro VideoMate H900 (note that this card only
+   supports analog input, it has no digital tuner!).
+
+2) Some people have problems getting the i2c bus to work. Cause unknown.
+   The symptom is that the eeprom cannot be read and the card is
+   unusable.
+
+3) The audio from the analog tuner is mono only. Probably caused by
+   incorrect audio register information in the datasheet. We are
+   waiting for updated information from Conexant.
+
+4) VBI (raw or sliced) has not yet been implemented.
+
+5) MPEG indexing is not yet implemented.
+
+6) The driver is still a bit rough around the edges, this should
+   improve over time.
+
+
+Firmware:
+
+The firmware needs to be extracted from the Windows Hauppauge HVR-1600
+driver, available here:
+
+http://hauppauge.lightpath.net/software/install_cd/hauppauge_cd_3.4d1.zip
+
+Unzip, then copy the following files to the firmware directory
+and rename them as follows:
+
+Drivers/Driver18/hcw18apu.rom -> v4l-cx23418-apu.fw
+Drivers/Driver18/hcw18enc.rom -> v4l-cx23418-cpu.fw
+Drivers/Driver18/hcw18mlC.rom -> v4l-cx23418-dig.fw
diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl
index cced8ac5c543..2cb816047fc1 100644
--- a/Documentation/video4linux/extract_xc3028.pl
+++ b/Documentation/video4linux/extract_xc3028.pl
@@ -686,11 +686,11 @@ sub main_firmware($$$$)
         write_hunk(812664, 192);
 
         #
-        # Firmware 58, type: SCODE FW  HAS IF (0x60000000), IF = 4.50 MHz id: NTSC/M Jp (0000000000002000), size: 192
+        # Firmware 58, type: SCODE FW  MTS LCD NOGD MONO IF HAS IF (0x6002b004), IF = 4.50 MHz id: NTSC PAL/M PAL/N (000000000000b700), size: 192
         #
 
-        write_le32(0x60000000);                 # Type
-        write_le64(0x00000000, 0x00002000);     # ID
+        write_le32(0x6002b004);                 # Type
+        write_le64(0x00000000, 0x0000b700);     # ID
         write_le16(4500);                       # IF
         write_le32(192);                        # Size
         write_hunk(807672, 192);
@@ -706,10 +706,10 @@ sub main_firmware($$$$)
         write_hunk(807864, 192);
 
         #
-        # Firmware 60, type: SCODE FW  DTV78 ZARLINK456 HAS IF (0x62000100), IF = 4.76 MHz id: (0000000000000000), size: 192
+        # Firmware 60, type: SCODE FW  DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 HAS IF (0x620003e0), IF = 4.76 MHz id: (0000000000000000), size: 192
         #
 
-        write_le32(0x62000100);                 # Type
+        write_le32(0x620003e0);                 # Type
         write_le64(0x00000000, 0x00000000);     # ID
         write_le16(4760);                       # IF
         write_le32(192);                        # Size
@@ -726,30 +726,30 @@ sub main_firmware($$$$)
         write_hunk(811512, 192);
 
         #
-        # Firmware 62, type: SCODE FW  DTV7 ZARLINK456 HAS IF (0x62000080), IF = 5.26 MHz id: (0000000000000000), size: 192
+        # Firmware 62, type: SCODE FW  HAS IF (0x60000000), IF = 5.26 MHz id: (0000000000000000), size: 192
         #
 
-        write_le32(0x62000080);                 # Type
+        write_le32(0x60000000);                 # Type
         write_le64(0x00000000, 0x00000000);     # ID
         write_le16(5260);                       # IF
         write_le32(192);                        # Size
         write_hunk(810552, 192);
 
         #
-        # Firmware 63, type: SCODE FW  MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
+        # Firmware 63, type: SCODE FW  MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG A2 NICAM (0000000f00000007), size: 192
         #
 
         write_le32(0x60008000);                 # Type
-        write_le64(0x00000008, 0x00000007);     # ID
+        write_le64(0x0000000f, 0x00000007);     # ID
         write_le16(5320);                       # IF
         write_le32(192);                        # Size
         write_hunk(810744, 192);
 
         #
-        # Firmware 64, type: SCODE FW  DTV8 CHINA HAS IF (0x64000200), IF = 5.40 MHz id: (0000000000000000), size: 192
+        # Firmware 64, type: SCODE FW  DTV7 DTV78 DTV8 DIBCOM52 CHINA HAS IF (0x65000380), IF = 5.40 MHz id: (0000000000000000), size: 192
         #
 
-        write_le32(0x64000200);                 # Type
+        write_le32(0x65000380);                 # Type
         write_le64(0x00000000, 0x00000000);     # ID
         write_le16(5400);                       # IF
         write_le32(192);                        # Size
@@ -766,50 +766,50 @@ sub main_firmware($$$$)
         write_hunk(809592, 192);
 
         #
-        # Firmware 66, type: SCODE FW  HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2/B (0000000200000007), size: 192
+        # Firmware 66, type: SCODE FW  HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2 (0000000300000007), size: 192
         #
 
         write_le32(0x60000000);                 # Type
-        write_le64(0x00000002, 0x00000007);     # ID
+        write_le64(0x00000003, 0x00000007);     # ID
         write_le16(5640);                       # IF
         write_le32(192);                        # Size
         write_hunk(808440, 192);
 
         #
-        # Firmware 67, type: SCODE FW  HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
+        # Firmware 67, type: SCODE FW  HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM (0000000c00000007), size: 192
         #
 
         write_le32(0x60000000);                 # Type
-        write_le64(0x00000008, 0x00000007);     # ID
+        write_le64(0x0000000c, 0x00000007);     # ID
         write_le16(5740);                       # IF
         write_le32(192);                        # Size
         write_hunk(808632, 192);
 
         #
-        # Firmware 68, type: SCODE FW  DTV7 DIBCOM52 HAS IF (0x61000080), IF = 5.90 MHz id: (0000000000000000), size: 192
+        # Firmware 68, type: SCODE FW  HAS IF (0x60000000), IF = 5.90 MHz id: (0000000000000000), size: 192
         #
 
-        write_le32(0x61000080);                 # Type
+        write_le32(0x60000000);                 # Type
         write_le64(0x00000000, 0x00000000);     # ID
         write_le16(5900);                       # IF
         write_le32(192);                        # Size
         write_hunk(810360, 192);
 
         #
-        # Firmware 69, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/I (0000000000000010), size: 192
+        # Firmware 69, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/DK PAL/I SECAM/K3 SECAM/L SECAM/Lc NICAM (0000000c04c000f0), size: 192
         #
 
         write_le32(0x60008000);                 # Type
-        write_le64(0x00000000, 0x00000010);     # ID
+        write_le64(0x0000000c, 0x04c000f0);     # ID
         write_le16(6000);                       # IF
         write_le32(192);                        # Size
         write_hunk(808824, 192);
 
         #
-        # Firmware 70, type: SCODE FW  DTV6 QAM F6MHZ HAS IF (0x68000060), IF = 6.20 MHz id: (0000000000000000), size: 192
+        # Firmware 70, type: SCODE FW  DTV6 QAM ATSC LG60 F6MHZ HAS IF (0x68050060), IF = 6.20 MHz id: (0000000000000000), size: 192
         #
 
-        write_le32(0x68000060);                 # Type
+        write_le32(0x68050060);                 # Type
         write_le64(0x00000000, 0x00000000);     # ID
         write_le16(6200);                       # IF
         write_le32(192);                        # Size
@@ -846,11 +846,11 @@ sub main_firmware($$$$)
         write_hunk(809208, 192);
 
         #
-        # Firmware 74, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.50 MHz id: SECAM/K3 (0000000004000000), size: 192
+        # Firmware 74, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.50 MHz id: PAL/DK SECAM/K3 SECAM/L NICAM (0000000c044000e0), size: 192
         #
 
         write_le32(0x60008000);                 # Type
-        write_le64(0x00000000, 0x04000000);     # ID
+        write_le64(0x0000000c, 0x044000e0);     # ID
         write_le16(6500);                       # IF
         write_le32(192);                        # Size
         write_hunk(811128, 192);
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index f962d01bea2a..3102b81bef88 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As
 these surplus hugepages go out of use, they are freed back to the buddy
 allocator.
 
-Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect
-will allow the number of surplus huge pages to exceed the overcommit
-value, as the pool hugepages (which must have been in use for a surplus
-hugepages to be allocated) will become surplus hugepages.  As long as
+Caveat: Shrinking the pool via nr_hugepages such that it becomes less
+than the number of hugepages in use will convert the balance to surplus
+huge pages even if it would exceed the overcommit value.  As long as
 this condition holds, however, no more surplus huge pages will be
 allowed on the system until one of the two sysctls are increased
 sufficiently, or the surplus huge pages go out of use and are freed.
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt
index dd4986497996..bad16d3f6a47 100644
--- a/Documentation/vm/numa_memory_policy.txt
+++ b/Documentation/vm/numa_memory_policy.txt
@@ -135,77 +135,58 @@ most general to most specific:
 
 Components of Memory Policies
 
-    A Linux memory policy is a tuple consisting of a "mode" and an optional set
-    of nodes.  The mode determine the behavior of the policy, while the
-    optional set of nodes can be viewed as the arguments to the behavior.
+    A Linux memory policy consists of a "mode", optional mode flags, and an
+    optional set of nodes.  The mode determines the behavior of the policy,
+    the optional mode flags determine the behavior of the mode, and the
+    optional set of nodes can be viewed as the arguments to the policy
+    behavior.
 
    Internally, memory policies are implemented by a reference counted
    structure, struct mempolicy.  Details of this structure will be discussed
    in context, below, as required to explain the behavior.
 
-        Note:  in some functions AND in the struct mempolicy itself, the mode
-        is called "policy".  However, to avoid confusion with the policy tuple,
-        this document will continue to use the term "mode".
-
    Linux memory policy supports the following 4 behavioral modes:
 
-        Default Mode--MPOL_DEFAULT:  The behavior specified by this mode is
-        context or scope dependent.
-
-            As mentioned in the Policy Scope section above, during normal
-            system operation, the System Default Policy is hard coded to
-            contain the Default mode.
-
-            In this context, default mode means "local" allocation--that is
-            attempt to allocate the page from the node associated with the cpu
-            where the fault occurs.  If the "local" node has no memory, or the
-            node's memory can be exhausted [no free pages available], local
-            allocation will "fallback to"--attempt to allocate pages from--
-            "nearby" nodes, in order of increasing "distance".
+        Default Mode--MPOL_DEFAULT:  This mode is only used in the memory
+        policy APIs.  Internally, MPOL_DEFAULT is converted to the NULL
+        memory policy in all policy scopes.  Any existing non-default policy
+        will simply be removed when MPOL_DEFAULT is specified.  As a result,
+        MPOL_DEFAULT means "fall back to the next most specific policy scope."
 
-                Implementation detail -- subject to change:  "Fallback" uses
-                a per node list of sibling nodes--called zonelists--built at
-                boot time, or when nodes or memory are added or removed from
-                the system [memory hotplug].  These per node zonelist are
-                constructed with nodes in order of increasing distance based
-                on information provided by the platform firmware.
+            For example, a NULL or default task policy will fall back to the
+            system default policy.  A NULL or default vma policy will fall
+            back to the task policy.
 
-            When a task/process policy or a shared policy contains the Default
-            mode, this also means "local allocation", as described above.
+            When specified in one of the memory policy APIs, the Default mode
+            does not use the optional set of nodes.
 
-            In the context of a VMA, Default mode means "fall back to task
-            policy"--which may or may not specify Default mode.  Thus, Default
-            mode can not be counted on to mean local allocation when used
-            on a non-shared region of the address space.  However, see
-            MPOL_PREFERRED below.
-
-            The Default mode does not use the optional set of nodes.
+            It is an error for the set of nodes specified for this policy to
+            be non-empty.
 
         MPOL_BIND:  This mode specifies that memory must come from the
-        set of nodes specified by the policy.
-
-            The memory policy APIs do not specify an order in which the nodes
-            will be searched.  However, unlike "local allocation", the Bind
-            policy does not consider the distance between the nodes.  Rather,
-            allocations will fallback to the nodes specified by the policy in
-            order of numeric node id.  Like everything in Linux, this is subject
-            to change.
+        set of nodes specified by the policy.  Memory will be allocated from
+        the node in the set with sufficient free memory that is closest to
+        the node where the allocation takes place.
 
         MPOL_PREFERRED:  This mode specifies that the allocation should be
         attempted from the single node specified in the policy.  If that
-        allocation fails, the kernel will search other nodes, exactly as
-        it would for a local allocation that started at the preferred node
-        in increasing distance from the preferred node.  "Local" allocation
-        policy can be viewed as a Preferred policy that starts at the node
+        allocation fails, the kernel will search other nodes, in order of
+        increasing distance from the preferred node based on information
+        provided by the platform firmware.
         containing the cpu where the allocation takes place.
 
             Internally, the Preferred policy uses a single node--the
-            preferred_node member of struct mempolicy.  A "distinguished
-            value of this preferred_node, currently '-1', is interpreted
-            as "the node containing the cpu where the allocation takes
-            place"--local allocation.  This is the way to specify
-            local allocation for a specific range of addresses--i.e. for
-            VMA policies.
+            preferred_node member of struct mempolicy.  When the internal
+            mode flag MPOL_F_LOCAL is set, the preferred_node is ignored and
+            the policy is interpreted as local allocation.  "Local" allocation
+            policy can be viewed as a Preferred policy that starts at the node
+            containing the cpu where the allocation takes place.
+
+            It is possible for the user to specify that local allocation is
+            always preferred by passing an empty nodemask with this mode.
+            If an empty nodemask is passed, the policy cannot use the
+            MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES flags described
+            below.
 
         MPOL_INTERLEAVED:  This mode specifies that page allocations be
         interleaved, on a page granularity, across the nodes specified in
@@ -231,6 +212,154 @@ Components of Memory Policies
             the temporary interleaved system default policy works in this
             mode.
 
+   Linux memory policy supports the following optional mode flags:
+
+        MPOL_F_STATIC_NODES:  This flag specifies that the nodemask passed by
+        the user should not be remapped if the task or VMA's set of allowed
+        nodes changes after the memory policy has been defined.
+
+            Without this flag, anytime a mempolicy is rebound because of a
+            change in the set of allowed nodes, the node (Preferred) or
+            nodemask (Bind, Interleave) is remapped to the new set of
+            allowed nodes.  This may result in nodes being used that were
+            previously undesired.
+
+            With this flag, if the user-specified nodes overlap with the
+            nodes allowed by the task's cpuset, then the memory policy is
+            applied to their intersection.  If the two sets of nodes do not
+            overlap, the Default policy is used.
+
+            For example, consider a task that is attached to a cpuset with
+            mems 1-3 that sets an Interleave policy over the same set.  If
+            the cpuset's mems change to 3-5, the Interleave will now occur
+            over nodes 3, 4, and 5.  With this flag, however, since only node
+            3 is allowed from the user's nodemask, the "interleave" only
+            occurs over that node.  If no nodes from the user's nodemask are
+            now allowed, the Default behavior is used.
+
+            MPOL_F_STATIC_NODES cannot be combined with the
+            MPOL_F_RELATIVE_NODES flag.  It also cannot be used for
+            MPOL_PREFERRED policies that were created with an empty nodemask
+            (local allocation).
+
+        MPOL_F_RELATIVE_NODES:  This flag specifies that the nodemask passed
+        by the user will be mapped relative to the set of the task or VMA's
+        set of allowed nodes.  The kernel stores the user-passed nodemask,
+        and if the allowed nodes changes, then that original nodemask will
+        be remapped relative to the new set of allowed nodes.
+
+            Without this flag (and without MPOL_F_STATIC_NODES), anytime a
+            mempolicy is rebound because of a change in the set of allowed
+            nodes, the node (Preferred) or nodemask (Bind, Interleave) is
+            remapped to the new set of allowed nodes.  That remap may not
+            preserve the relative nature of the user's passed nodemask to its
+            set of allowed nodes upon successive rebinds: a nodemask of
+            1,3,5 may be remapped to 7-9 and then to 1-3 if the set of
+            allowed nodes is restored to its original state.
+
+            With this flag, the remap is done so that the node numbers from
+            the user's passed nodemask are relative to the set of allowed
+            nodes.  In other words, if nodes 0, 2, and 4 are set in the user's
+            nodemask, the policy will be effected over the first (and in the
+            Bind or Interleave case, the third and fifth) nodes in the set of
+            allowed nodes.  The nodemask passed by the user represents nodes
+            relative to task or VMA's set of allowed nodes.
+
+            If the user's nodemask includes nodes that are outside the range
+            of the new set of allowed nodes (for example, node 5 is set in
+            the user's nodemask when the set of allowed nodes is only 0-3),
+            then the remap wraps around to the beginning of the nodemask and,
+            if not already set, sets the node in the mempolicy nodemask.
+
+            For example, consider a task that is attached to a cpuset with
+            mems 2-5 that sets an Interleave policy over the same set with
+            MPOL_F_RELATIVE_NODES.  If the cpuset's mems change to 3-7, the
+            interleave now occurs over nodes 3,5-6.  If the cpuset's mems
+            then change to 0,2-3,5, then the interleave occurs over nodes
+            0,3,5.
+
+            Thanks to the consistent remapping, applications preparing
+            nodemasks to specify memory policies using this flag should
+            disregard their current, actual cpuset imposed memory placement
+            and prepare the nodemask as if they were always located on
+            memory nodes 0 to N-1, where N is the number of memory nodes the
+            policy is intended to manage.  Let the kernel then remap to the
+            set of memory nodes allowed by the task's cpuset, as that may
+            change over time.
+
+            MPOL_F_RELATIVE_NODES cannot be combined with the
+            MPOL_F_STATIC_NODES flag.  It also cannot be used for
+            MPOL_PREFERRED policies that were created with an empty nodemask
+            (local allocation).
+
+MEMORY POLICY REFERENCE COUNTING
+
+To resolve use/free races, struct mempolicy contains an atomic reference
+count field.  Internal interfaces, mpol_get()/mpol_put() increment and
+decrement this reference count, respectively.  mpol_put() will only free
+the structure back to the mempolicy kmem cache when the reference count
+goes to zero.
+
+When a new memory policy is allocated, it's reference count is initialized
+to '1', representing the reference held by the task that is installing the
+new policy.  When a pointer to a memory policy structure is stored in another
+structure, another reference is added, as the task's reference will be dropped
+on completion of the policy installation.
+
+During run-time "usage" of the policy, we attempt to minimize atomic operations
+on the reference count, as this can lead to cache lines bouncing between cpus
+and NUMA nodes.  "Usage" here means one of the following:
+
+1) querying of the policy, either by the task itself [using the get_mempolicy()
+   API discussed below] or by another task using the /proc/<pid>/numa_maps
+   interface.
+
+2) examination of the policy to determine the policy mode and associated node
+   or node lists, if any, for page allocation.  This is considered a "hot
+   path".  Note that for MPOL_BIND, the "usage" extends across the entire
+   allocation process, which may sleep during page reclaimation, because the
+   BIND policy nodemask is used, by reference, to filter ineligible nodes.
+
+We can avoid taking an extra reference during the usages listed above as
+follows:
+
+1) we never need to get/free the system default policy as this is never
+   changed nor freed, once the system is up and running.
+
+2) for querying the policy, we do not need to take an extra reference on the
+   target task's task policy nor vma policies because we always acquire the
+   task's mm's mmap_sem for read during the query.  The set_mempolicy() and
+   mbind() APIs [see below] always acquire the mmap_sem for write when
+   installing or replacing task or vma policies.  Thus, there is no possibility
+   of a task or thread freeing a policy while another task or thread is
+   querying it.
+
+3) Page allocation usage of task or vma policy occurs in the fault path where
+   we hold them mmap_sem for read.  Again, because replacing the task or vma
+   policy requires that the mmap_sem be held for write, the policy can't be
+   freed out from under us while we're using it for page allocation.
+
+4) Shared policies require special consideration.  One task can replace a
+   shared memory policy while another task, with a distinct mmap_sem, is
+   querying or allocating a page based on the policy.  To resolve this
+   potential race, the shared policy infrastructure adds an extra reference
+   to the shared policy during lookup while holding a spin lock on the shared
+   policy management structure.  This requires that we drop this extra
+   reference when we're finished "using" the policy.  We must drop the
+   extra reference on shared policies in the same query/allocation paths
+   used for non-shared policies.  For this reason, shared policies are marked
+   as such, and the extra reference is dropped "conditionally"--i.e., only
+   for shared policies.
+
+   Because of this extra reference counting, and because we must lookup
+   shared policies in a tree structure under spinlock, shared policies are
+   more expensive to use in the page allocation path.  This is expecially
+   true for shared policies on shared memory regions shared by tasks running
+   on different NUMA nodes.  This extra overhead can be avoided by always
+   falling back to task or system default policy for shared memory regions,
+   or by prefaulting the entire shared memory region into memory and locking
+   it down.  However, this might not be appropriate for all applications.
+
 MEMORY POLICY APIs
 
 Linux supports 3 system calls for controlling memory policy.  These APIS
@@ -251,7 +380,9 @@ Set [Task] Memory Policy:
         Set's the calling task's "task/process memory policy" to mode
         specified by the 'mode' argument and the set of nodes defined
         by 'nmask'.  'nmask' points to a bit mask of node ids containing
-        at least 'maxnode' ids.
+        at least 'maxnode' ids.  Optional mode flags may be passed by
+        combining the 'mode' argument with the flag (for example:
+        MPOL_INTERLEAVE | MPOL_F_STATIC_NODES).
 
         See the set_mempolicy(2) man page for more details
 
@@ -303,29 +434,19 @@ MEMORY POLICIES AND CPUSETS
 Memory policies work within cpusets as described above.  For memory policies
 that require a node or set of nodes, the nodes are restricted to the set of
 nodes whose memories are allowed by the cpuset constraints.  If the nodemask
-specified for the policy contains nodes that are not allowed by the cpuset, or
-the intersection of the set of nodes specified for the policy and the set of
-nodes with memory is the empty set, the policy is considered invalid
-and cannot be installed.
-
-The interaction of memory policies and cpusets can be problematic for a
-couple of reasons:
-
-1) the memory policy APIs take physical node id's as arguments.  As mentioned
-   above, it is illegal to specify nodes that are not allowed in the cpuset.
-   The application must query the allowed nodes using the get_mempolicy()
-   API with the MPOL_F_MEMS_ALLOWED flag to determine the allowed nodes and
-   restrict itself to those nodes.  However, the resources available to a
-   cpuset can be changed by the system administrator, or a workload manager
-   application, at any time.  So, a task may still get errors attempting to
-   specify policy nodes, and must query the allowed memories again.
-
-2) when tasks in two cpusets share access to a memory region, such as shared
-   memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and
-   MAP_SHARED flags, and any of the tasks install shared policy on the region,
-   only nodes whose memories are allowed in both cpusets may be used in the
-   policies.  Obtaining this information requires "stepping outside" the
-   memory policy APIs to use the cpuset information and requires that one
-   know in what cpusets other task might be attaching to the shared region.
-   Furthermore, if the cpusets' allowed memory sets are disjoint, "local"
-   allocation is the only valid policy.
+specified for the policy contains nodes that are not allowed by the cpuset and
+MPOL_F_RELATIVE_NODES is not used, the intersection of the set of nodes
+specified for the policy and the set of nodes with memory is used.  If the
+result is the empty set, the policy is considered invalid and cannot be
+installed.  If MPOL_F_RELATIVE_NODES is used, the policy's nodes are mapped
+onto and folded into the task's set of allowed nodes as previously described.
+
+The interaction of memory policies and cpusets can be problematic when tasks
+in two cpusets share access to a memory region, such as shared memory segments
+created by shmget() of mmap() with the MAP_ANONYMOUS and MAP_SHARED flags, and
+any of the tasks install shared policy on the region, only nodes whose
+memories are allowed in both cpusets may be used in the policies.  Obtaining
+this information requires "stepping outside" the memory policy APIs to use the
+cpuset information and requires that one know in what cpusets other task might
+be attaching to the shared region.  Furthermore, if the cpusets' allowed
+memory sets are disjoint, "local" allocation is the only valid policy.
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
new file mode 100644
index 000000000000..ce72c0fe6177
--- /dev/null
+++ b/Documentation/vm/pagemap.txt
@@ -0,0 +1,77 @@
+pagemap, from the userspace perspective
+---------------------------------------
+
+pagemap is a new (as of 2.6.25) set of interfaces in the kernel that allow
+userspace programs to examine the page tables and related information by
+reading files in /proc.
+
+There are three components to pagemap:
+
+ * /proc/pid/pagemap.  This file lets a userspace process find out which
+   physical frame each virtual page is mapped to.  It contains one 64-bit
+   value for each virtual page, containing the following data (from
+   fs/proc/task_mmu.c, above pagemap_read):
+
+    * Bits 0-55  page frame number (PFN) if present
+    * Bits 0-4   swap type if swapped
+    * Bits 5-55  swap offset if swapped
+    * Bits 55-60 page shift (page size = 1<<page shift)
+    * Bit  61    reserved for future use
+    * Bit  62    page swapped
+    * Bit  63    page present
+
+   If the page is not present but in swap, then the PFN contains an
+   encoding of the swap file number and the page's offset into the
+   swap. Unmapped pages return a null PFN. This allows determining
+   precisely which pages are mapped (or in swap) and comparing mapped
+   pages between processes.
+
+   Efficient users of this interface will use /proc/pid/maps to
+   determine which areas of memory are actually mapped and llseek to
+   skip over unmapped regions.
+
+ * /proc/kpagecount.  This file contains a 64-bit count of the number of
+   times each page is mapped, indexed by PFN.
+
+ * /proc/kpageflags.  This file contains a 64-bit set of flags for each
+   page, indexed by PFN.
+
+   The flags are (from fs/proc/proc_misc, above kpageflags_read):
+
+     0. LOCKED
+     1. ERROR
+     2. REFERENCED
+     3. UPTODATE
+     4. DIRTY
+     5. LRU
+     6. ACTIVE
+     7. SLAB
+     8. WRITEBACK
+     9. RECLAIM
+    10. BUDDY
+
+Using pagemap to do something useful:
+
+The general procedure for using pagemap to find out about a process' memory
+usage goes like this:
+
+ 1. Read /proc/pid/maps to determine which parts of the memory space are
+    mapped to what.
+ 2. Select the maps you are interested in -- all of them, or a particular
+    library, or the stack or the heap, etc.
+ 3. Open /proc/pid/pagemap and seek to the pages you would like to examine.
+ 4. Read a u64 for each page from pagemap.
+ 5. Open /proc/kpagecount and/or /proc/kpageflags.  For each PFN you just
+    read, seek to that entry in the file, and read the data you want.
+
+For example, to find the "unique set size" (USS), which is the amount of
+memory that a process is using that is not shared with any other process,
+you can go through every map in the process, find the PFNs, look those up
+in kpagecount, and tally up the number of pages that are only referenced
+once.
+
+Other notes:
+
+Reading from any of the files will return -EINVAL if you are not starting
+the read on an 8-byte boundary (e.g., if you seeked an odd number of bytes
+into the file), or if the size of the read is not a multiple of 8 bytes.
diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c
index 22d7e3e4d60c..e4230ed16ee7 100644
--- a/Documentation/vm/slabinfo.c
+++ b/Documentation/vm/slabinfo.c
@@ -31,14 +31,14 @@ struct slabinfo {
         int hwcache_align, object_size, objs_per_slab;
         int sanity_checks, slab_size, store_user, trace;
         int order, poison, reclaim_account, red_zone;
-        unsigned long partial, objects, slabs;
+        unsigned long partial, objects, slabs, objects_partial, objects_total;
         unsigned long alloc_fastpath, alloc_slowpath;
         unsigned long free_fastpath, free_slowpath;
         unsigned long free_frozen, free_add_partial, free_remove_partial;
         unsigned long alloc_from_partial, alloc_slab, free_slab, alloc_refill;
         unsigned long cpuslab_flush, deactivate_full, deactivate_empty;
         unsigned long deactivate_to_head, deactivate_to_tail;
-        unsigned long deactivate_remote_frees;
+        unsigned long deactivate_remote_frees, order_fallback;
         int numa[MAX_NODES];
         int numa_partial[MAX_NODES];
 } slabinfo[MAX_SLABS];
@@ -293,7 +293,7 @@ int line = 0;
 void first_line(void)
 {
         if (show_activity)
-                printf("Name                   Objects    Alloc     Free   %%Fast\n");
+                printf("Name                   Objects      Alloc       Free   %%Fast Fallb O\n");
         else
                 printf("Name                   Objects Objsize    Space "
                         "Slabs/Part/Cpu  O/S O %%Fr %%Ef Flg\n");
@@ -540,7 +540,8 @@ void slabcache(struct slabinfo *s)
                 return;
 
         store_size(size_str, slab_size(s));
-        snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs, s->partial, s->cpu_slabs);
+        snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs - s->cpu_slabs,
+                                                s->partial, s->cpu_slabs);
 
         if (!line++)
                 first_line();
@@ -572,11 +573,12 @@ void slabcache(struct slabinfo *s)
                 total_alloc = s->alloc_fastpath + s->alloc_slowpath;
                 total_free = s->free_fastpath + s->free_slowpath;
 
-                printf("%-21s %8ld %8ld %8ld %3ld %3ld \n",
+                printf("%-21s %8ld %10ld %10ld %3ld %3ld %5ld %1d\n",
                         s->name, s->objects,
                         total_alloc, total_free,
                         total_alloc ? (s->alloc_fastpath * 100 / total_alloc) : 0,
-                        total_free ? (s->free_fastpath * 100 / total_free) : 0);
+                        total_free ? (s->free_fastpath * 100 / total_free) : 0,
+                        s->order_fallback, s->order);
         }
         else
                 printf("%-21s %8ld %7d %8s %14s %4d %1d %3ld %3ld %s\n",
@@ -776,7 +778,6 @@ void totals(void)
                 unsigned long used;
                 unsigned long long wasted;
                 unsigned long long objwaste;
-                long long objects_in_partial_slabs;
                 unsigned long percentage_partial_slabs;
                 unsigned long percentage_partial_objs;
 
@@ -790,18 +791,11 @@ void totals(void)
                 wasted = size - used;
                 objwaste = s->slab_size - s->object_size;
 
-                objects_in_partial_slabs = s->objects -
-                        (s->slabs - s->partial - s ->cpu_slabs) *
-                        s->objs_per_slab;
-
-                if (objects_in_partial_slabs < 0)
-                        objects_in_partial_slabs = 0;
-
                 percentage_partial_slabs = s->partial * 100 / s->slabs;
                 if (percentage_partial_slabs > 100)
                         percentage_partial_slabs = 100;
 
-                percentage_partial_objs = objects_in_partial_slabs * 100
+                percentage_partial_objs = s->objects_partial * 100
                                                         / s->objects;
 
                 if (percentage_partial_objs > 100)
@@ -823,8 +817,8 @@ void totals(void)
                         min_objects = s->objects;
                 if (used < min_used)
                         min_used = used;
-                if (objects_in_partial_slabs < min_partobj)
-                        min_partobj = objects_in_partial_slabs;
+                if (s->objects_partial < min_partobj)
+                        min_partobj = s->objects_partial;
                 if (percentage_partial_slabs < min_ppart)
                         min_ppart = percentage_partial_slabs;
                 if (percentage_partial_objs < min_ppartobj)
@@ -848,8 +842,8 @@ void totals(void)
                         max_objects = s->objects;
                 if (used > max_used)
                         max_used = used;
-                if (objects_in_partial_slabs > max_partobj)
-                        max_partobj = objects_in_partial_slabs;
+                if (s->objects_partial > max_partobj)
+                        max_partobj = s->objects_partial;
                 if (percentage_partial_slabs > max_ppart)
                         max_ppart = percentage_partial_slabs;
                 if (percentage_partial_objs > max_ppartobj)
@@ -864,7 +858,7 @@ void totals(void)
 
                 total_objects += s->objects;
                 total_used += used;
-                total_partobj += objects_in_partial_slabs;
+                total_partobj += s->objects_partial;
                 total_ppart += percentage_partial_slabs;
                 total_ppartobj += percentage_partial_objs;
 
@@ -1160,6 +1154,8 @@ void read_slab_dir(void)
                         slab->hwcache_align = get_obj("hwcache_align");
                         slab->object_size = get_obj("object_size");
                         slab->objects = get_obj("objects");
+                        slab->objects_partial = get_obj("objects_partial");
+                        slab->objects_total = get_obj("objects_total");
                         slab->objs_per_slab = get_obj("objs_per_slab");
                         slab->order = get_obj("order");
                         slab->partial = get_obj("partial");
@@ -1193,6 +1189,7 @@ void read_slab_dir(void)
                         slab->deactivate_to_head = get_obj("deactivate_to_head");
                         slab->deactivate_to_tail = get_obj("deactivate_to_tail");
                         slab->deactivate_remote_frees = get_obj("deactivate_remote_frees");
+                        slab->order_fallback = get_obj("order_fallback");
                         chdir("..");
                         if (slab->name[0] == ':')
                                 alias_targets++;
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
new file mode 100644
index 000000000000..17965f927c15
--- /dev/null
+++ b/Documentation/x86/pat.txt
@@ -0,0 +1,100 @@
+
+PAT (Page Attribute Table)
+
+x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
+page level granularity. PAT is complementary to the MTRR settings which allows
+for setting of memory types over physical address ranges. However, PAT is
+more flexible than MTRR due to its capability to set attributes at page level
+and also due to the fact that there are no hardware limitations on number of
+such attribute settings allowed. Added flexibility comes with guidelines for
+not having memory type aliasing for the same physical memory with multiple
+virtual addresses.
+
+PAT allows for different types of memory attributes. The most commonly used
+ones that will be supported at this time are Write-back, Uncached,
+Write-combined and Uncached Minus.
+
+There are many different APIs in the kernel that allows setting of memory
+attributes at the page level. In order to avoid aliasing, these interfaces
+should be used thoughtfully. Below is a table of interfaces available,
+their intended usage and their memory attribute relationships. Internally,
+these APIs use a reserve_memtype()/free_memtype() interface on the physical
+address range to avoid any aliasing.
+
+
+-------------------------------------------------------------------
+API                    |    RAM   |  ACPI,...  |  Reserved/Holes  |
+-----------------------|----------|------------|------------------|
+                       |          |            |                  |
+ioremap                |    --    |    UC      |       UC         |
+                       |          |            |                  |
+ioremap_cache          |    --    |    WB      |       WB         |
+                       |          |            |                  |
+ioremap_nocache        |    --    |    UC      |       UC         |
+                       |          |            |                  |
+ioremap_wc             |    --    |    --      |       WC         |
+                       |          |            |                  |
+set_memory_uc          |    UC    |    --      |       --         |
+ set_memory_wb         |          |            |                  |
+                       |          |            |                  |
+set_memory_wc          |    WC    |    --      |       --         |
+ set_memory_wb         |          |            |                  |
+                       |          |            |                  |
+pci sysfs resource     |    --    |    --      |       UC         |
+                       |          |            |                  |
+pci sysfs resource_wc  |    --    |    --      |       WC         |
+ is IORESOURCE_PREFETCH|          |            |                  |
+                       |          |            |                  |
+pci proc               |    --    |    --      |       UC         |
+ !PCIIOC_WRITE_COMBINE |          |            |                  |
+                       |          |            |                  |
+pci proc               |    --    |    --      |       WC         |
+ PCIIOC_WRITE_COMBINE  |          |            |                  |
+                       |          |            |                  |
+/dev/mem               |    --    |    UC      |       UC         |
+ read-write            |          |            |                  |
+                       |          |            |                  |
+/dev/mem               |    --    |    UC      |       UC         |
+ mmap SYNC flag        |          |            |                  |
+                       |          |            |                  |
+/dev/mem               |    --    |  WB/WC/UC  |    WB/WC/UC      |
+ mmap !SYNC flag       |          |(from exist-|  (from exist-    |
+ and                   |          |  ing alias)|    ing alias)    |
+ any alias to this area|          |            |                  |
+                       |          |            |                  |
+/dev/mem               |    --    |    WB      |       WB         |
+ mmap !SYNC flag       |          |            |                  |
+ no alias to this area |          |            |                  |
+ and                   |          |            |                  |
+ MTRR says WB          |          |            |                  |
+                       |          |            |                  |
+/dev/mem               |    --    |    --      |    UC_MINUS      |
+ mmap !SYNC flag       |          |            |                  |
+ no alias to this area |          |            |                  |
+ and                   |          |            |                  |
+ MTRR says !WB         |          |            |                  |
+                       |          |            |                  |
+-------------------------------------------------------------------
+
+Notes:
+
+-- in the above table mean "Not suggested usage for the API". Some of the --'s
+are strictly enforced by the kernel. Some others are not really enforced
+today, but may be enforced in future.
+
+For ioremap and pci access through /sys or /proc - The actual type returned
+can be more restrictive, in case of any existing aliasing for that address.
+For example: If there is an existing uncached mapping, a new ioremap_wc can
+return uncached mapping in place of write-combine requested.
+
+set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will
+first make a region uc or wc and switch it back to wb after use.
+
+Over time writes to /proc/mtrr will be deprecated in favor of using PAT based
+interfaces. Users writing to /proc/mtrr are suggested to use above interfaces.
+
+Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access
+types.
+
+Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
+
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index 34abae4e9442..b0c7b6c4abda 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -307,3 +307,8 @@ Debugging
                         stuck (default)
 
 Miscellaneous
+
+        nogbpages
+                Do not use GB pages for kernel direct mappings.
+        gbpages
+                Use GB pages for kernel direct mappings.