48 files changed, 2027 insertions, 492 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index f7923a42e76..a82a113b4a4 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
@@ -285,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
diff --git a/Documentation/ABI/stable/sysfs-class-ubi b/Documentation/ABI/stable/sysfs-class-ubi
new file mode 100644
index 00000000000..18d471d9fae
--- /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 00000000000..ceddcff4082
--- /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-ibft b/Documentation/ABI/testing/sysfs-ibft
new file mode 100644
index 00000000000..c2b7d1154be
--- /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/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index dc0f30c3e57..488dd4a4945 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -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>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 2e9d6b41f03..77c42f40be5 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 
@@ -854,7 +854,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 +1238,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 +1656,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/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index d4188d4ff53..eeff19ca831 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
+      structured and introduces the reader to the concept of USB urbs
-      are essential to USB drivers.
+      (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
+      When the driver is unloaded from the system, it needs to deregister
-      itself with the USB subsystem. This is done with the usb_unregister
+      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
+     the data and submits the urb to the USB subsystem.  This can be seen in
-     he following code:
+     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 54835610b3d..0291ade44c1 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
+  - Known regressions in each release are periodically posted to the 
-    tracked at the following URI:
+    linux-kernel mailing list.  The goal is to reduce the length of 
-    http://kernelnewbies.org/known_regressions
+    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.linux-foundation.org/mailman/listinfo/bugme-new
-        http://lists.osdl.org/mailman/listinfo/bugme-janitors
+        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 00000000000..49f43946c6b
--- /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 c93f42a74d7..9a07e38631b 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 6650af43252..6650af43252 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 d2c2e6e2b22..8d4dc6250c5 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 d5da8617010..16c251230c8 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 1fc4e7144dc..9c93a03ea33 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/>
diff --git a/Documentation/arm/Samsung-S3C24XX/NAND.txt b/Documentation/arm/Samsung-S3C24XX/NAND.txt
new file mode 100644
index 00000000000..bc478a3409b
--- /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 c31b76fa66c..d04e1e30c47 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 93f223b9723..4dbb8be1c99 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/cdrom/cdrom-standard.tex b/Documentation/cdrom/cdrom-standard.tex
index c713aeb020c..c06233fe52a 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/cli-sti-removal.txt b/Documentation/cli-sti-removal.txt
index 0223c9d2033..60932b02fcb 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/cpusets.txt b/Documentation/cpusets.txt
index ad2bb3b3acc..aa854b9b18c 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
@@ -497,7 +499,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
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index c09a96b9935..354aec047c0 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -47,7 +47,6 @@
 .mm
 53c700_d.h
 53c8xx_d.h*
-BitKeeper
 COPYING
 CREDITS
 CVS
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README
index 766d320c8eb..e35d8305219 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
+For active users, you are better off using the klibc git
-repositories, at http://klibc.bkbits.net/
+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/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index af0e9393bf6..448729fcaeb 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -261,17 +261,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
@@ -282,6 +271,13 @@ Why:	Not used in-tree. The current out-of-tree users used it to
        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:   /sys/o2cb symlink
@@ -291,3 +287,11 @@ Why:	/sys/fs/o2cb is the proper location for this information - /sys/o2cb
        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>
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt
new file mode 100644
index 00000000000..d0ec45ae4e7
--- /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/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 518ebe609e2..2a99116edc4 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
@@ -2348,4 +2349,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/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index 7fb8e6dc62b..b843743aa0b 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -122,8 +122,7 @@ stop() is the place to free it.
        }
 Finally, the show() function should format the object currently pointed to
-by the iterator for output. It should return zero, or an error code if
+by the iterator for output.  The example module's show() function is:
-something goes wrong. The example module's show() function is:
        static int ct_seq_show(struct seq_file *s, void *v)
        {
@@ -132,6 +131,12 @@ something goes wrong. The example module's show() function is:
                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:
@@ -182,12 +187,18 @@ 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 function for printing filenames:
+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.
+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
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 4598ef7b622..7f27b8f840d 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
+  This allows userspace to do partial reads and forward seeks
-  the entire file at will. 
+  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/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
deleted file mode 100644
index 6865cbe075e..00000000000
--- 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 2de62854f0e..00000000000
--- 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/highuid.txt b/Documentation/highuid.txt
index 76034d9dbfc..6bad6f1d1ca 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/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index 1d247d59ad5..1821c077b43 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/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4b0f1ae31a4..bf6303ec0bd 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -847,6 +847,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
@@ -954,6 +958,8 @@ and is between 256 and 4096 characters. It is defined in the file
        l2cr=           [PPC]
+        l3cr=           [PPC]
        lapic           [X86-32,APIC] Enable the local APIC even if BIOS
                        disabled it.
@@ -1280,8 +1286,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
@@ -1461,10 +1475,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
diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt
index bd450e79755..95070028d15 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/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1f506f7830e..e5a819a4f0c 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/PCI/pci.txt
-            Documentation/DMA-mapping.txt
+            Documentation/PCI/PCI-DMA-mapping.txt
            Documentation/DMA-API.txt
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 461e4f1dbec..421e7d00ffd 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 7b4e8a70882..4cc780024e6 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".
+   - cell-index : the ucc number(1-8), corresponding to UCCx in UM.
-   - device-id : 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";
+                cell-index = <1>;
-                device-id = <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>;
@@ -2817,9 +2826,528 @@ platforms are moved over to use the flattened-device-tree model.
           };
-   More devices will be defined as this spec matures.
+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
+   Example Discovery PHY node:
+     ethernet-phy@1 {
+             device_type = "ethernet-phy";
+             compatible = "broadcom,bcm5421";
+             interrupts = <76>;      /* GPP 12 */
+             interrupt-parent = <&PIC>;
+             reg = <1>;
+     };
+   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
-VII - Specifying interrupt information for devices
+   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 +3433,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/phyp-assisted-dump.txt b/Documentation/powerpc/phyp-assisted-dump.txt
new file mode 100644
index 00000000000..c4682b982a2
--- /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 00000000000..f8e8e95e81f
--- /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 00000000000..1fcd9144537
--- /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 00000000000..843c81eac23
--- /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/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
index 1c6332f4543..14f901f639e 100644
--- a/Documentation/scheduler/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
@@ -1,59 +1,177 @@
+                                Real-Time group scheduling
+                                --------------------------
+CONTENTS
+========
-Real-Time group scheduling.
+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
-The problem space:
-In order to schedule multiple groups of realtime tasks each group must
+1. Overview
-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
+1.1 The problem
-limit.
+---------------
-Now if the audio thread needs to refill the DMA buffer every 0.005s, but
+Realtime scheduling is all about determinism, a group has to be able to rely on
-needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s
+the amount of bandwidth (eg. CPU time) being constant. In order to schedule
-= 0.00015s.
+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
+----------------
-The Interface:
+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.
-system wide:
+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.
-/proc/sys/kernel/sched_rt_period_ms
+Let's consider an example: a frame fixed realtime renderer must deliver 25
-/proc/sys/kernel/sched_rt_runtime_us
+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.
-CONFIG_FAIR_USER_SCHED
+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.
-/sys/kernel/uids/<uid>/cpu_rt_runtime_us
+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.
-or
+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.
-CONFIG_FAIR_CGROUP_SCHED
-/cgroup/<cgroup>/cpu.rt_runtime_us
+2. The Interface
+================
-[ 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 ].
+2.1 System wide settings
+------------------------
-A runtime of -1 specifies runtime == period, ie. no limit.
+The system wide settings are configured under the /proc virtual file system:
-New groups get the period from /proc/sys/kernel/sched_rt_period_us and
+/proc/sys/kernel/sched_rt_period_us:
-a runtime of 0.
+  The scheduling period that is equivalent to 100% CPU bandwidth
-Settings are constrained to:
+/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
-in order to keep the configuration schedulable.
+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/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index e985cf5e041..fd4c32a031c 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
  ------------------
@@ -818,19 +825,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 +884,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 +925,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 +956,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 +999,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 +1038,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 +1621,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/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828
new file mode 100644
index 00000000000..aaae360312e
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.au0828
@@ -0,0 +1,4 @@
+  0 -> Unknown board                            (au0828)
+  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200]
+  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 d97cf7cc608..f32efb6fb12 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 0924e6e142c..929b90c8387 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]
+  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 bc5593bd970..54395734646 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 Real Angel 330                           [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.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 0424901ebc7..44d84dd15ad 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
+ 27 -> Manli MuchTV M-TV002
- 28 -> Manli MuchTV M-TV001/Behold TV 401
+ 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]
@@ -131,3 +131,12 @@
 130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
 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]
diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl
index cced8ac5c54..2cb816047fc 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_le32(0x6002b004);                 # Type
-        write_le64(0x00000000, 0x00002000);     # ID
+        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);