79 files changed, 2869 insertions, 278 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
new file mode 100644
index 00000000000..c2a270b45b0
--- /dev/null
+++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
@@ -0,0 +1,10 @@
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
+Date:           October 2010
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The integer value of this attribute ranges from 0-4.
+                When read, this attribute returns the number of the actual
+                profile. This value is persistent, so its equivalent to the
+                profile that's active when the mouse is powered on next time.
+                When written, this file sets the number of the startup profile
+                and the mouse activates this profile immediately.
+                Please use actual_profile, it does the same thing.
diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block
index 4873c759d53..c1eb41cb987 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -142,3 +142,67 @@ Description:
                with the previous I/O request are enabled. When set to 2,
                all merge tries are disabled. The default value is 0 -
                which enables all types of merge tries.
+What:           /sys/block/<disk>/discard_alignment
+Date:           May 2011
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Devices that support discard functionality may
+                internally allocate space in units that are bigger than
+                the exported logical block size. The discard_alignment
+                parameter indicates how many bytes the beginning of the
+                device is offset from the internal allocation unit's
+                natural alignment.
+What:           /sys/block/<disk>/<partition>/discard_alignment
+Date:           May 2011
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Devices that support discard functionality may
+                internally allocate space in units that are bigger than
+                the exported logical block size. The discard_alignment
+                parameter indicates how many bytes the beginning of the
+                partition is offset from the internal allocation unit's
+                natural alignment.
+What:           /sys/block/<disk>/queue/discard_granularity
+Date:           May 2011
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Devices that support discard functionality may
+                internally allocate space using units that are bigger
+                than the logical block size. The discard_granularity
+                parameter indicates the size of the internal allocation
+                unit in bytes if reported by the device. Otherwise the
+                discard_granularity will be set to match the device's
+                physical block size. A discard_granularity of 0 means
+                that the device does not support discard functionality.
+What:           /sys/block/<disk>/queue/discard_max_bytes
+Date:           May 2011
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Devices that support discard functionality may have
+                internal limits on the number of bytes that can be
+                trimmed or unmapped in a single operation. Some storage
+                protocols also have inherent limits on the number of
+                blocks that can be described in a single command. The
+                discard_max_bytes parameter is set by the device driver
+                to the maximum number of bytes that can be discarded in
+                a single operation. Discard requests issued to the
+                device must not exceed this limit. A discard_max_bytes
+                value of 0 means that the device does not support
+                discard functionality.
+What:           /sys/block/<disk>/queue/discard_zeroes_data
+Date:           May 2011
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Devices that support discard functionality may return
+                stale or random data when a previously discarded block
+                is read back. This can cause problems if the filesystem
+                expects discarded blocks to be explicitly cleared. If a
+                device reports that it deterministically returns zeroes
+                when a discarded area is read the discard_zeroes_data
+                parameter will be set to one. Otherwise it will be 0 and
+                the result of reading a discarded area is undefined.
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 36bf454ba85..349ecf26ce1 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -74,6 +74,15 @@ Description:
                hot-remove the PCI device and any of its children.
                Depends on CONFIG_HOTPLUG.
+What:           /sys/bus/pci/devices/.../pci_bus/.../rescan
+Date:           May 2011
+Contact:        Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+                Writing a non-zero value to this attribute will
+                force a rescan of the bus and all child buses,
+                and re-discover devices removed earlier from this
+                part of the device tree.  Depends on CONFIG_HOTPLUG.
 What:           /sys/bus/pci/devices/.../rescan
 Date:           January 2009
 Contact:        Linux PCI developers <linux-pci@vger.kernel.org>
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
index 326e05452da..c1b53b8bc2a 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
@@ -1,9 +1,12 @@
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
 Date:           October 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:    When read, this file returns the number of the actual profile in
+Description:    The integer value of this attribute ranges from 0-4.
-                range 0-4.
+                When read, this attribute returns the number of the actual
-                This file is readonly.
+                profile. This value is persistent, so its equivalent to the
+                profile that's active when the mouse is powered on next time.
+                When written, this file sets the number of the startup profile
+                and the mouse activates this profile immediately.
 Users:          http://roccat.sourceforge.net
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
@@ -89,16 +92,6 @@ Description:	The mouse has a tracking- and a distance-control-unit. These
                This file is writeonly.
 Users:          http://roccat.sourceforge.net
-What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
-Date:           October 2010
-Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
-Description:    The integer value of this attribute ranges from 0-4.
-                When read, this attribute returns the number of the profile
-                that's active when the mouse is powered on.
-                When written, this file sets the number of the startup profile
-                and the mouse activates this profile immediately.
-Users:          http://roccat.sourceforge.net
 What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
 Date:           October 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp
new file mode 100644
index 00000000000..d40d2b55050
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ptp
@@ -0,0 +1,98 @@
+What:           /sys/class/ptp/
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This directory contains files and directories
+                providing a standardized interface to the ancillary
+                features of PTP hardware clocks.
+What:           /sys/class/ptp/ptpN/
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This directory contains the attributes of the Nth PTP
+                hardware clock registered into the PTP class driver
+                subsystem.
+What:           /sys/class/ptp/ptpN/clock_name
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the name of the PTP hardware clock
+                as a human readable string.
+What:           /sys/class/ptp/ptpN/max_adjustment
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the PTP hardware clock's maximum
+                frequency adjustment value (a positive integer) in
+                parts per billion.
+What:           /sys/class/ptp/ptpN/n_alarms
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the number of periodic or one shot
+                alarms offer by the PTP hardware clock.
+What:           /sys/class/ptp/ptpN/n_external_timestamps
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the number of external timestamp
+                channels offered by the PTP hardware clock.
+What:           /sys/class/ptp/ptpN/n_periodic_outputs
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the number of programmable periodic
+                output channels offered by the PTP hardware clock.
+What:           /sys/class/ptp/ptpN/pps_avaiable
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file indicates whether the PTP hardware clock
+                supports a Pulse Per Second to the host CPU. Reading
+                "1" means that the PPS is supported, while "0" means
+                not supported.
+What:           /sys/class/ptp/ptpN/extts_enable
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This write-only file enables or disables external
+                timestamps. To enable external timestamps, write the
+                channel index followed by a "1" into the file.
+                To disable external timestamps, write the channel
+                index followed by a "0" into the file.
+What:           /sys/class/ptp/ptpN/fifo
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file provides timestamps on external events, in
+                the form of three integers: channel index, seconds,
+                and nanoseconds.
+What:           /sys/class/ptp/ptpN/period
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This write-only file enables or disables periodic
+                outputs. To enable a periodic output, write five
+                integers into the file: channel index, start time
+                seconds, start time nanoseconds, period seconds, and
+                period nanoseconds. To disable a periodic output, set
+                all the seconds and nanoseconds values to zero.
+What:           /sys/class/ptp/ptpN/pps_enable
+Date:           September 2010
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This write-only file enables or disables delivery of
+                PPS events to the Linux PPS subsystem. To enable PPS
+                events, write a "1" into the file. To disable events,
+                write a "0" into the file.
diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore
index c6def352fe3..679034cbd68 100644
--- a/Documentation/DocBook/.gitignore
+++ b/Documentation/DocBook/.gitignore
@@ -8,3 +8,4 @@
 *.dvi
 *.log
 *.out
+media/
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 8436b018c28..3cebfa0d161 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -73,7 +73,7 @@ installmandocs: mandocs
 ###
 #External programs used
 KERNELDOC = $(srctree)/scripts/kernel-doc
-DOCPROC   = $(objtree)/scripts/basic/docproc
+DOCPROC   = $(objtree)/scripts/docproc
 XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
diff --git a/Documentation/DocBook/dvb/dvbapi.xml b/Documentation/DocBook/dvb/dvbapi.xml
index ad8678d4891..9fad86ce7f5 100644
--- a/Documentation/DocBook/dvb/dvbapi.xml
+++ b/Documentation/DocBook/dvb/dvbapi.xml
@@ -35,6 +35,14 @@
 <revhistory>
 <!-- Put document revisions here, newest first. -->
 <revision>
+        <revnumber>2.0.4</revnumber>
+        <date>2011-05-06</date>
+        <authorinitials>mcc</authorinitials>
+        <revremark>
+                Add more information about DVB APIv5, better describing the frontend GET/SET props ioctl's.
+        </revremark>
+</revision>
+<revision>
        <revnumber>2.0.3</revnumber>
        <date>2010-07-03</date>
        <authorinitials>mcc</authorinitials>
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml
index 97f397e2fb3..52d5e3c7cf6 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -1,6 +1,327 @@
-<section id="FE_GET_PROPERTY">
+<section id="FE_GET_SET_PROPERTY">
 <title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
+<programlisting>
+/* Reserved fields should be set to 0 */
+struct dtv_property {
+        __u32 cmd;
+        union {
+                __u32 data;
+                struct {
+                        __u8 data[32];
+                        __u32 len;
+                        __u32 reserved1[3];
+                        void *reserved2;
+                } buffer;
+        } u;
+        int result;
+} __attribute__ ((packed));
+/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
+#define DTV_IOCTL_MAX_MSGS 64
+struct dtv_properties {
+        __u32 num;
+        struct dtv_property *props;
+};
+</programlisting>
+<section id="FE_GET_PROPERTY">
+<title>FE_GET_PROPERTY</title>
+<para>DESCRIPTION
+</para>
+<informaltable><tgroup cols="1"><tbody><row><entry
+ align="char">
+<para>This ioctl call returns one or more frontend properties. This call only
+ requires read-only access to the device.</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>SYNOPSIS
+</para>
+<informaltable><tgroup cols="1"><tbody><row><entry
+ align="char">
+<para>int ioctl(int fd, int request = <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>,
+ dtv_properties &#x22C6;props);</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>PARAMETERS
+</para>
+<informaltable><tgroup cols="2"><tbody><row><entry align="char">
+<para>int fd</para>
+</entry><entry
+ align="char">
+<para>File descriptor returned by a previous call to open().</para>
+</entry>
+ </row><row><entry
+ align="char">
+<para>int num</para>
+</entry><entry
+ align="char">
+<para>Equals <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> for this command.</para>
+</entry>
+ </row><row><entry
+ align="char">
+<para>struct dtv_property *props</para>
+</entry><entry
+ align="char">
+<para>Points to the location where the front-end property commands are stored.</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>ERRORS</para>
+<informaltable><tgroup cols="2"><tbody><row>
+  <entry align="char"><para>EINVAL</para></entry>
+  <entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
+ </row><row>
+  <entry align="char"><para>ENOMEM</para></entry>
+  <entry align="char"><para>Out of memory.</para></entry>
+ </row><row>
+  <entry align="char"><para>EFAULT</para></entry>
+  <entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
+ </row><row>
+  <entry align="char"><para>EOPNOTSUPP</para></entry>
+  <entry align="char"><para>Property type not supported.</para></entry>
+ </row></tbody></tgroup></informaltable>
+</section>
+<section id="FE_SET_PROPERTY">
+<title>FE_SET_PROPERTY</title>
+<para>DESCRIPTION
+</para>
+<informaltable><tgroup cols="1"><tbody><row><entry
+ align="char">
+<para>This ioctl call sets one or more frontend properties. This call only
+ requires read-only access to the device.</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>SYNOPSIS
+</para>
+<informaltable><tgroup cols="1"><tbody><row><entry
+ align="char">
+<para>int ioctl(int fd, int request = <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
+ dtv_properties &#x22C6;props);</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>PARAMETERS
+</para>
+<informaltable><tgroup cols="2"><tbody><row><entry align="char">
+<para>int fd</para>
+</entry><entry
+ align="char">
+<para>File descriptor returned by a previous call to open().</para>
+</entry>
+ </row><row><entry
+ align="char">
+<para>int num</para>
+</entry><entry
+ align="char">
+<para>Equals <link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link> for this command.</para>
+</entry>
+ </row><row><entry
+ align="char">
+<para>struct dtv_property *props</para>
+</entry><entry
+ align="char">
+<para>Points to the location where the front-end property commands are stored.</para>
+</entry>
+ </row></tbody></tgroup></informaltable>
+<para>ERRORS
+</para>
+<informaltable><tgroup cols="2"><tbody><row>
+  <entry align="char"><para>EINVAL</para></entry>
+  <entry align="char"><para>Invalid parameter(s) received or number of parameters out of the range.</para></entry>
+ </row><row>
+  <entry align="char"><para>ENOMEM</para></entry>
+  <entry align="char"><para>Out of memory.</para></entry>
+ </row><row>
+  <entry align="char"><para>EFAULT</para></entry>
+  <entry align="char"><para>Failure while copying data from/to userspace.</para></entry>
+ </row><row>
+  <entry align="char"><para>EOPNOTSUPP</para></entry>
+  <entry align="char"><para>Property type not supported.</para></entry>
+ </row></tbody></tgroup></informaltable>
+</section>
+<para>
+On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
+the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to
+get/set up to 64 properties. The actual meaning of each property is described on the next sections.
+</para>
+<para>The Available frontend property types are:</para>
+<programlisting>
+#define DTV_UNDEFINED           0
+#define DTV_TUNE                1
+#define DTV_CLEAR               2
+#define DTV_FREQUENCY           3
+#define DTV_MODULATION          4
+#define DTV_BANDWIDTH_HZ        5
+#define DTV_INVERSION           6
+#define DTV_DISEQC_MASTER       7
+#define DTV_SYMBOL_RATE         8
+#define DTV_INNER_FEC           9
+#define DTV_VOLTAGE             10
+#define DTV_TONE                11
+#define DTV_PILOT               12
+#define DTV_ROLLOFF             13
+#define DTV_DISEQC_SLAVE_REPLY  14
+#define DTV_FE_CAPABILITY_COUNT 15
+#define DTV_FE_CAPABILITY       16
+#define DTV_DELIVERY_SYSTEM     17
+#define DTV_ISDBT_PARTIAL_RECEPTION     18
+#define DTV_ISDBT_SOUND_BROADCASTING    19
+#define DTV_ISDBT_SB_SUBCHANNEL_ID      20
+#define DTV_ISDBT_SB_SEGMENT_IDX        21
+#define DTV_ISDBT_SB_SEGMENT_COUNT      22
+#define DTV_ISDBT_LAYERA_FEC                    23
+#define DTV_ISDBT_LAYERA_MODULATION             24
+#define DTV_ISDBT_LAYERA_SEGMENT_COUNT          25
+#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING      26
+#define DTV_ISDBT_LAYERB_FEC                    27
+#define DTV_ISDBT_LAYERB_MODULATION             28
+#define DTV_ISDBT_LAYERB_SEGMENT_COUNT          29
+#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING      30
+#define DTV_ISDBT_LAYERC_FEC                    31
+#define DTV_ISDBT_LAYERC_MODULATION             32
+#define DTV_ISDBT_LAYERC_SEGMENT_COUNT          33
+#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING      34
+#define DTV_API_VERSION         35
+#define DTV_CODE_RATE_HP        36
+#define DTV_CODE_RATE_LP        37
+#define DTV_GUARD_INTERVAL      38
+#define DTV_TRANSMISSION_MODE   39
+#define DTV_HIERARCHY           40
+#define DTV_ISDBT_LAYER_ENABLED 41
+#define DTV_ISDBS_TS_ID         42
+</programlisting>
+<section id="fe_property_common">
+        <title>Parameters that are common to all Digital TV standards</title>
+        <section id="DTV_FREQUENCY">
+                <title><constant>DTV_FREQUENCY</constant></title>
+                <para>Central frequency of the channel, in HZ.</para>
+                <para>Notes:</para>
+                <para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
+                        E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
+                        the channel which is 6MHz.</para>
+                <para>2)As in ISDB-Tsb the channel consists of only one or three segments the
+                        frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
+                        central frequency of the channel is expected.</para>
+        </section>
+        <section id="DTV_BANDWIDTH_HZ">
+                <title><constant>DTV_BANDWIDTH_HZ</constant></title>
+                <para>Bandwidth for the channel, in HZ.</para>
+                <para>Possible values:
+                        <constant>1712000</constant>,
+                        <constant>5000000</constant>,
+                        <constant>6000000</constant>,
+                        <constant>7000000</constant>,
+                        <constant>8000000</constant>,
+                        <constant>10000000</constant>.
+                </para>
+                <para>Notes:</para>
+                <para>1) For ISDB-T it should be always 6000000Hz (6MHz)</para>
+                <para>2) For ISDB-Tsb it can vary depending on the number of connected segments</para>
+                <para>3) Bandwidth doesn't apply for DVB-C transmissions, as the bandwidth
+                         for DVB-C depends on the symbol rate</para>
+                <para>4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
+                        other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
+                        DTV_ISDBT_SB_SEGMENT_COUNT).</para>
+                <para>5) DVB-T supports 6, 7 and 8MHz.</para>
+                <para>6) In addition, DVB-T2 supports 1.172, 5 and 10MHz.</para>
+        </section>
+        <section id="DTV_DELIVERY_SYSTEM">
+                <title><constant>DTV_DELIVERY_SYSTEM</constant></title>
+                <para>Specifies the type of Delivery system</para>
+                <para>Possible values: </para>
+<programlisting>
+typedef enum fe_delivery_system {
+        SYS_UNDEFINED,
+        SYS_DVBC_ANNEX_AC,
+        SYS_DVBC_ANNEX_B,
+        SYS_DVBT,
+        SYS_DSS,
+        SYS_DVBS,
+        SYS_DVBS2,
+        SYS_DVBH,
+        SYS_ISDBT,
+        SYS_ISDBS,
+        SYS_ISDBC,
+        SYS_ATSC,
+        SYS_ATSCMH,
+        SYS_DMBTH,
+        SYS_CMMB,
+        SYS_DAB,
+        SYS_DVBT2,
+} fe_delivery_system_t;
+</programlisting>
+        </section>
+        <section id="DTV_TRANSMISSION_MODE">
+                <title><constant>DTV_TRANSMISSION_MODE</constant></title>
+                <para>Specifies the number of carriers used by the standard</para>
+                <para>Possible values are:</para>
+<programlisting>
+typedef enum fe_transmit_mode {
+        TRANSMISSION_MODE_2K,
+        TRANSMISSION_MODE_8K,
+        TRANSMISSION_MODE_AUTO,
+        TRANSMISSION_MODE_4K,
+        TRANSMISSION_MODE_1K,
+        TRANSMISSION_MODE_16K,
+        TRANSMISSION_MODE_32K,
+} fe_transmit_mode_t;
+</programlisting>
+                <para>Notes:</para>
+                <para>1) ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
+                        'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
+                <para>2) If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
+                        hardware will try to find the correct FFT-size (if capable) and will
+                        use TMCC to fill in the missing parameters.</para>
+                <para>3) DVB-T specifies 2K and 8K as valid sizes.</para>
+                <para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para>
+        </section>
+        <section id="DTV_GUARD_INTERVAL">
+                <title><constant>DTV_GUARD_INTERVAL</constant></title>
+                <para>Possible values are:</para>
+<programlisting>
+typedef enum fe_guard_interval {
+        GUARD_INTERVAL_1_32,
+        GUARD_INTERVAL_1_16,
+        GUARD_INTERVAL_1_8,
+        GUARD_INTERVAL_1_4,
+        GUARD_INTERVAL_AUTO,
+        GUARD_INTERVAL_1_128,
+        GUARD_INTERVAL_19_128,
+        GUARD_INTERVAL_19_256,
+} fe_guard_interval_t;
+</programlisting>
+                <para>Notes:</para>
+                <para>1) If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
+                        try to find the correct guard interval (if capable) and will use TMCC to fill
+                        in the missing parameters.</para>
+                <para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para>
+        </section>
+</section>
 <section id="isdbt">
        <title>ISDB-T frontend</title>
        <para>This section describes shortly what are the possible parameters in the Linux
@@ -32,73 +353,6 @@
        <para>Parameters used by ISDB-T and ISDB-Tsb.</para>
-        <section id="isdbt-parms">
-                <title>Parameters that are common with DVB-T and ATSC</title>
-                <section id="isdbt-freq">
-                        <title><constant>DTV_FREQUENCY</constant></title>
-                        <para>Central frequency of the channel.</para>
-                        <para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a
-                                valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
-                                the channel which is 6MHz.</para>
-                        <para>As in ISDB-Tsb the channel consists of only one or three segments the
-                                frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
-                                central frequency of the channel is expected.</para>
-                </section>
-                <section id="isdbt-bw">
-                        <title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title>
-                        <para>Possible values:</para>
-                        <para>For ISDB-T it should be always 6000000Hz (6MHz)</para>
-                        <para>For ISDB-Tsb it can vary depending on the number of connected segments</para>
-                        <para>Note: Hardware specific values might be given here, but standard
-                                applications should not bother to set a value to this field as
-                                standard demods are ignoring it anyway.</para>
-                        <para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from
-                                other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
-                                DTV_ISDBT_SB_SEGMENT_COUNT).</para>
-                </section>
-                <section id="isdbt-delivery-sys">
-                        <title><constant>DTV_DELIVERY_SYSTEM</constant></title>
-                        <para>Possible values: <constant>SYS_ISDBT</constant></para>
-                </section>
-                <section id="isdbt-tx-mode">
-                        <title><constant>DTV_TRANSMISSION_MODE</constant></title>
-                        <para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called
-                                'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para>
-                        <para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>,
-                                <constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para>
-                        <para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the
-                                hardware will try to find the correct FFT-size (if capable) and will
-                                use TMCC to fill in the missing parameters.</para>
-                        <para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para>
-                </section>
-                <section id="isdbt-guard-interval">
-                        <title><constant>DTV_GUARD_INTERVAL</constant></title>
-                        <para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>,
-                                <constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para>
-                        <para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will
-                                try to find the correct guard interval (if capable) and will use TMCC to fill
-                                in the missing parameters.</para>
-                </section>
-        </section>
        <section id="isdbt-new-parms">
                <title>ISDB-T only parameters</title>
@@ -314,5 +568,20 @@
                        </section>
                </section>
        </section>
+        <section id="dvbt2-params">
+                <title>DVB-T2 parameters</title>
+                
+                <para>This section covers parameters that apply only to the DVB-T2 delivery method. DVB-T2
+                        support is currently in the early stages development so expect this section to grow
+                        and become more detailed with time.</para>
+                <section id="dvbt2-plp-id">
+                        <title><constant>DTV_DVBT2_PLP_ID</constant></title>
+                        <para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of
+                                many data types via a single multiplex. The API will soon support this
+                                at which point this section will be expanded.</para>
+                </section>
+        </section>
 </section>
 </section>
diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml
index d08e0d40141..d792f789ad3 100644
--- a/Documentation/DocBook/dvb/frontend.h.xml
+++ b/Documentation/DocBook/dvb/frontend.h.xml
@@ -176,14 +176,20 @@ typedef enum fe_transmit_mode {
        TRANSMISSION_MODE_2K,
        TRANSMISSION_MODE_8K,
        TRANSMISSION_MODE_AUTO,
-        TRANSMISSION_MODE_4K
+        TRANSMISSION_MODE_4K,
+        TRANSMISSION_MODE_1K,
+        TRANSMISSION_MODE_16K,
+        TRANSMISSION_MODE_32K,
 } fe_transmit_mode_t;
 typedef enum fe_bandwidth {
        BANDWIDTH_8_MHZ,
        BANDWIDTH_7_MHZ,
        BANDWIDTH_6_MHZ,
-        BANDWIDTH_AUTO
+        BANDWIDTH_AUTO,
+        BANDWIDTH_5_MHZ,
+        BANDWIDTH_10_MHZ,
+        BANDWIDTH_1_712_MHZ,
 } fe_bandwidth_t;
@@ -192,7 +198,10 @@ typedef enum fe_guard_interval {
        GUARD_INTERVAL_1_16,
        GUARD_INTERVAL_1_8,
        GUARD_INTERVAL_1_4,
-        GUARD_INTERVAL_AUTO
+        GUARD_INTERVAL_AUTO,
+        GUARD_INTERVAL_1_128,
+        GUARD_INTERVAL_19_128,
+        GUARD_INTERVAL_19_256,
 } fe_guard_interval_t;
@@ -306,7 +315,9 @@ struct dvb_frontend_event {
 #define DTV_ISDBS_TS_ID         42
-#define DTV_MAX_COMMAND                         DTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID        43
+#define DTV_MAX_COMMAND                         DTV_DVBT2_PLP_ID
 typedef enum fe_pilot {
        PILOT_ON,
@@ -338,6 +349,7 @@ typedef enum fe_delivery_system {
        SYS_DMBTH,
        SYS_CMMB,
        SYS_DAB,
+        SYS_DVBT2,
 } fe_delivery_system_t;
 struct dtv_cmds_h {
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl
index fea63b45471..c8abb23ef1e 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -270,6 +270,7 @@
 <!ENTITY sub-write SYSTEM "v4l/func-write.xml">
 <!ENTITY sub-io SYSTEM "v4l/io.xml">
 <!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml">
+<!ENTITY sub-m420 SYSTEM "v4l/pixfmt-m420.xml">
 <!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml">
 <!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
 <!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml">
@@ -295,6 +296,7 @@
 <!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
 <!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
 <!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
+<!ENTITY sub-y10b SYSTEM "v4l/pixfmt-y10b.xml">
 <!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
 <!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
 <!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
diff --git a/Documentation/DocBook/v4l/pixfmt-m420.xml b/Documentation/DocBook/v4l/pixfmt-m420.xml
new file mode 100644
index 00000000000..ce4bc019e5c
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-m420.xml
@@ -0,0 +1,147 @@
+    <refentry id="V4L2-PIX-FMT-M420">
+      <refmeta>
+        <refentrytitle>V4L2_PIX_FMT_M420 ('M420')</refentrytitle>
+        &manvol;
+      </refmeta>
+      <refnamediv>
+        <refname><constant>V4L2_PIX_FMT_M420</constant></refname>
+        <refpurpose>Format with &frac12; horizontal and vertical chroma
+        resolution, also known as YUV 4:2:0. Hybrid plane line-interleaved
+        layout.</refpurpose>
+      </refnamediv>
+      <refsect1>
+        <title>Description</title>
+        <para>M420 is a YUV format with &frac12; horizontal and vertical chroma
+        subsampling (YUV 4:2:0). Pixels are organized as interleaved luma and
+        chroma planes. Two lines of luma data are followed by one line of chroma
+        data.</para>
+        <para>The luma plane has one byte per pixel. The chroma plane contains
+        interleaved CbCr pixels subsampled by &frac12; in the horizontal and
+        vertical directions. Each CbCr pair belongs to four pixels. For example,
+Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
+Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
+Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.</para>
+        <para>All line lengths are identical: if the Y lines include pad bytes
+        so do the CbCr lines.</para>
+        <example>
+          <title><constant>V4L2_PIX_FMT_M420</constant> 4 &times; 4
+pixel image</title>
+          <formalpara>
+            <title>Byte Order.</title>
+            <para>Each cell is one byte.
+                <informaltable frame="none">
+                <tgroup cols="5" align="center">
+                  <colspec align="left" colwidth="2*" />
+                  <tbody valign="top">
+                    <row>
+                      <entry>start&nbsp;+&nbsp;0:</entry>
+                      <entry>Y'<subscript>00</subscript></entry>
+                      <entry>Y'<subscript>01</subscript></entry>
+                      <entry>Y'<subscript>02</subscript></entry>
+                      <entry>Y'<subscript>03</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;4:</entry>
+                      <entry>Y'<subscript>10</subscript></entry>
+                      <entry>Y'<subscript>11</subscript></entry>
+                      <entry>Y'<subscript>12</subscript></entry>
+                      <entry>Y'<subscript>13</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;8:</entry>
+                      <entry>Cb<subscript>00</subscript></entry>
+                      <entry>Cr<subscript>00</subscript></entry>
+                      <entry>Cb<subscript>01</subscript></entry>
+                      <entry>Cr<subscript>01</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;16:</entry>
+                      <entry>Y'<subscript>20</subscript></entry>
+                      <entry>Y'<subscript>21</subscript></entry>
+                      <entry>Y'<subscript>22</subscript></entry>
+                      <entry>Y'<subscript>23</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;20:</entry>
+                      <entry>Y'<subscript>30</subscript></entry>
+                      <entry>Y'<subscript>31</subscript></entry>
+                      <entry>Y'<subscript>32</subscript></entry>
+                      <entry>Y'<subscript>33</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;24:</entry>
+                      <entry>Cb<subscript>10</subscript></entry>
+                      <entry>Cr<subscript>10</subscript></entry>
+                      <entry>Cb<subscript>11</subscript></entry>
+                      <entry>Cr<subscript>11</subscript></entry>
+                    </row>
+                  </tbody>
+                </tgroup>
+                </informaltable>
+              </para>
+          </formalpara>
+          <formalpara>
+            <title>Color Sample Location.</title>
+            <para>
+                <informaltable frame="none">
+                <tgroup cols="7" align="center">
+                  <tbody valign="top">
+                    <row>
+                      <entry></entry>
+                      <entry>0</entry><entry></entry><entry>1</entry><entry></entry>
+                      <entry>2</entry><entry></entry><entry>3</entry>
+                    </row>
+                    <row>
+                      <entry>0</entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry>
+                    </row>
+                    <row>
+                      <entry></entry>
+                      <entry></entry><entry>C</entry><entry></entry><entry></entry>
+                      <entry></entry><entry>C</entry><entry></entry>
+                    </row>
+                    <row>
+                      <entry>1</entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry>
+                    </row>
+                    <row>
+                      <entry></entry>
+                    </row>
+                    <row>
+                      <entry>2</entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry>
+                    </row>
+                    <row>
+                      <entry></entry>
+                      <entry></entry><entry>C</entry><entry></entry><entry></entry>
+                      <entry></entry><entry>C</entry><entry></entry>
+                    </row>
+                    <row>
+                      <entry>3</entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
+                      <entry>Y</entry><entry></entry><entry>Y</entry>
+                    </row>
+                  </tbody>
+                </tgroup>
+                </informaltable>
+              </para>
+          </formalpara>
+        </example>
+      </refsect1>
+    </refentry>
+  <!--
+Local Variables:
+mode: sgml
+sgml-parent-document: "pixfmt.sgml"
+indent-tabs-mode: nil
+End:
+  -->
diff --git a/Documentation/DocBook/v4l/pixfmt-y10b.xml b/Documentation/DocBook/v4l/pixfmt-y10b.xml
new file mode 100644
index 00000000000..adb0ad808c9
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y10b.xml
@@ -0,0 +1,43 @@
+<refentry id="V4L2-PIX-FMT-Y10BPACK">
+  <refmeta>
+    <refentrytitle>V4L2_PIX_FMT_Y10BPACK ('Y10B')</refentrytitle>
+    &manvol;
+  </refmeta>
+  <refnamediv>
+    <refname><constant>V4L2_PIX_FMT_Y10BPACK</constant></refname>
+    <refpurpose>Grey-scale image as a bit-packed array</refpurpose>
+  </refnamediv>
+  <refsect1>
+    <title>Description</title>
+    <para>This is a packed grey-scale image format with a depth of 10 bits per
+      pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel,
+      with no padding between them and with the most significant bits coming
+      first from the left.</para>
+    <example>
+      <title><constant>V4L2_PIX_FMT_Y10BPACK</constant> 4 pixel data stream taking 5 bytes</title>
+      <formalpara>
+        <title>Bit-packed representation</title>
+        <para>pixels cross the byte boundary and have a ratio of 5 bytes for each 4
+          pixels.
+          <informaltable frame="all">
+            <tgroup cols="5" align="center">
+              <colspec align="left" colwidth="2*" />
+              <tbody valign="top">
+                <row>
+                  <entry>Y'<subscript>00[9:2]</subscript></entry>
+                  <entry>Y'<subscript>00[1:0]</subscript>Y'<subscript>01[9:4]</subscript></entry>
+                  <entry>Y'<subscript>01[3:0]</subscript>Y'<subscript>02[9:6]</subscript></entry>
+                  <entry>Y'<subscript>02[5:0]</subscript>Y'<subscript>03[9:8]</subscript></entry>
+                  <entry>Y'<subscript>03[7:0]</subscript></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </para>
+      </formalpara>
+    </example>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml
index 40af4beb48b..dbfe3b08435 100644
--- a/Documentation/DocBook/v4l/pixfmt.xml
+++ b/Documentation/DocBook/v4l/pixfmt.xml
@@ -697,6 +697,7 @@ information.</para>
    &sub-grey;
    &sub-y10;
    &sub-y12;
+    &sub-y10b;
    &sub-y16;
    &sub-yuyv;
    &sub-uyvy;
@@ -712,6 +713,7 @@ information.</para>
    &sub-nv12m;
    &sub-nv12mt;
    &sub-nv16;
+    &sub-m420;
  </section>
  <section>
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml
index d7ccd25edcc..a26b10c0785 100644
--- a/Documentation/DocBook/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
@@ -2522,5 +2522,51 @@
        </tgroup>
      </table>
    </section>
+    <section>
+      <title>JPEG Compressed Formats</title>
+      <para>Those data formats consist of an ordered sequence of 8-bit bytes
+        obtained from JPEG compression process. Additionally to the
+        <constant>_JPEG</constant> prefix the format code is made of
+        the following information.
+        <itemizedlist>
+          <listitem>The number of bus samples per entropy encoded byte.</listitem>
+          <listitem>The bus width.</listitem>
+        </itemizedlist>
+        <para>For instance, for a JPEG baseline process and an 8-bit bus width
+          the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
+        </para>
+      </para>
+      <para>The following table lists existing JPEG compressed formats.</para>
+      <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-jpeg">
+        <title>JPEG Formats</title>
+        <tgroup cols="3">
+          <colspec colname="id" align="left" />
+          <colspec colname="code" align="left"/>
+          <colspec colname="remarks" align="left"/>
+          <thead>
+            <row>
+              <entry>Identifier</entry>
+              <entry>Code</entry>
+              <entry>Remarks</entry>
+            </row>
+          </thead>
+          <tbody valign="top">
+            <row id="V4L2-MBUS-FMT-JPEG-1X8">
+              <entry>V4L2_MBUS_FMT_JPEG_1X8</entry>
+              <entry>0x4001</entry>
+              <entry>Besides of its usage for the parallel bus this format is
+                recommended for transmission of JPEG data over MIPI CSI bus
+                using the User Defined 8-bit Data types.
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+    </section>
  </section>
 </section>
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2ee98..c50536a4f59 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -311,6 +311,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link>     v4l2_fourcc('Y', '1', '0', ' ') /* 10  Greyscale     */
 #define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link>     v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale     */
+/* Grey bit-packed formats */
+#define <link linkend="V4L2-PIX-FMT-Y10BPACK">V4L2_PIX_FMT_Y10BPACK</link>    v4l2_fourcc('Y', '1', '0', 'B') /* 10  Greyscale bit-packed */
 /* Palette formats */
 #define <link linkend="V4L2-PIX-FMT-PAL8">V4L2_PIX_FMT_PAL8</link>    v4l2_fourcc('P', 'A', 'L', '8') /*  8  8-bit palette */
@@ -333,6 +336,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-YUV420">V4L2_PIX_FMT_YUV420</link>  v4l2_fourcc('Y', 'U', '1', '2') /* 12  YUV 4:2:0     */
 #define <link linkend="V4L2-PIX-FMT-HI240">V4L2_PIX_FMT_HI240</link>   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit color   */
 #define <link linkend="V4L2-PIX-FMT-HM12">V4L2_PIX_FMT_HM12</link>    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16 macroblocks */
+#define <link linkend="V4L2-PIX-FMT-M420">V4L2_PIX_FMT_M420</link>    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
 /* two planes -- one Y, one Cr + Cb interleaved  */
 #define <link linkend="V4L2-PIX-FMT-NV12">V4L2_PIX_FMT_NV12</link>    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 365bda9a0d9..81bc1a9ab9d 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -209,7 +209,7 @@ tools.  One such tool that is particularly recommended is the Linux
 Cross-Reference project, which is able to present source code in a
 self-referential, indexed webpage format. An excellent up-to-date
 repository of the kernel code may be found at:
-        http://users.sosdg.org/~qiyong/lxr/
+        http://lxr.linux.no/+trees
 The development process
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt
index b4a615b7840..7890fae1852 100644
--- a/Documentation/IRQ-affinity.txt
+++ b/Documentation/IRQ-affinity.txt
@@ -4,10 +4,11 @@ ChangeLog:
 SMP IRQ affinity
-/proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted
+/proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify
-for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed
+which target CPUs are permitted for a given IRQ source.  It's a bitmask
-to turn off all CPUs, and if an IRQ controller does not support IRQ
+(smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs.  It's not
-affinity then the value will not change from the default 0xffffffff.
+allowed to turn off all CPUs, and if an IRQ controller does not support
+IRQ affinity then the value will not change from the default of all cpus.
 /proc/irq/default_smp_affinity specifies default affinity mask that applies
 to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask
@@ -54,3 +55,11 @@ round-trip min/avg/max = 0.1/0.5/585.4 ms
 This time around IRQ44 was delivered only to the last four processors.
 i.e counters for the CPU0-3 did not change.
+Here is an example of limiting that same irq (44) to cpus 1024 to 1031:
+[root@moon 44]# echo 1024-1031 > smp_affinity
+[root@moon 44]# cat smp_affinity
+1024-1031
+Note that to do this with a bitmask would require 32 bitmasks of zero
+to follow the pertinent one.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index e439cd0d337..569f3532e13 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -714,10 +714,11 @@ Jeff Garzik, "Linux kernel patch submission format".
  <http://linux.yyz.us/patch-format.html>
 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
-  <http://www.kroah.com/log/2005/03/31/>
+  <http://www.kroah.com/log/linux/maintainer.html>
-  <http://www.kroah.com/log/2005/07/08/>
+  <http://www.kroah.com/log/linux/maintainer-02.html>
-  <http://www.kroah.com/log/2005/10/19/>
+  <http://www.kroah.com/log/linux/maintainer-03.html>
-  <http://www.kroah.com/log/2006/01/11/>
+  <http://www.kroah.com/log/linux/maintainer-04.html>
+  <http://www.kroah.com/log/linux/maintainer-05.html>
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
  <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
diff --git a/Documentation/blockdev/cciss.txt b/Documentation/blockdev/cciss.txt
index 89698e8df7d..c00c6a5ab21 100644
--- a/Documentation/blockdev/cciss.txt
+++ b/Documentation/blockdev/cciss.txt
@@ -169,3 +169,18 @@ is issued which positions the tape to a known position.  Typically you
 must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example)
 before i/o can proceed again to a tape drive which was reset.
+There is a cciss_tape_cmds module parameter which can be used to make cciss
+allocate more commands for use by tape drives.  Ordinarily only a few commands
+(6) are allocated for tape drives because tape drives are slow and
+infrequently used and the primary purpose of Smart Array controllers is to
+act as a RAID controller for disk drives, so the vast majority of commands
+are allocated for disk devices.  However, if you have more than a few tape
+drives attached to a smart array, the default number of commands may not be
+enought (for example, if you have 8 tape drives, you could only rewind 6
+at one time with the default number of commands.)  The cciss_tape_cmds module
+parameter allows more commands (up to 16 more) to be allocated for use by
+tape drives.  For example:
+        insmod cciss.ko cciss_tape_cmds=16
+Or, as a kernel boot parameter passed in via grub:  cciss.cciss_tape_cmds=8
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 9164ae3b83b..9b728dc1753 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -16,7 +16,7 @@ on all processors in the system.  Don't let this scare you into
 thinking SMP cache/tlb flushing must be so inefficient, this is in
 fact an area where many optimizations are possible.  For example,
 if it can be proven that a user address space has never executed
-on a cpu (see vma->cpu_vm_mask), one need not perform a flush
+on a cpu (see mm_cpumask()), one need not perform a flush
 for this address space on that cpu.
 First, the TLB flushing interfaces, since they are the simplest.  The
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index edb7ae19e86..2c6be0377f5 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -74,3 +74,57 @@ Example:
                interrupt-parent = <&mpic>;
                phy-handle = <&phy0>
        };
+* Gianfar PTP clock nodes
+General Properties:
+  - compatible   Should be "fsl,etsec-ptp"
+  - reg          Offset and length of the register set for the device
+  - interrupts   There should be at least two interrupts. Some devices
+                 have as many as four PTP related interrupts.
+Clock Properties:
+  - fsl,tclk-period  Timer reference clock period in nanoseconds.
+  - fsl,tmr-prsc     Prescaler, divides the output clock.
+  - fsl,tmr-add      Frequency compensation value.
+  - fsl,tmr-fiper1   Fixed interval period pulse generator.
+  - fsl,tmr-fiper2   Fixed interval period pulse generator.
+  - fsl,max-adj      Maximum frequency adjustment in parts per billion.
+  These properties set the operational parameters for the PTP
+  clock. You must choose these carefully for the clock to work right.
+  Here is how to figure good values:
+  TimerOsc     = system clock               MHz
+  tclk_period  = desired clock period       nanoseconds
+  NominalFreq  = 1000 / tclk_period         MHz
+  FreqDivRatio = TimerOsc / NominalFreq     (must be greater that 1.0)
+  tmr_add      = ceil(2^32 / FreqDivRatio)
+  OutputClock  = NominalFreq / tmr_prsc     MHz
+  PulseWidth   = 1 / OutputClock            microseconds
+  FiperFreq1   = desired frequency in Hz
+  FiperDiv1    = 1000000 * OutputClock / FiperFreq1
+  tmr_fiper1   = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
+  max_adj      = 1000000000 * (FreqDivRatio - 1.0) - 1
+  The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
+  driver expects that tmr_fiper1 will be correctly set to produce a 1
+  Pulse Per Second (PPS) signal, since this will be offered to the PPS
+  subsystem to synchronize the Linux clock.
+Example:
+        ptp_clock@24E00 {
+                compatible = "fsl,etsec-ptp";
+                reg = <0x24E00 0xB0>;
+                interrupts = <12 0x8 13 0x8>;
+                interrupt-parent = < &ipic >;
+                fsl,tclk-period = <10>;
+                fsl,tmr-prsc    = <100>;
+                fsl,tmr-add     = <0x999999A4>;
+                fsl,tmr-fiper1  = <0x3B9AC9F6>;
+                fsl,tmr-fiper2  = <0x00018696>;
+                fsl,max-adj     = <659999998>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index a7e155a023b..36afa322b04 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -127,7 +127,7 @@ Nintendo Wii device tree
   - reg : should contain the SDHCI registers location and length
   - interrupts : should contain the SDHCI interrupt
-1.j) The Inter-Processsor Communication (IPC) node
+1.j) The Inter-Processor Communication (IPC) node
  Represent the Inter-Processor Communication interface. This interface
  enables communications between the Broadway and the Starlet processors.
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 470d3dba1a6..dfa6fc6e4b2 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -1,6 +1,8 @@
 *.a
 *.aux
 *.bin
+*.bz2
+*.cis
 *.cpio
 *.csp
 *.dsp
@@ -8,6 +10,8 @@
 *.elf
 *.eps
 *.fw
+*.gcno
+*.gcov
 *.gen.S
 *.gif
 *.grep
@@ -19,14 +23,20 @@
 *.ko
 *.log
 *.lst
+*.lzma
+*.lzo
+*.mo
 *.moc
 *.mod.c
 *.o
 *.o.*
+*.order
 *.orig
 *.out
+*.patch
 *.pdf
 *.png
+*.pot
 *.ps
 *.rej
 *.s
@@ -39,16 +49,22 @@
 *.tex
 *.ver
 *.xml
+*.xz
 *_MODULES
 *_vga16.c
 *~
+\#*#
 *.9
-*.9.gz
 .*
+.*.d
 .mm
 53c700_d.h
 CVS
 ChangeSet
+GPATH
+GRTAGS
+GSYMS
+GTAGS
 Image
 Kerntypes
 Module.markers
@@ -57,15 +73,14 @@ PENDING
 SCCS
 System.map*
 TAGS
+aconf
+af_names.h
 aic7*reg.h*
 aic7*reg_print.c*
 aic7*seq.h*
 aicasm
 aicdb.h*
-altivec1.c
+altivec*.c
-altivec2.c
-altivec4.c
-altivec8.c
 asm-offsets.h
 asm_offsets.h
 autoconf.h*
@@ -80,6 +95,7 @@ btfixupprep
 build
 bvmlinux
 bzImage*
+capability_names.h
 capflags.c
 classlist.h*
 comp*.log
@@ -88,7 +104,8 @@ conf
 config
 config-*
 config_data.h*
-config_data.gz*
+config.mak
+config.mak.autogen
 conmakehash
 consolemap_deftbl.c*
 cpustr.h
@@ -96,7 +113,9 @@ crc32table.h*
 cscope.*
 defkeymap.c
 devlist.h*
+dnotify_test
 docproc
+dslm
 elf2ecoff
 elfconfig.h*
 evergreen_reg_safe.h
@@ -105,6 +124,7 @@ flask.h
 fore200e_mkfirm
 fore200e_pca_fw.c*
 gconf
+gconf.glade.h
 gen-devlist
 gen_crc32table
 gen_init_cpio
@@ -112,11 +132,12 @@ generated
 genheaders
 genksyms
 *_gray256.c
+hpet_example
+hugepage-mmap
+hugepage-shm
 ihex2fw
 ikconfig.h*
 inat-tables.c
-initramfs_data.cpio
-initramfs_data.cpio.gz
 initramfs_list
 int16.c
 int1.c
@@ -133,15 +154,19 @@ kxgettext
 lkc_defs.h
 lex.c
 lex.*.c
+linux
 logo_*.c
 logo_*_clut224.c
 logo_*_mono.c
 lxdialog
+mach
 mach-types
 mach-types.h
 machtypes.h
 map
+map_hugetlb
 maui_boot.h
+media
 mconf
 miboot*
 mk_elfconfig
@@ -150,23 +175,29 @@ mkbugboot
 mkcpustr
 mkdep
 mkprep
+mkregtable
 mktables
 mktree
 modpost
 modules.builtin
 modules.order
 modversions.h*
+nconf
 ncscope.*
 offset.h
 offsets.h
 oui.c*
+page-types
 parse.c
 parse.h
 patches*
 pca200e.bin
 pca200e_ecd.bin2
-piggy.gz
+perf.data
+perf.data.old
+perf-archive
 piggyback
+piggy.gzip
 piggy.S
 pnmtologo
 ppc_defs.h*
@@ -177,10 +208,9 @@ r200_reg_safe.h
 r300_reg_safe.h
 r420_reg_safe.h
 r600_reg_safe.h
-raid6altivec*.c
+recordmcount
-raid6int*.c
-raid6tables.c
 relocs
+rlim_names.h
 rn50_reg_safe.h
 rs600_reg_safe.h
 rv515_reg_safe.h
@@ -194,6 +224,7 @@ split-include
 syscalltab.h
 tables.c
 tags
+test_get_len
 tftpboot.img
 timeconst.h
 times.h*
@@ -210,10 +241,13 @@ vdso32.so.dbg
 vdso64.lds
 vdso64.so.dbg
 version.h*
+vmImage
 vmlinux
 vmlinux-*
 vmlinux.aout
+vmlinux.bin.all
 vmlinux.lds
+vmlinuz
 voffset.h
 vsyscall.lds
 vsyscall_32.lds
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 4cba260e305..95788ad2506 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -215,7 +215,7 @@ Who:	Zhang Rui <rui.zhang@intel.com>
 What:   CONFIG_ACPI_PROCFS_POWER
 When:   2.6.39
 Why:    sysfs I/F for ACPI power devices, including AC and Battery,
-        has been working in upstream kenrel since 2.6.24, Sep 2007.
+        has been working in upstream kernel since 2.6.24, Sep 2007.
        In 2.6.37, we make the sysfs I/F always built in and this option
        disabled by default.
        Remove this option and the ACPI power procfs interface in 2.6.39.
@@ -551,3 +551,26 @@ Why:	These legacy callbacks should no longer be used as i2c-core offers
 Who:    Jean Delvare <khali@linux-fr.org>
 ----------------------------
+What:   Support for UVCIOC_CTRL_ADD in the uvcvideo driver
+When:   2.6.42
+Why:    The information passed to the driver by this ioctl is now queried
+        dynamically from the device.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
+What:   Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
+When:   2.6.42
+Why:    Used only by applications compiled against older driver versions.
+        Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
+What:   Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
+When:   2.6.42
+Why:    Superseded by the UVCIOC_CTRL_QUERY ioctl.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index b22abba78fe..13de64c7f0a 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -25,6 +25,8 @@ Other applications are described in the following papers:
                http://xcpu.org/papers/cellfs-talk.pdf
        * PROSE I/O: Using 9p to enable Application Partitions
                http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
+        * VirtFS: A Virtualization Aware File System pass-through
+                http://goo.gl/3WPDg
 USAGE
 =====
@@ -130,31 +132,20 @@ OPTIONS
 RESOURCES
 =========
-Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html)
+Protocol specifications are maintained on github:
-as the 9p server.  You can start a 9p server under Inferno by issuing the
+http://ericvh.github.com/9p-rfc/
-following command:
-   ; styxlisten -A tcp!*!564 export '#U*'
-The -A specifies an unauthenticated export.  The 564 is the port # (you may
+9p client and server implementations are listed on
-have to choose a higher port number if running as a normal user).  The '#U*'
+http://9p.cat-v.org/implementations
-specifies exporting the root of the Linux name space.  You may specify a
-subset of the namespace by extending the path: '#U*'/tmp would just export
-/tmp.  For more information, see the Inferno manual pages covering styxlisten
-and export.
-A Linux version of the 9p server is now maintained under the npfs project
+A 9p2000.L server is being developed by LLNL and can be found
-on sourceforge (http://sourceforge.net/projects/npfs).  The currently
+at http://code.google.com/p/diod/
-maintained version is the single-threaded version of the server (named spfs)
-available from the same SVN repository.
 There are user and developer mailing lists available through the v9fs project
 on sourceforge (http://sourceforge.net/projects/v9fs).
-A stand-alone version of the module (which should build for any 2.6 kernel)
+News and other information is maintained on a Wiki.
-is available via (http://github.com/ericvh/9p-sac/tree/master)
+(http://sf.net/apps/mediawiki/v9fs/index.php).
-News and other information is maintained on SWiK (http://swik.net/v9fs)
-and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php).
 Bug reports may be issued through the kernel.org bugzilla 
 (http://bugzilla.kernel.org)
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 60740e8ecb3..f4817802406 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -574,6 +574,12 @@ The contents of each smp_affinity file is the same by default:
  > cat /proc/irq/0/smp_affinity
  ffffffff
+There is an alternate interface, smp_affinity_list which allows specifying
+a cpu range instead of a bitmask:
+  > cat /proc/irq/0/smp_affinity_list
+  1024-1031
 The default_smp_affinity mask applies to all non-active IRQs, which are the
 IRQs which have not yet been allocated/activated, and hence which lack a
 /proc/irq/[0-9]* directory.
@@ -583,12 +589,13 @@ reports itself as being attached. This hardware locality information does not
 include information about any possible driver locality preference.
 prof_cpu_mask specifies which CPUs are to be profiled by the system wide
-profiler. Default value is ffffffff (all cpus).
+profiler. Default value is ffffffff (all cpus if there are only 32 of them).
 The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
 between all the CPUs which are allowed to handle it. As usual the kernel has
 more info than you and does a better job than you, so the defaults are the
-best choice for almost everyone.
+best choice for almost everyone.  [Note this applies only to those IO-APIC's
+that support "Round Robin" interrupt distribution.]
 There are  three  more  important subdirectories in /proc: net, scsi, and sys.
 The general  rule  is  that  the  contents,  or  even  the  existence of these
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt
index d7b13b01e98..8e4fab639d9 100644
--- a/Documentation/filesystems/ubifs.txt
+++ b/Documentation/filesystems/ubifs.txt
@@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
 Module Parameters for Debugging
 ===============================
-When UBIFS has been compiled with debugging enabled, there are 3 module
+When UBIFS has been compiled with debugging enabled, there are 2 module
 parameters that are available to control aspects of testing and debugging.
-The parameters are unsigned integers where each bit controls an option.
-The parameters are:
-debug_msgs      Selects which debug messages to display, as follows:
-                Message Type                            Flag value
-                General messages                        1
-                Journal messages                        2
-                Mount messages                          4
-                Commit messages                         8
-                LEB search messages                     16
-                Budgeting messages                      32
-                Garbage collection messages             64
-                Tree Node Cache (TNC) messages          128
-                LEB properties (lprops) messages        256
-                Input/output messages                   512
-                Log messages                            1024
-                Scan messages                           2048
-                Recovery messages                       4096
 debug_chks      Selects extra checks that UBIFS can do while running:
@@ -154,11 +134,9 @@ debug_tsts	Selects a mode of testing, as follows:
                Test mode                               Flag value
-                Force in-the-gaps method                2
                Failure mode for recovery testing       4
-For example, set debug_msgs to 5 to display General messages and Mount
+For example, set debug_chks to 3 to enable general and TNC checks.
-messages.
 References
diff --git a/Documentation/usb/hiddev.txt b/Documentation/hid/hiddev.txt
index 6e8c9f1d2f2..6e8c9f1d2f2 100644
--- a/Documentation/usb/hiddev.txt
+++ b/Documentation/hid/hiddev.txt
diff --git a/Documentation/hid/hidraw.txt b/Documentation/hid/hidraw.txt
new file mode 100644
index 00000000000..029e6cb9a7e
--- /dev/null
+++ b/Documentation/hid/hidraw.txt
@@ -0,0 +1,119 @@
+      HIDRAW - Raw Access to USB and Bluetooth Human Interface Devices
+     ==================================================================
+The hidraw driver provides a raw interface to USB and Bluetooth Human
+Interface Devices (HIDs).  It differs from hiddev in that reports sent and
+received are not parsed by the HID parser, but are sent to and received from
+the device unmodified.
+Hidraw should be used if the userspace application knows exactly how to
+communicate with the hardware device, and is able to construct the HID
+reports manually.  This is often the case when making userspace drivers for
+custom HID devices.
+Hidraw is also useful for communicating with non-conformant HID devices
+which send and receive data in a way that is inconsistent with their report
+descriptors.  Because hiddev parses reports which are sent and received
+through it, checking them against the device's report descriptor, such
+communication with these non-conformant devices is impossible using hiddev.
+Hidraw is the only alternative, short of writing a custom kernel driver, for
+these non-conformant devices.
+A benefit of hidraw is that its use by userspace applications is independent
+of the underlying hardware type.  Currently, Hidraw is implemented for USB
+and Bluetooth.  In the future, as new hardware bus types are developed which
+use the HID specification, hidraw will be expanded to add support for these
+new bus types.
+Hidraw uses a dynamic major number, meaning that udev should be relied on to
+create hidraw device nodes.  Udev will typically create the device nodes
+directly under /dev (eg: /dev/hidraw0).  As this location is distribution-
+and udev rule-dependent, applications should use libudev to locate hidraw
+devices attached to the system.  There is a tutorial on libudev with a
+working example at:
+        http://www.signal11.us/oss/udev/
+The HIDRAW API
+---------------
+read()
+-------
+read() will read a queued report received from the HID device. On USB
+devices, the reports read using read() are the reports sent from the device
+on the INTERRUPT IN endpoint.  By default, read() will block until there is
+a report available to be read.  read() can be made non-blocking, by passing
+the O_NONBLOCK flag to open(), or by setting the O_NONBLOCK flag using
+fcntl().
+On a device which uses numbered reports, the first byte of the returned data
+will be the report number; the report data follows, beginning in the second
+byte.  For devices which do not use numbered reports, the report data
+will begin at the first byte.
+write()
+--------
+The write() function will write a report to the device. For USB devices, if
+the device has an INTERRUPT OUT endpoint, the report will be sent on that
+endpoint. If it does not, the report will be sent over the control endpoint,
+using a SET_REPORT transfer.
+The first byte of the buffer passed to write() should be set to the report
+number.  If the device does not use numbered reports, the first byte should
+be set to 0. The report data itself should begin at the second byte.
+ioctl()
+--------
+Hidraw supports the following ioctls:
+HIDIOCGRDESCSIZE: Get Report Descriptor Size
+This ioctl will get the size of the device's report descriptor.
+HIDIOCGRDESC: Get Report Descriptor
+This ioctl returns the device's report descriptor using a
+hidraw_report_descriptor struct.  Make sure to set the size field of the
+hidraw_report_descriptor struct to the size returned from HIDIOCGRDESCSIZE.
+HIDIOCGRAWINFO: Get Raw Info
+This ioctl will return a hidraw_devinfo struct containing the bus type, the
+vendor ID (VID), and product ID (PID) of the device. The bus type can be one
+of:
+        BUS_USB
+        BUS_HIL
+        BUS_BLUETOOTH
+        BUS_VIRTUAL
+which are defined in linux/input.h.
+HIDIOCGRAWNAME(len): Get Raw Name
+This ioctl returns a string containing the vendor and product strings of
+the device.  The returned string is Unicode, UTF-8 encoded.
+HIDIOCGRAWPHYS(len): Get Physical Address
+This ioctl returns a string representing the physical address of the device.
+For USB devices, the string contains the physical path to the device (the
+USB controller, hubs, ports, etc).  For Bluetooth devices, the string
+contains the hardware (MAC) address of the device.
+HIDIOCSFEATURE(len): Send a Feature Report
+This ioctl will send a feature report to the device.  Per the HID
+specification, feature reports are always sent using the control endpoint.
+Set the first byte of the supplied buffer to the report number.  For devices
+which do not use numbered reports, set the first byte to 0. The report data
+begins in the second byte. Make sure to set len accordingly, to one more
+than the length of the report (to account for the report number).
+HIDIOCGFEATURE(len): Get a Feature Report
+This ioctl will request a feature report from the device using the control
+endpoint.  The first byte of the supplied buffer should be set to the report
+number of the requested report.  For devices which do not use numbered
+reports, set the first byte to 0.  The report will be returned starting at
+the first byte of the buffer (ie: the report number is not returned).
+Example
+---------
+In samples/, find hid-example.c, which shows examples of read(), write(),
+and all the ioctls for hidraw.  The code may be used by anyone for any
+purpose, and can serve as a starting point for developing applications using
+hidraw.
+Document by:
+        Alan Ott <alan@signal11.us>, Signal 11 Software
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275
new file mode 100644
index 00000000000..6a3a6476cf2
--- /dev/null
+++ b/Documentation/hwmon/adm1275
@@ -0,0 +1,60 @@
+Kernel driver adm1275
+=====================
+Supported chips:
+  * Analog Devices ADM1275
+    Prefix: 'adm1275'
+    Addresses scanned: -
+    Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1275.pdf
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Description
+-----------
+This driver supports hardware montoring for Analog Devices ADM1275 Hot-Swap
+Controller and Digital Power Monitor.
+The ADM1275 is a hot-swap controller that allows a circuit board to be removed
+from or inserted into a live backplane. It also features current and voltage
+readback via an integrated 12-bit analog-to-digital converter (ADC), accessed
+using a PMBus. interface.
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus for details on PMBus client drivers.
+Usage Notes
+-----------
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+Platform data support
+---------------------
+The driver supports standard PMBus driver platform data. Please see
+Documentation/hwmon/pmbus for details.
+Sysfs entries
+-------------
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+in1_label               "vin1" or "vout1" depending on chip variant and
+                        configuration.
+in1_input               Measured voltage. From READ_VOUT register.
+in1_min                 Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in1_max                 Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in1_min_alarm           Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in1_max_alarm           Voltage high alarm. From VOLTAGE_OV_WARNING status.
+curr1_label             "iout1"
+curr1_input             Measured current. From READ_IOUT register.
+curr1_max               Maximum current. From IOUT_OC_WARN_LIMIT register.
+curr1_max_alarm         Current high alarm. From IOUT_OC_WARN_LIMIT register.
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 25568f84480..f85e913a340 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -15,8 +15,13 @@ Author: Rudolf Marek
 Description
 -----------
+This driver permits reading the DTS (Digital Temperature Sensor) embedded
+inside Intel CPUs. This driver can read both the per-core and per-package
+temperature using the appropriate sensors. The per-package sensor is new;
+as of now, it is present only in the SandyBridge platform. The driver will
+show the temperature of all cores inside a package under a single device
+directory inside hwmon.
-This driver permits reading temperature sensor embedded inside Intel Core CPU.
 Temperature is measured in degrees Celsius and measurement resolution is
 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because
 the actual value of temperature register is in fact a delta from TjMax.
@@ -27,13 +32,15 @@ mechanism will perform actions to forcibly cool down the processor. Alarm
 may be raised, if the temperature grows enough (more than TjMax) to trigger
 the Out-Of-Spec bit. Following table summarizes the exported sysfs files:
-temp1_input      - Core temperature (in millidegrees Celsius).
+All Sysfs entries are named with their core_id (represented here by 'X').
-temp1_max        - All cooling devices should be turned on (on Core2).
+tempX_input      - Core temperature (in millidegrees Celsius).
-temp1_crit       - Maximum junction temperature (in millidegrees Celsius).
+tempX_max        - All cooling devices should be turned on (on Core2).
-temp1_crit_alarm - Set when Out-of-spec bit is set, never clears.
+tempX_crit       - Maximum junction temperature (in millidegrees Celsius).
+tempX_crit_alarm - Set when Out-of-spec bit is set, never clears.
                   Correct CPU operation is no longer guaranteed.
-temp1_label      - Contains string "Core X", where X is processor
+tempX_label      - Contains string "Core X", where X is processor
-                   number.
+                   number. For Package temp, this will be "Physical id Y",
+                   where Y is the package number.
 The TjMax temperature is set to 85 degrees C if undocumented model specific
 register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as
diff --git a/Documentation/hwmon/emc6w201 b/Documentation/hwmon/emc6w201
new file mode 100644
index 00000000000..32f355aaf56
--- /dev/null
+++ b/Documentation/hwmon/emc6w201
@@ -0,0 +1,42 @@
+Kernel driver emc6w201
+======================
+Supported chips:
+  * SMSC EMC6W201
+    Prefix: 'emc6w201'
+    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
+    Datasheet: Not public
+Author: Jean Delvare <khali@linux-fr.org>
+Description
+-----------
+From the datasheet:
+"The EMC6W201 is an environmental monitoring device with automatic fan
+control capability and enhanced system acoustics for noise suppression.
+This ACPI compliant device provides hardware monitoring for up to six
+voltages (including its own VCC) and five external thermal sensors,
+measures the speed of up to five fans, and controls the speed of
+multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note
+that it is possible to control more than three fans by connecting two
+fans to one PWM output. The EMC6W201 will be available in a 36-pin
+QFN package."
+The device is functionally close to the EMC6D100 series, but is
+register-incompatible.
+The driver currently only supports the monitoring of the voltages,
+temperatures and fan speeds. Limits can be changed. Alarms are not
+supported, and neither is fan speed control.
+Known Systems With EMC6W201
+---------------------------
+The EMC6W201 is a rare device, only found on a few systems, made in
+2005 and 2006. Known systems with this device:
+* Dell Precision 670 workstation
+* Gigabyte 2CEWH mainboard
diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg
index df02245d141..84d2623810f 100644
--- a/Documentation/hwmon/f71882fg
+++ b/Documentation/hwmon/f71882fg
@@ -6,6 +6,10 @@ Supported chips:
    Prefix: 'f71808e'
    Addresses scanned: none, address read from Super I/O config space
    Datasheet: Not public
+  * Fintek F71808A
+    Prefix: 'f71808a'
+    Addresses scanned: none, address read from Super I/O config space
+    Datasheet: Not public
  * Fintek F71858FG
    Prefix: 'f71858fg'
    Addresses scanned: none, address read from Super I/O config space
diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
new file mode 100644
index 00000000000..a92918e0bd6
--- /dev/null
+++ b/Documentation/hwmon/fam15h_power
@@ -0,0 +1,37 @@
+Kernel driver fam15h_power
+==========================
+Supported chips:
+* AMD Family 15h Processors
+  Prefix: 'fam15h_power'
+  Addresses scanned: PCI space
+  Datasheets:
+  BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
+    (not yet published)
+Author: Andreas Herrmann <andreas.herrmann3@amd.com>
+Description
+-----------
+This driver permits reading of registers providing power information
+of AMD Family 15h processors.
+For AMD Family 15h processors the following power values can be
+calculated using different processor northbridge function registers:
+* BasePwrWatts: Specifies in watts the maximum amount of power
+  consumed by the processor for NB and logic external to the core.
+* ProcessorPwrWatts: Specifies in watts the maximum amount of power
+  the processor can support.
+* CurrPwrWatts: Specifies in watts the current amount of power being
+  consumed by the processor.
+This driver provides ProcessorPwrWatts and CurrPwrWatts:
+* power1_crit (ProcessorPwrWatts)
+* power1_input (CurrPwrWatts)
+On multi-node processors the calculated value is for the entire
+package and not for a single node. Thus the driver creates sysfs
+attributes only for internal node0 of a multi-node processor.
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
index d2b56a4fd1f..0393c89277c 100644
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -11,6 +11,7 @@ Supported chips:
  Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
 * AMD Family 12h processors: "Llano"
 * AMD Family 14h processors: "Brazos" (C/E/G-Series)
+* AMD Family 15h processors: "Bulldozer"
  Prefix: 'k10temp'
  Addresses scanned: PCI space
@@ -40,7 +41,7 @@ Description
 -----------
 This driver permits reading of the internal temperature sensor of AMD
-Family 10h/11h/12h/14h processors.
+Family 10h/11h/12h/14h/15h processors.
 All these processors have a sensor, but on those for Socket F or AM2+,
 the sensor may return inconsistent values (erratum 319).  The driver
diff --git a/Documentation/hwmon/max16065 b/Documentation/hwmon/max16065
new file mode 100644
index 00000000000..44b4f61e04f
--- /dev/null
+++ b/Documentation/hwmon/max16065
@@ -0,0 +1,98 @@
+Kernel driver max16065
+======================
+Supported chips:
+  * Maxim MAX16065, MAX16066
+    Prefixes: 'max16065', 'max16066'
+    Addresses scanned: -
+    Datasheet:
+        http://datasheets.maxim-ic.com/en/ds/MAX16065-MAX16066.pdf
+ *  Maxim MAX16067
+    Prefix: 'max16067'
+    Addresses scanned: -
+    Datasheet:
+        http://datasheets.maxim-ic.com/en/ds/MAX16067.pdf
+ *  Maxim MAX16068
+    Prefix: 'max16068'
+    Addresses scanned: -
+    Datasheet:
+        http://datasheets.maxim-ic.com/en/ds/MAX16068.pdf
+ *  Maxim MAX16070/MAX16071
+    Prefixes: 'max16070', 'max16071'
+    Addresses scanned: -
+    Datasheet:
+        http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Description
+-----------
+[From datasheets] The MAX16065/MAX16066 flash-configurable system managers
+monitor and sequence multiple system voltages. The MAX16065/MAX16066 can also
+accurately monitor (+/-2.5%) one current channel using a dedicated high-side
+current-sense amplifier. The MAX16065 manages up to twelve system voltages
+simultaneously, and the MAX16066 manages up to eight supply voltages.
+The MAX16067 flash-configurable system manager monitors and sequences multiple
+system voltages. The MAX16067 manages up to six system voltages simultaneously.
+The MAX16068 flash-configurable system manager monitors and manages up to six
+system voltages simultaneously.
+The MAX16070/MAX16071 flash-configurable system monitors supervise multiple
+system voltages. The MAX16070/MAX16071 can also accurately monitor (+/-2.5%)
+one current channel using a dedicated high-side current-sense amplifier. The
+MAX16070 monitors up to twelve system voltages simultaneously, and the MAX16071
+monitors up to eight supply voltages.
+Each monitored channel has its own low and high critical limits. MAX16065,
+MAX16066, MAX16070, and MAX16071 support an additional limit which is
+configurable as either low or high secondary limit. MAX16065, MAX16066,
+MAX16070, and MAX16071 also support supply current monitoring.
+Usage Notes
+-----------
+This driver does not probe for devices, since there is no register which
+can be safely used to identify the chip. You will have to instantiate
+the devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+Sysfs entries
+-------------
+in[0-11]_input          Input voltage measurements.
+in12_input              Voltage on CSP (Current Sense Positive) pin.
+                        Only if the chip supports current sensing and if
+                        current sensing is enabled.
+in[0-11]_min            Low warning limit.
+                        Supported on MAX16065, MAX16066, MAX16070, and MAX16071
+                        only.
+in[0-11]_max            High warning limit.
+                        Supported on MAX16065, MAX16066, MAX16070, and MAX16071
+                        only.
+                        Either low or high warning limits are supported
+                        (depending on chip configuration), but not both.
+in[0-11]_lcrit          Low critical limit.
+in[0-11]_crit           High critical limit.
+in[0-11]_alarm          Input voltage alarm.
+curr1_input             Current sense input; only if the chip supports current
+                        sensing and if current sensing is enabled.
+                        Displayed current assumes 0.001 Ohm current sense
+                        resistor.
+curr1_alarm             Overcurrent alarm; only if the chip supports current
+                        sensing and if current sensing is enabled.
diff --git a/Documentation/hwmon/max6642 b/Documentation/hwmon/max6642
new file mode 100644
index 00000000000..afbd3e4942e
--- /dev/null
+++ b/Documentation/hwmon/max6642
@@ -0,0 +1,21 @@
+Kernel driver max6642
+=====================
+Supported chips:
+  * Maxim MAX6642
+    Prefix: 'max6642'
+    Addresses scanned: I2C 0x48-0x4f
+    Datasheet: Publicly available at the Maxim website
+               http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf
+Authors:
+        Per Dalen <per.dalen@appeartv.com>
+Description
+-----------
+The MAX6642 is a digital temperature sensor. It senses its own temperature as
+well as the temperature on one external diode.
+All temperature values are given in degrees Celsius. Resolution
+is 0.25 degree for the local temperature and for the remote temperature.
diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650
index c565650fcfc..58d9644a2bd 100644
--- a/Documentation/hwmon/max6650
+++ b/Documentation/hwmon/max6650
@@ -2,9 +2,13 @@ Kernel driver max6650
 =====================
 Supported chips:
-  * Maxim 6650 / 6651
+  * Maxim MAX6650
    Prefix: 'max6650'
-    Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b
+    Addresses scanned: none
+    Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
+  * Maxim MAX6651
+    Prefix: 'max6651'
+    Addresses scanned: none
    Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
 Authors:
@@ -15,10 +19,10 @@ Authors:
 Description
 -----------
-This driver implements support for the Maxim 6650/6651
+This driver implements support for the Maxim MAX6650 and MAX6651.
-The 2 devices are very similar, but the Maxim 6550 has a reduced feature
+The 2 devices are very similar, but the MAX6550 has a reduced feature
-set, e.g. only one fan-input, instead of 4 for the 6651.
+set, e.g. only one fan-input, instead of 4 for the MAX6651.
 The driver is not able to distinguish between the 2 devices.
@@ -36,6 +40,13 @@ fan1_div	rw	sets the speed range the inputs can handle. Legal
                        values are 1, 2, 4, and 8. Use lower values for
                        faster fans.
+Usage notes
+-----------
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
 Module parameters
 -----------------
diff --git a/Documentation/hwmon/pkgtemp b/Documentation/hwmon/pkgtemp
deleted file mode 100644
index c8e1fb0fadd..00000000000
--- a/Documentation/hwmon/pkgtemp
+++ /dev/null
@@ -1,36 +0,0 @@
-Kernel driver pkgtemp
-======================
-Supported chips:
-  * Intel family
-    Prefix: 'pkgtemp'
-    CPUID:
-    Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
-               Volume 3A: System Programming Guide
-Author: Fenghua Yu
-Description
-----------
-This driver permits reading package level temperature sensor embedded inside
-Intel CPU package. The sensors can be in core, uncore, memory controller, or
-other components in a package. The feature is first implemented in Intel Sandy
-Bridge platform.
-Temperature is measured in degrees Celsius and measurement resolution is
-1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual
-value of temperature register is in fact a delta from TjMax.
-Temperature known as TjMax is the maximum junction temperature of package.
-We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible,
-we define TjMax as 100 degrees Celsius. At this temperature, protection
-mechanism will perform actions to forcibly cool down the package. Alarm
-may be raised, if the temperature grows enough (more than TjMax) to trigger
-the Out-Of-Spec bit. Following table summarizes the exported sysfs files:
-temp1_input       - Package temperature (in millidegrees Celsius).
-temp1_max        - All cooling devices should be turned on.
-temp1_crit        - Maximum junction temperature (in millidegrees Celsius).
-temp1_crit_alarm - Set when Out-of-spec bit is set, never clears.
-                    Correct CPU operation is no longer guaranteed.
diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15
new file mode 100644
index 00000000000..02850bdfac1
--- /dev/null
+++ b/Documentation/hwmon/sht15
@@ -0,0 +1,74 @@
+Kernel driver sht15
+===================
+Authors:
+  * Wouter Horre
+  * Jonathan Cameron
+  * Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+  * Jerome Oufella <jerome.oufella@savoirfairelinux.com>
+Supported chips:
+  * Sensirion SHT10
+    Prefix: 'sht10'
+  * Sensirion SHT11
+    Prefix: 'sht11'
+  * Sensirion SHT15
+    Prefix: 'sht15'
+  * Sensirion SHT71
+    Prefix: 'sht71'
+  * Sensirion SHT75
+    Prefix: 'sht75'
+Datasheet: Publicly available at the Sensirion website
+http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf
+Description
+-----------
+The SHT10, SHT11, SHT15, SHT71, and SHT75 are humidity and temperature
+sensors.
+The devices communicate using two GPIO lines.
+Supported resolutions for the measurements are 14 bits for temperature and 12
+bits for humidity, or 12 bits for temperature and 8 bits for humidity.
+The humidity calibration coefficients are programmed into an OTP memory on the
+chip. These coefficients are used to internally calibrate the signals from the
+sensors. Disabling the reload of those coefficients allows saving 10ms for each
+measurement and decrease power consumption, while loosing on precision.
+Some options may be set directly in the sht15_platform_data structure
+or via sysfs attributes.
+Notes:
+  * The regulator supply name is set to "vcc".
+  * If a CRC validation fails, a soft reset command is sent, which resets
+    status register to its hardware default value, but the driver will try to
+    restore the previous device configuration.
+Platform data
+-------------
+* checksum:
+  set it to true to enable CRC validation of the readings (default to false).
+* no_otp_reload:
+  flag to indicate not to reload from OTP (default to false).
+* low_resolution:
+  flag to indicate the temp/humidity resolution to use (default to false).
+Sysfs interface
+---------------
+* temp1_input:     temperature input
+* humidity1_input: humidity input
+* heater_enable:   write 1 in this attribute to enable the on-chip heater,
+                   0 to disable it. Be careful not to enable the heater
+                   for too long.
+* temp1_fault:     if 1, this means that the voltage is low (below 2.47V) and
+                   measurement may be invalid.
+* humidity1_fault: same as temp1_fault.
diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000
new file mode 100644
index 00000000000..40ca6db50c4
--- /dev/null
+++ b/Documentation/hwmon/ucd9000
@@ -0,0 +1,110 @@
+Kernel driver ucd9000
+=====================
+Supported chips:
+  * TI UCD90120, UCD90124, UCD9090, and UCD90910
+    Prefixes: 'ucd90120', 'ucd90124', 'ucd9090', 'ucd90910'
+    Addresses scanned: -
+    Datasheets:
+        http://focus.ti.com/lit/ds/symlink/ucd90120.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd90124.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Description
+-----------
+From datasheets:
+The UCD90120 Power Supply Sequencer and System Health Monitor monitors and
+sequences up to 12 independent voltage rails. The device integrates a 12-bit
+ADC with a 2.5V internal reference for monitoring up to 13 power supply voltage,
+current, or temperature inputs.
+The UCD90124 is a 12-rail PMBus/I2C addressable power-supply sequencer and
+system-health monitor. The device integrates a 12-bit ADC for monitoring up to
+13 power-supply voltage, current, or temperature inputs. Twenty-six GPIO pins
+can be used for power supply enables, power-on reset signals, external
+interrupts, cascading, or other system functions. Twelve of these pins offer PWM
+functionality. Using these pins, the UCD90124 offers support for fan control,
+margining, and general-purpose PWM functions.
+The UCD9090 is a 10-rail PMBus/I2C addressable power-supply sequencer and
+monitor. The device integrates a 12-bit ADC for monitoring up to 10 power-supply
+voltage inputs. Twenty-three GPIO pins can be used for power supply enables,
+power-on reset signals, external interrupts, cascading, or other system
+functions. Ten of these pins offer PWM functionality. Using these pins, the
+UCD9090 offers support for margining, and general-purpose PWM functions.
+The UCD90910 is a ten-rail I2C / PMBus addressable power-supply sequencer and
+system-health monitor. The device integrates a 12-bit ADC for monitoring up to
+13 power-supply voltage, current, or temperature inputs.
+This driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus for details on PMBus client drivers.
+Usage Notes
+-----------
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+Platform data support
+---------------------
+The driver supports standard PMBus driver platform data. Please see
+Documentation/hwmon/pmbus for details.
+Sysfs entries
+-------------
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+in[1-12]_label          "vout[1-12]".
+in[1-12]_input          Measured voltage. From READ_VOUT register.
+in[1-12]_min            Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[1-12]_max            Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in[1-12]_lcrit          Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[1-12]_crit           Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
+in[1-12]_min_alarm      Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in[1-12]_max_alarm      Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in[1-12]_lcrit_alarm    Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
+in[1-12]_crit_alarm     Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
+curr[1-12]_label        "iout[1-12]".
+curr[1-12]_input        Measured current. From READ_IOUT register.
+curr[1-12]_max          Maximum current. From IOUT_OC_WARN_LIMIT register.
+curr[1-12]_lcrit        Critical minumum output current. From IOUT_UC_FAULT_LIMIT
+                        register.
+curr[1-12]_crit         Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
+curr[1-12]_max_alarm    Current high alarm. From IOUT_OC_WARNING status.
+curr[1-12]_crit_alarm   Current critical high alarm. From IOUT_OC_FAULT status.
+                        For each attribute index, either voltage or current is
+                        reported, but not both. If voltage or current is
+                        reported depends on the chip configuration.
+temp[1-2]_input         Measured temperatures. From READ_TEMPERATURE_1 and
+                        READ_TEMPERATURE_2 registers.
+temp[1-2]_max           Maximum temperature. From OT_WARN_LIMIT register.
+temp[1-2]_crit          Critical high temperature. From OT_FAULT_LIMIT register.
+temp[1-2]_max_alarm     Temperature high alarm.
+temp[1-2]_crit_alarm    Temperature critical high alarm.
+fan[1-4]_input          Fan RPM.
+fan[1-4]_alarm          Fan alarm.
+fan[1-4]_fault          Fan fault.
+                        Fan attributes are only available on chips supporting
+                        fan control (UCD90124, UCD90910). Attribute files are
+                        created only for enabled fans.
+                        Note that even though UCD90910 supports up to 10 fans,
+                        only up to four fans are currently supported.
diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200
new file mode 100644
index 00000000000..3c58607f72f
--- /dev/null
+++ b/Documentation/hwmon/ucd9200
@@ -0,0 +1,112 @@
+Kernel driver ucd9200
+=====================
+Supported chips:
+  * TI UCD9220, UCD9222, UCD9224, UCD9240, UCD9244, UCD9246, and UCD9248
+    Prefixes: 'ucd9220', 'ucd9222', 'ucd9224', 'ucd9240', 'ucd9244', 'ucd9246',
+        'ucd9248'
+    Addresses scanned: -
+    Datasheets:
+        http://focus.ti.com/lit/ds/symlink/ucd9220.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9222.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9224.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9240.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9244.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
+        http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+Description
+-----------
+[From datasheets] UCD9220, UCD9222, UCD9224, UCD9240, UCD9244, UCD9246, and
+UCD9248 are multi-rail, multi-phase synchronous buck digital PWM controllers
+designed for non-isolated DC/DC power applications. The devices integrate
+dedicated circuitry for DC/DC loop management with flash memory and a serial
+interface to support configuration, monitoring and management.
+This driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus for details on PMBus client drivers.
+Usage Notes
+-----------
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+Platform data support
+---------------------
+The driver supports standard PMBus driver platform data. Please see
+Documentation/hwmon/pmbus for details.
+Sysfs entries
+-------------
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+in1_label               "vin".
+in1_input               Measured voltage. From READ_VIN register.
+in1_min                 Minumum Voltage. From VIN_UV_WARN_LIMIT register.
+in1_max                 Maximum voltage. From VIN_OV_WARN_LIMIT register.
+in1_lcrit               Critical minumum Voltage. VIN_UV_FAULT_LIMIT register.
+in1_crit                Critical maximum voltage. From VIN_OV_FAULT_LIMIT register.
+in1_min_alarm           Voltage low alarm. From VIN_UV_WARNING status.
+in1_max_alarm           Voltage high alarm. From VIN_OV_WARNING status.
+in1_lcrit_alarm         Voltage critical low alarm. From VIN_UV_FAULT status.
+in1_crit_alarm          Voltage critical high alarm. From VIN_OV_FAULT status.
+in[2-5]_label           "vout[1-4]".
+in[2-5]_input           Measured voltage. From READ_VOUT register.
+in[2-5]_min             Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[2-5]_max             Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in[2-5]_lcrit           Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[2-5]_crit            Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
+in[2-5]_min_alarm       Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in[2-5]_max_alarm       Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in[2-5]_lcrit_alarm     Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
+in[2-5]_crit_alarm      Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
+curr1_label             "iin".
+curr1_input             Measured current. From READ_IIN register.
+curr[2-5]_label         "iout[1-4]".
+curr[2-5]_input         Measured current. From READ_IOUT register.
+curr[2-5]_max           Maximum current. From IOUT_OC_WARN_LIMIT register.
+curr[2-5]_lcrit         Critical minumum output current. From IOUT_UC_FAULT_LIMIT
+                        register.
+curr[2-5]_crit          Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
+curr[2-5]_max_alarm     Current high alarm. From IOUT_OC_WARNING status.
+curr[2-5]_crit_alarm    Current critical high alarm. From IOUT_OC_FAULT status.
+power1_input            Measured input power. From READ_PIN register.
+power1_label            "pin"
+power[2-5]_input        Measured output power. From READ_POUT register.
+power[2-5]_label        "pout[1-4]"
+                        The number of output voltage, current, and power
+                        attribute sets is determined by the number of enabled
+                        rails. See chip datasheets for details.
+temp[1-5]_input         Measured temperatures. From READ_TEMPERATURE_1 and
+                        READ_TEMPERATURE_2 registers.
+                        temp1 is the chip internal temperature. temp[2-5] are
+                        rail temperatures.  temp[2-5] attributes are only
+                        created for enabled rails. See chip datasheets for
+                        details.
+temp[1-5]_max           Maximum temperature. From OT_WARN_LIMIT register.
+temp[1-5]_crit          Critical high temperature. From OT_FAULT_LIMIT register.
+temp[1-5]_max_alarm     Temperature high alarm.
+temp[1-5]_crit_alarm    Temperature critical high alarm.
+fan1_input              Fan RPM. ucd9240 only.
+fan1_alarm              Fan alarm. ucd9240 only.
+fan1_fault              Fan fault. ucd9240 only.
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index 6df69765ccb..2871fd50034 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -19,6 +19,7 @@ Supported adapters:
  * Intel 6 Series (PCH)
  * Intel Patsburg (PCH)
  * Intel DH89xxCC (PCH)
+  * Intel Panther Point (PCH)
   Datasheets: Publicly available at the Intel website
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 5ebf5af1d71..5aa53374ea2 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = {
                .name   = "foo",
        },
-        .id_table       = foo_ids,
+        .id_table       = foo_idtable,
        .probe          = foo_probe,
        .remove         = foo_remove,
        /* if device autodetection is needed: */
diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt
index 56941ae1f5d..db798af5ef9 100644
--- a/Documentation/input/elantech.txt
+++ b/Documentation/input/elantech.txt
@@ -34,7 +34,8 @@ Contents
 Currently the Linux Elantech touchpad driver is aware of two different
 hardware versions unimaginatively called version 1 and version 2. Version 1
 is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
-be introduced with the EeePC and uses 6 bytes per packet.
+be introduced with the EeePC and uses 6 bytes per packet, and provides
+additional features such as position of two fingers, and width of the touch.
 The driver tries to support both hardware versions and should be compatible
 with the Xorg Synaptics touchpad driver and its graphical configuration
@@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under
   can check these bits and reject any packet that appears corrupted. Using
   this knob you can bypass that check.
-   It is not known yet whether hardware version 2 provides the same parity
+   Hardware version 2 does not provide the same parity bits. Only some basic
-   bits. Hence checking is disabled by default. Currently even turning it on
+   data consistency checking can be done. For now checking is disabled by
-   will do nothing.
+   default. Currently even turning it on will do nothing.
 /////////////////////////////////////////////////////////////////////////////
+3. Differentiating hardware versions
+   =================================
+To detect the hardware version, read the version number as param[0].param[1].param[2]
+ 4 bytes version: (after the arrow is the name given in the Dell-provided driver)
+ 02.00.22 => EF013
+ 02.06.00 => EF019
+In the wild, there appear to be more versions, such as 00.01.64, 01.00.21,
+02.00.00, 02.00.04, 02.00.06.
+ 6 bytes:
+ 02.00.30 => EF113
+ 02.08.00 => EF023
+ 02.08.XX => EF123
+ 02.0B.00 => EF215
+ 04.01.XX => Scroll_EF051
+ 04.02.XX => EF051
+In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There
+appears to be almost no difference, except for EF113, which does not report
+pressure/width and has different data consistency checks.
+Probably all the versions with param[0] <= 01 can be considered as
+4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as
+4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes.
+/////////////////////////////////////////////////////////////////////////////
-3. Hardware version 1
+4. Hardware version 1
   ==================
-3.1 Registers
+4.1 Registers
    ~~~~~~~~~
 By echoing a hexadecimal value to a register it contents can be altered.
@@ -168,7 +195,7 @@ For example:
         smart edge activation area width?
-3.2 Native relative mode 4 byte packet format
+4.2 Native relative mode 4 byte packet format
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 byte 0:
@@ -226,9 +253,13 @@ byte 3:
                       positive = down
-3.3 Native absolute mode 4 byte packet format
+4.3 Native absolute mode 4 byte packet format
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and
+when 1 finger is touching, the first 2 position reports must be discarded.
+This counting is reset whenever a different number of fingers is reported.
 byte 0:
   firmware version 1.x:
@@ -279,11 +310,11 @@ byte 3:
 /////////////////////////////////////////////////////////////////////////////
-4. Hardware version 2
+5. Hardware version 2
   ==================
-4.1 Registers
+5.1 Registers
    ~~~~~~~~~
 By echoing a hexadecimal value to a register it contents can be altered.
@@ -316,16 +347,41 @@ For example:
                                   0x7f = never i.e. tap again to release)
-4.2 Native absolute mode 6 byte packet format
+5.2 Native absolute mode 6 byte packet format
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+5.2.1 Parity checking and packet re-synchronization
-4.2.1 One finger touch
+There is no parity checking, however some consistency checks can be performed.
+For instance for EF113:
+        SA1= packet[0];
+        A1 = packet[1];
+        B1 = packet[2];
+        SB1= packet[3];
+        C1 = packet[4];
+        D1 = packet[5];
+        if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1
+            (((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed)
+            (((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2
+            (((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4
+            (((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed)
+            (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00))  ) // check Byte 5
+                // error detected
+For all the other ones, there are just a few constant bits:
+        if( ((packet[0] & 0x0C) != 0x04) ||
+            ((packet[3] & 0x0f) != 0x02) )
+                // error detected
+In case an error is detected, all the packets are shifted by one (and packet[0] is discarded).
+5.2.1 One/Three finger touch
      ~~~~~~~~~~~~~~~~
 byte 0:
   bit   7   6   5   4   3   2   1   0
-        n1  n0   .   .   .   .   R   L
+         n1  n0  w3  w2   .   .   R   L
         L, R = 1 when Left, Right mouse button pressed
         n1..n0 = numbers of fingers on touchpad
@@ -333,24 +389,40 @@ byte 0:
 byte 1:
   bit   7   6   5   4   3   2   1   0
-         .   .   .   .   .  x10 x9  x8
+         p7  p6  p5  p4  .  x10 x9  x8
 byte 2:
   bit   7   6   5   4   3   2   1   0
-        x7  x6  x5  x4  x4  x2  x1  x0
+         x7  x6  x5  x4  x3  x2  x1  x0
         x10..x0 = absolute x value (horizontal)
 byte 3:
   bit   7   6   5   4   3   2   1   0
-         .   .   .   .   .   .   .   .
+         n4  vf  w1  w0   .   .   .  b2
+         n4 = set if more than 3 fingers (only in 3 fingers mode)
+         vf = a kind of flag ? (only on EF123, 0 when finger is over one
+              of the buttons, 1 otherwise)
+         w3..w0 = width of the finger touch (not EF113)
+         b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed:
+                0 = none
+                1 = Left
+                2 = Right
+                3 = Middle (Left and Right)
+                4 = Forward
+                5 = Back
+                6 = Another one
+                7 = Another one
 byte 4:
   bit   7   6   5   4   3   2   1   0
-         .   .   .   .   .   .  y9  y8
+        p3  p1  p2  p0   .   .  y9  y8
+         p7..p0 = pressure (not EF113)
 byte 5:
@@ -363,6 +435,11 @@ byte 5:
 4.2.2 Two finger touch
      ~~~~~~~~~~~~~~~~
+Note that the two pairs of coordinates are not exactly the coordinates of the
+two fingers, but only the pair of the lower-left and upper-right coordinates.
+So the actual fingers might be situated on the other diagonal of the square
+defined by these two points.
 byte 0:
   bit   7   6   5   4   3   2   1   0
@@ -376,14 +453,14 @@ byte 1:
   bit   7   6   5   4   3   2   1   0
        ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0
-         ax8..ax0 = first finger absolute x value
+         ax8..ax0 = lower-left finger absolute x value
 byte 2:
   bit   7   6   5   4   3   2   1   0
        ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0
-         ay8..ay0 = first finger absolute y value
+         ay8..ay0 = lower-left finger absolute y value
 byte 3:
@@ -395,11 +472,11 @@ byte 4:
   bit   7   6   5   4   3   2   1   0
        bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0
-         bx8..bx0 = second finger absolute x value
+         bx8..bx0 = upper-right finger absolute x value
 byte 5:
   bit   7   6   5   4   3   2   1   0
        by7 by8 by5 by4 by3 by2 by1 by0
-         by8..by0 = second finger absolute y value
+         by8..by0 = upper-right finger absolute y value
diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt
index 943e8f6f2b1..92e68bce13a 100644
--- a/Documentation/input/rotary-encoder.txt
+++ b/Documentation/input/rotary-encoder.txt
@@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees
 and by triggering on falling and rising edges, the turn direction can
 be determined.
+Some encoders have both outputs low in stable states, whereas others also have
+a stable state with both outputs high (half-period mode).
 The phase diagram of these two outputs look like this:
                  _____       _____       _____
@@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this:
                |<-------->|
                  one step
+                |<-->|
+                  one step (half-period mode)
 For more information, please see
        http://en.wikipedia.org/wiki/Rotary_encoder
@@ -34,6 +39,13 @@ For more information, please see
 1. Events / state machine
 -------------------------
+In half-period mode, state a) and c) above are used to determine the
+rotational direction based on the last stable state. Events are reported in
+states b) and d) given that the new stable state is different from the last
+(i.e. the rotation was not reversed half-way).
+Otherwise, the following apply:
 a) Rising edge on channel A, channel B in low state
        This state is used to recognize a clockwise turn
@@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = {
        .gpio_b         = GPIO_ROTARY_B,
        .inverted_a     = 0,
        .inverted_b     = 0,
+        .half_period    = false,
 };
 static struct platform_device rotary_encoder_device = {
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index a0a5d82b6b0..3a46e360496 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -166,7 +166,6 @@ Code  Seq#(hex)	Include File		Comments
 'T'     all     arch/x86/include/asm/ioctls.h   conflict!
 'T'     C0-DF   linux/if_tun.h          conflict!
 'U'     all     sound/asound.h          conflict!
-'U'     00-0F   drivers/media/video/uvc/uvcvideo.h      conflict!
 'U'     00-CF   linux/uinput.h          conflict!
 'U'     00-EF   linux/usbdevice_fs.h
 'U'     C0-CF   drivers/bluetooth/hci_uart.h
@@ -259,6 +258,7 @@ Code  Seq#(hex)	Include File		Comments
 't'     80-8F   linux/isdn_ppp.h
 't'     90      linux/toshiba.h
 'u'     00-1F   linux/smb_fs.h          gone
+'u'     20-3F   linux/uvcvideo.h        USB video class host driver
 'v'     00-1F   linux/ext2_fs.h         conflict!
 'v'     00-1F   linux/fs.h              conflict!
 'v'     00-0F   linux/sonypi.h          conflict!
@@ -304,6 +304,7 @@ Code  Seq#(hex)	Include File		Comments
 0xB0    all     RATIO devices           in development:
                                        <mailto:vgo@ratio.de>
 0xB1    00-1F   PPPoX                   <mailto:mostrows@styx.uwaterloo.ca>
+0xB3    00      linux/mmc/ioctl.h
 0xC0    00-0F   linux/usb/iowarrior.h
 0xCB    00-1F   CBM serial IEC bus      in development:
                                        <mailto:michael.klein@puffin.lb.shuttle.de>
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 7c2a89ba674..68e32bb6bd8 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -201,3 +201,16 @@ KBUILD_ENABLE_EXTRA_GCC_CHECKS
 --------------------------------------------------
 If enabled over the make command line with "W=1", it turns on additional
 gcc -W... options for more extensive build-time checking.
+KBUILD_BUILD_TIMESTAMP
+--------------------------------------------------
+Setting this to a date string overrides the timestamp used in the
+UTS_VERSION definition (uname -v in the running kernel). The value has to
+be a string that can be passed to date -d. The default value
+is the output of the date command at one point during build.
+KBUILD_BUILD_USER, KBUILD_BUILD_HOST
+--------------------------------------------------
+These two variables allow to override the user@host string displayed during
+boot and in /proc/version. The default value is the output of the commands
+whoami and host, respectively.
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index b507d61fd41..44e2649fbb2 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -113,6 +113,13 @@ applicable everywhere (see syntax).
        That will limit the usefulness but on the other hand avoid
        the illegal configurations all over.
+- limiting menu display: "visible if" <expr>
+  This attribute is only applicable to menu blocks, if the condition is
+  false, the menu block is not displayed to the user (the symbols
+  contained there can still be selected by other symbols, though). It is
+  similar to a conditional "prompt" attribude for individual menu
+  entries. Default value of "visible" is true.
 - numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
  This allows to limit the range of possible input values for int
  and hex symbols. The user can only input a value which is larger than
@@ -303,7 +310,8 @@ menu:
        "endmenu"
 This defines a menu block, see "Menu structure" above for more
-information. The only possible options are dependencies.
+information. The only possible options are dependencies and "visible"
+attributes.
 if:
@@ -381,3 +389,25 @@ config FOO
 limits FOO to module (=m) or disabled (=n).
+Kconfig symbol existence
+~~~~~~~~~~~~~~~~~~~~~~~~
+The following two methods produce the same kconfig symbol dependencies
+but differ greatly in kconfig symbol existence (production) in the
+generated config file.
+case 1:
+config FOO
+        tristate "about foo"
+        depends on BAR
+vs. case 2:
+if BAR
+config FOO
+        tristate "about foo"
+endif
+In case 1, the symbol FOO will always exist in the config file (given
+no other dependencies).  In case 2, the symbol FOO will only exist in
+the config file if BAR is enabled.
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index cca46b1a0f6..c313d71324b 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -48,11 +48,6 @@ KCONFIG_OVERWRITECONFIG
 If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
 break symlinks when .config is a symlink to somewhere else.
-KCONFIG_NOTIMESTAMP
--------------------------------------------------
-If this environment variable exists and is non-null, the timestamp line
-in generated .config files is omitted.
 ______________________________________________________________________
 Environment variables for '{allyes/allmod/allno/rand}config'
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 5d145bb443c..47435e56c5d 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -40,11 +40,13 @@ This document describes the Linux kernel Makefiles.
           --- 6.6 Commands useful for building a boot image
           --- 6.7 Custom kbuild commands
           --- 6.8 Preprocessing linker scripts
+           --- 6.9 Generic header files
        === 7 Kbuild syntax for exported headers
                --- 7.1 header-y
                --- 7.2 objhdr-y
                --- 7.3 destination-y
+                --- 7.4 generic-y
        === 8 Kbuild Variables
        === 9 Makefile language
@@ -499,6 +501,18 @@ more details, with real examples.
        gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
        Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options
+    cc-disable-warning
+        cc-disable-warning checks if gcc supports a given warning and returns
+        the commandline switch to disable it. This special function is needed,
+        because gcc 4.4 and later accept any unknown -Wno-* option and only
+        warn about it if there is another warning in the source file.
+        Example:
+                KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+        In the above example, -Wno-unused-but-set-variable will be added to
+        KBUILD_CFLAGS only if gcc really accepts it.
    cc-version
        cc-version returns a numerical version of the $(CC) compiler version.
        The format is <major><minor> where both are two digits. So for example
@@ -955,6 +969,11 @@ When kbuild executes, the following steps are followed (roughly):
        used when linking modules. This is often a linker script.
        From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
+    KBUILD_ARFLAGS   Options for $(AR) when creating archives
+        $(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic
+        mode) if this option is supported by $(AR).
 --- 6.2 Add prerequisites to archprepare:
        The archprepare: rule is used to list prerequisites that need to be
@@ -1209,6 +1228,14 @@ When kbuild executes, the following steps are followed (roughly):
        The kbuild infrastructure for *lds file are used in several
        architecture-specific files.
+--- 6.9 Generic header files
+        The directory include/asm-generic contains the header files
+        that may be shared between individual architectures.
+        The recommended approach how to use a generic header file is
+        to list the file in the Kbuild file.
+        See "7.4 generic-y" for further info on syntax etc.
 === 7 Kbuild syntax for exported headers
 The kernel include a set of headers that is exported to userspace.
@@ -1265,6 +1292,32 @@ See subsequent chapter for the syntax of the Kbuild file.
        In the example above all exported headers in the Kbuild file
        will be located in the directory "include/linux" when exported.
+        --- 7.4 generic-y
+        If an architecture uses a verbatim copy of a header from
+        include/asm-generic then this is listed in the file
+        arch/$(ARCH)/include/asm/Kbuild like this:
+                Example:
+                        #arch/x86/include/asm/Kbuild
+                        generic-y += termios.h
+                        generic-y += rtc.h
+        During the prepare phase of the build a wrapper include
+        file is generated in the directory:
+                arch/$(ARCH)/include/generated/asm
+        When a header is exported where the architecture uses
+        the generic header a similar wrapper is generated as part
+        of the set of exported headers in the directory:
+                usr/include/asm
+        The generated wrapper will in both cases look like the following:
+                Example: termios.h
+                        #include <asm-generic/termios.h>
 === 8 Kbuild Variables
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c603ef7b056..5438a2d7907 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1777,9 +1777,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        nosoftlockup    [KNL] Disable the soft-lockup detector.
-        noswapaccount   [KNL] Disable accounting of swap in memory resource
-                        controller. (See Documentation/cgroups/memory.txt)
        nosync          [HW,M68K] Disables sync negotiation for all devices.
        notsc           [BUGS=X86-32] Disable Time Stamp Counter
@@ -2585,6 +2582,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                        bytes of sense data);
                                c = FIX_CAPACITY (decrease the reported
                                        device capacity by one sector);
+                                d = NO_READ_DISC_INFO (don't use
+                                        READ_DISC_INFO command);
+                                e = NO_READ_CAPACITY_16 (don't use
+                                        READ_CAPACITY_16 command);
                                h = CAPACITY_HEURISTICS (decrease the
                                        reported device capacity by one
                                        sector if the number is odd);
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt
index 65f4c795015..9c0a80d17a2 100644
--- a/Documentation/lockstat.txt
+++ b/Documentation/lockstat.txt
@@ -136,7 +136,7 @@ View the top contending locks:
                             dcache_lock:          1037           1161           0.38          45.32         774.51           6611         243371           0.15         306.48       77387.24
                         &inode->i_mutex:           161            286 18446744073709       62882.54     1244614.55           3653          20598 18446744073709       62318.60     1693822.74
                         &zone->lru_lock:            94             94           0.53           7.33          92.10           4366          32690           0.29          59.81       16350.06
-              &inode->i_data.i_mmap_lock:            79             79           0.40           3.77          53.03          11779          87755           0.28         116.93       29898.44
+              &inode->i_data.i_mmap_mutex:            79             79           0.40           3.77          53.03          11779          87755           0.28         116.93       29898.44
                        &q->__queue_lock:            48             50           0.52          31.62          86.31            774          13131           0.17         113.08       12277.52
                        &rq->rq_lock_key:            43             47           0.74          68.50         170.63           3706          33929           0.22         107.99       17460.62
                      &rq->rq_lock_key#2:            39             46           0.75           6.68          49.03           2979          32292           0.17         125.17       17137.63
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index fca586f5b85..93dd7a71407 100644
--- a/Documentation/mmc/00-INDEX
+++ b/Documentation/mmc/00-INDEX
@@ -2,3 +2,5 @@
        - this file
 mmc-dev-attrs.txt
        - info on SD and MMC device attributes
+mmc-dev-parts.txt
+        - info on SD and MMC device partitions
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index ff2bd685bce..8898a95b41e 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -1,3 +1,13 @@
+SD and MMC Block Device Attributes
+==================================
+These attributes are defined for the block devices associated with the
+SD or MMC device.
+The following attributes are read/write.
+        force_ro                Enforce read-only access even if write protect switch is off.
 SD and MMC Device Attributes
 ============================
diff --git a/Documentation/mmc/mmc-dev-parts.txt b/Documentation/mmc/mmc-dev-parts.txt
new file mode 100644
index 00000000000..2db28b8e662
--- /dev/null
+++ b/Documentation/mmc/mmc-dev-parts.txt
@@ -0,0 +1,27 @@
+SD and MMC Device Partitions
+============================
+Device partitions are additional logical block devices present on the
+SD/MMC device.
+As of this writing, MMC boot partitions as supported and exposed as
+/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
+parent /dev/mmcblkX.
+MMC Boot Partitions
+===================
+Read and write access is provided to the two MMC boot partitions. Due to
+the sensitive nature of the boot partition contents, which often store
+a bootloader or bootloader configuration tables crucial to booting the
+platform, write access is disabled by default to reduce the chance of
+accidental bricking.
+To enable write access to /dev/mmcblkXbootY, disable the forced read-only
+access with:
+echo 0 > /sys/block/mmcblkXbootY/force_ro
+To re-enable read-only access:
+echo 1 > /sys/block/mmcblkXbootY/force_ro
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1f45bd887d6..675612ff41a 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -770,8 +770,17 @@ resend_igmp
        a failover event. One membership report is issued immediately after
        the failover, subsequent packets are sent in each 200ms interval.
-        The valid range is 0 - 255; the default value is 1. This option
+        The valid range is 0 - 255; the default value is 1. A value of 0
-        was added for bonding version 3.7.0.
+        prevents the IGMP membership report from being issued in response
+        to the failover event.
+        This option is useful for bonding modes balance-rr (0), active-backup
+        (1), balance-tlb (5) and balance-alb (6), in which a failover can
+        switch the IGMP traffic from one slave to another.  Therefore a fresh
+        IGMP report must be issued to cause the switch to forward the incoming
+        IGMP traffic over the newly selected slave.
+        This option was added for bonding version 3.7.0.
 3. Configuring Bonding Devices
 ==============================
diff --git a/Documentation/pti/pti_intel_mid.txt b/Documentation/pti/pti_intel_mid.txt
new file mode 100644
index 00000000000..e7a5b6d1f7a
--- /dev/null
+++ b/Documentation/pti/pti_intel_mid.txt
@@ -0,0 +1,99 @@
+The Intel MID PTI project is HW implemented in Intel Atom
+system-on-a-chip designs based on the Parallel Trace
+Interface for MIPI P1149.7 cJTAG standard.  The kernel solution
+for this platform involves the following files:
+./include/linux/pti.h
+./drivers/.../n_tracesink.h
+./drivers/.../n_tracerouter.c
+./drivers/.../n_tracesink.c
+./drivers/.../pti.c
+pti.c is the driver that enables various debugging features
+popular on platforms from certain mobile manufacturers.
+n_tracerouter.c and n_tracesink.c allow extra system information to
+be collected and routed to the pti driver, such as trace
+debugging data from a modem.  Although n_tracerouter
+and n_tracesink are a part of the complete PTI solution,
+these two line disciplines can work separately from
+pti.c and route any data stream from one /dev/tty node
+to another /dev/tty node via kernel-space.  This provides
+a stable, reliable connection that will not break unless
+the user-space application shuts down (plus avoids
+kernel->user->kernel context switch overheads of routing
+data).
+An example debugging usage for this driver system:
+   *Hook /dev/ttyPTI0 to syslogd.  Opening this port will also start
+    a console device to further capture debugging messages to PTI.
+   *Hook /dev/ttyPTI1 to modem debugging data to write to PTI HW.
+    This is where n_tracerouter and n_tracesink are used.
+   *Hook /dev/pti to a user-level debugging application for writing
+    to PTI HW.
+   *Use mipi_* Kernel Driver API in other device drivers for
+    debugging to PTI by first requesting a PTI write address via
+    mipi_request_masterchannel(1).
+Below is example pseudo-code on how a 'privileged' application
+can hook up n_tracerouter and n_tracesink to any tty on
+a system.  'Privileged' means the application has enough
+privileges to successfully manipulate the ldisc drivers
+but is not just blindly executing as 'root'. Keep in mind
+the use of ioctl(,TIOCSETD,) is not specific to the n_tracerouter
+and n_tracesink line discpline drivers but is a generic
+operation for a program to use a line discpline driver
+on a tty port other than the default n_tty.
+/////////// To hook up n_tracerouter and n_tracesink /////////
+// Note that n_tracerouter depends on n_tracesink.
+#include <errno.h>
+#define ONE_TTY "/dev/ttyOne"
+#define TWO_TTY "/dev/ttyTwo"
+// needed global to hand onto ldisc connection
+static int g_fd_source = -1;
+static int g_fd_sink  = -1;
+// these two vars used to grab LDISC values from loaded ldisc drivers
+// in OS.  Look at /proc/tty/ldiscs to get the right numbers from
+// the ldiscs loaded in the system.
+int source_ldisc_num, sink_ldisc_num = -1;
+int retval;
+g_fd_source = open(ONE_TTY, O_RDWR); // must be R/W
+g_fd_sink   = open(TWO_TTY, O_RDWR); // must be R/W
+if (g_fd_source <= 0) || (g_fd_sink <= 0) {
+   // doubt you'll want to use these exact error lines of code
+   printf("Error on open(). errno: %d\n",errno);
+   return errno;
+}
+retval = ioctl(g_fd_sink, TIOCSETD, &sink_ldisc_num);
+if (retval < 0) {
+   printf("Error on ioctl().  errno: %d\n", errno);
+   return errno;
+}
+retval = ioctl(g_fd_source, TIOCSETD, &source_ldisc_num);
+if (retval < 0) {
+   printf("Error on ioctl().  errno: %d\n", errno);
+   return errno;
+}
+/////////// To disconnect n_tracerouter and n_tracesink ////////
+// First make sure data through the ldiscs has stopped.
+// Second, disconnect ldiscs.  This provides a
+// little cleaner shutdown on tty stack.
+sink_ldisc_num = 0;
+source_ldisc_num = 0;
+ioctl(g_fd_uart, TIOCSETD, &sink_ldisc_num);
+ioctl(g_fd_gadget, TIOCSETD, &source_ldisc_num);
+// Three, program closes connection, and cleanup:
+close(g_fd_uart);
+close(g_fd_gadget);
+g_fd_uart = g_fd_gadget = NULL;
diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt
new file mode 100644
index 00000000000..ae8fef86b83
--- /dev/null
+++ b/Documentation/ptp/ptp.txt
@@ -0,0 +1,89 @@
+* PTP hardware clock infrastructure for Linux
+  This patch set introduces support for IEEE 1588 PTP clocks in
+  Linux. Together with the SO_TIMESTAMPING socket options, this
+  presents a standardized method for developing PTP user space
+  programs, synchronizing Linux with external clocks, and using the
+  ancillary features of PTP hardware clocks.
+  A new class driver exports a kernel interface for specific clock
+  drivers and a user space interface. The infrastructure supports a
+  complete set of PTP hardware clock functionality.
+  + Basic clock operations
+    - Set time
+    - Get time
+    - Shift the clock by a given offset atomically
+    - Adjust clock frequency
+  + Ancillary clock features
+    - One short or periodic alarms, with signal delivery to user program
+    - Time stamp external events
+    - Period output signals configurable from user space
+    - Synchronization of the Linux system time via the PPS subsystem
+** PTP hardware clock kernel API
+   A PTP clock driver registers itself with the class driver. The
+   class driver handles all of the dealings with user space. The
+   author of a clock driver need only implement the details of
+   programming the clock hardware. The clock driver notifies the class
+   driver of asynchronous events (alarms and external time stamps) via
+   a simple message passing interface.
+   The class driver supports multiple PTP clock drivers. In normal use
+   cases, only one PTP clock is needed. However, for testing and
+   development, it can be useful to have more than one clock in a
+   single system, in order to allow performance comparisons.
+** PTP hardware clock user space API
+   The class driver also creates a character device for each
+   registered clock. User space can use an open file descriptor from
+   the character device as a POSIX clock id and may call
+   clock_gettime, clock_settime, and clock_adjtime.  These calls
+   implement the basic clock operations.
+   User space programs may control the clock using standardized
+   ioctls. A program may query, enable, configure, and disable the
+   ancillary clock features. User space can receive time stamped
+   events via blocking read() and poll(). One shot and periodic
+   signals may be configured via the POSIX timer_settime() system
+   call.
+** Writing clock drivers
+   Clock drivers include include/linux/ptp_clock_kernel.h and register
+   themselves by presenting a 'struct ptp_clock_info' to the
+   registration method. Clock drivers must implement all of the
+   functions in the interface. If a clock does not offer a particular
+   ancillary feature, then the driver should just return -EOPNOTSUPP
+   from those functions.
+   Drivers must ensure that all of the methods in interface are
+   reentrant. Since most hardware implementations treat the time value
+   as a 64 bit integer accessed as two 32 bit registers, drivers
+   should use spin_lock_irqsave/spin_unlock_irqrestore to protect
+   against concurrent access. This locking cannot be accomplished in
+   class driver, since the lock may also be needed by the clock
+   driver's interrupt service routine.
+** Supported hardware
+   + Freescale eTSEC gianfar
+     - 2 Time stamp external triggers, programmable polarity (opt. interrupt)
+     - 2 Alarm registers (optional interrupt)
+     - 3 Periodic signals (optional interrupt)
+   + National DP83640
+     - 6 GPIOs programmable as inputs or outputs
+     - 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be
+       used as general inputs or outputs
+     - GPIO inputs can time stamp external triggers
+     - GPIO outputs can produce periodic signals
+     - 1 interrupt pin
+   + Intel IXP465
+     - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
+     - Target Time (optional interrupt)
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
new file mode 100644
index 00000000000..f59ded06610
--- /dev/null
+++ b/Documentation/ptp/testptp.c
@@ -0,0 +1,381 @@
+/*
+ * PTP 1588 clock support - User space test program
+ *
+ * Copyright (C) 2010 OMICRON electronics GmbH
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include <errno.h>
+#include <fcntl.h>
+#include <math.h>
+#include <signal.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <sys/time.h>
+#include <sys/timex.h>
+#include <sys/types.h>
+#include <time.h>
+#include <unistd.h>
+#include <linux/ptp_clock.h>
+#define DEVICE "/dev/ptp0"
+#ifndef ADJ_SETOFFSET
+#define ADJ_SETOFFSET 0x0100
+#endif
+#ifndef CLOCK_INVALID
+#define CLOCK_INVALID -1
+#endif
+/* When glibc offers the syscall, this will go away. */
+#include <sys/syscall.h>
+static int clock_adjtime(clockid_t id, struct timex *tx)
+{
+        return syscall(__NR_clock_adjtime, id, tx);
+}
+static clockid_t get_clockid(int fd)
+{
+#define CLOCKFD 3
+#define FD_TO_CLOCKID(fd)       ((~(clockid_t) (fd) << 3) | CLOCKFD)
+        return FD_TO_CLOCKID(fd);
+}
+static void handle_alarm(int s)
+{
+        printf("received signal %d\n", s);
+}
+static int install_handler(int signum, void (*handler)(int))
+{
+        struct sigaction action;
+        sigset_t mask;
+        /* Unblock the signal. */
+        sigemptyset(&mask);
+        sigaddset(&mask, signum);
+        sigprocmask(SIG_UNBLOCK, &mask, NULL);
+        /* Install the signal handler. */
+        action.sa_handler = handler;
+        action.sa_flags = 0;
+        sigemptyset(&action.sa_mask);
+        sigaction(signum, &action, NULL);
+        return 0;
+}
+static long ppb_to_scaled_ppm(int ppb)
+{
+        /*
+         * The 'freq' field in the 'struct timex' is in parts per
+         * million, but with a 16 bit binary fractional field.
+         * Instead of calculating either one of
+         *
+         *    scaled_ppm = (ppb / 1000) << 16  [1]
+         *    scaled_ppm = (ppb << 16) / 1000  [2]
+         *
+         * we simply use double precision math, in order to avoid the
+         * truncation in [1] and the possible overflow in [2].
+         */
+        return (long) (ppb * 65.536);
+}
+static void usage(char *progname)
+{
+        fprintf(stderr,
+                "usage: %s [options]\n"
+                " -a val     request a one-shot alarm after 'val' seconds\n"
+                " -A val     request a periodic alarm every 'val' seconds\n"
+                " -c         query the ptp clock's capabilities\n"
+                " -d name    device to open\n"
+                " -e val     read 'val' external time stamp events\n"
+                " -f val     adjust the ptp clock frequency by 'val' ppb\n"
+                " -g         get the ptp clock time\n"
+                " -h         prints this message\n"
+                " -p val     enable output with a period of 'val' nanoseconds\n"
+                " -P val     enable or disable (val=1|0) the system clock PPS\n"
+                " -s         set the ptp clock time from the system time\n"
+                " -S         set the system time from the ptp clock time\n"
+                " -t val     shift the ptp clock time by 'val' seconds\n",
+                progname);
+}
+int main(int argc, char *argv[])
+{
+        struct ptp_clock_caps caps;
+        struct ptp_extts_event event;
+        struct ptp_extts_request extts_request;
+        struct ptp_perout_request perout_request;
+        struct timespec ts;
+        struct timex tx;
+        static timer_t timerid;
+        struct itimerspec timeout;
+        struct sigevent sigevent;
+        char *progname;
+        int c, cnt, fd;
+        char *device = DEVICE;
+        clockid_t clkid;
+        int adjfreq = 0x7fffffff;
+        int adjtime = 0;
+        int capabilities = 0;
+        int extts = 0;
+        int gettime = 0;
+        int oneshot = 0;
+        int periodic = 0;
+        int perout = -1;
+        int pps = -1;
+        int settime = 0;
+        progname = strrchr(argv[0], '/');
+        progname = progname ? 1+progname : argv[0];
+        while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+                switch (c) {
+                case 'a':
+                        oneshot = atoi(optarg);
+                        break;
+                case 'A':
+                        periodic = atoi(optarg);
+                        break;
+                case 'c':
+                        capabilities = 1;
+                        break;
+                case 'd':
+                        device = optarg;
+                        break;
+                case 'e':
+                        extts = atoi(optarg);
+                        break;
+                case 'f':
+                        adjfreq = atoi(optarg);
+                        break;
+                case 'g':
+                        gettime = 1;
+                        break;
+                case 'p':
+                        perout = atoi(optarg);
+                        break;
+                case 'P':
+                        pps = atoi(optarg);
+                        break;
+                case 's':
+                        settime = 1;
+                        break;
+                case 'S':
+                        settime = 2;
+                        break;
+                case 't':
+                        adjtime = atoi(optarg);
+                        break;
+                case 'h':
+                        usage(progname);
+                        return 0;
+                case '?':
+                default:
+                        usage(progname);
+                        return -1;
+                }
+        }
+        fd = open(device, O_RDWR);
+        if (fd < 0) {
+                fprintf(stderr, "opening %s: %s\n", device, strerror(errno));
+                return -1;
+        }
+        clkid = get_clockid(fd);
+        if (CLOCK_INVALID == clkid) {
+                fprintf(stderr, "failed to read clock id\n");
+                return -1;
+        }
+        if (capabilities) {
+                if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) {
+                        perror("PTP_CLOCK_GETCAPS");
+                } else {
+                        printf("capabilities:\n"
+                               "  %d maximum frequency adjustment (ppb)\n"
+                               "  %d programmable alarms\n"
+                               "  %d external time stamp channels\n"
+                               "  %d programmable periodic signals\n"
+                               "  %d pulse per second\n",
+                               caps.max_adj,
+                               caps.n_alarm,
+                               caps.n_ext_ts,
+                               caps.n_per_out,
+                               caps.pps);
+                }
+        }
+        if (0x7fffffff != adjfreq) {
+                memset(&tx, 0, sizeof(tx));
+                tx.modes = ADJ_FREQUENCY;
+                tx.freq = ppb_to_scaled_ppm(adjfreq);
+                if (clock_adjtime(clkid, &tx)) {
+                        perror("clock_adjtime");
+                } else {
+                        puts("frequency adjustment okay");
+                }
+        }
+        if (adjtime) {
+                memset(&tx, 0, sizeof(tx));
+                tx.modes = ADJ_SETOFFSET;
+                tx.time.tv_sec = adjtime;
+                tx.time.tv_usec = 0;
+                if (clock_adjtime(clkid, &tx) < 0) {
+                        perror("clock_adjtime");
+                } else {
+                        puts("time shift okay");
+                }
+        }
+        if (gettime) {
+                if (clock_gettime(clkid, &ts)) {
+                        perror("clock_gettime");
+                } else {
+                        printf("clock time: %ld.%09ld or %s",
+                               ts.tv_sec, ts.tv_nsec, ctime(&ts.tv_sec));
+                }
+        }
+        if (settime == 1) {
+                clock_gettime(CLOCK_REALTIME, &ts);
+                if (clock_settime(clkid, &ts)) {
+                        perror("clock_settime");
+                } else {
+                        puts("set time okay");
+                }
+        }
+        if (settime == 2) {
+                clock_gettime(clkid, &ts);
+                if (clock_settime(CLOCK_REALTIME, &ts)) {
+                        perror("clock_settime");
+                } else {
+                        puts("set time okay");
+                }
+        }
+        if (extts) {
+                memset(&extts_request, 0, sizeof(extts_request));
+                extts_request.index = 0;
+                extts_request.flags = PTP_ENABLE_FEATURE;
+                if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
+                        perror("PTP_EXTTS_REQUEST");
+                        extts = 0;
+                } else {
+                        puts("external time stamp request okay");
+                }
+                for (; extts; extts--) {
+                        cnt = read(fd, &event, sizeof(event));
+                        if (cnt != sizeof(event)) {
+                                perror("read");
+                                break;
+                        }
+                        printf("event index %u at %lld.%09u\n", event.index,
+                               event.t.sec, event.t.nsec);
+                        fflush(stdout);
+                }
+                /* Disable the feature again. */
+                extts_request.flags = 0;
+                if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
+                        perror("PTP_EXTTS_REQUEST");
+                }
+        }
+        if (oneshot) {
+                install_handler(SIGALRM, handle_alarm);
+                /* Create a timer. */
+                sigevent.sigev_notify = SIGEV_SIGNAL;
+                sigevent.sigev_signo = SIGALRM;
+                if (timer_create(clkid, &sigevent, &timerid)) {
+                        perror("timer_create");
+                        return -1;
+                }
+                /* Start the timer. */
+                memset(&timeout, 0, sizeof(timeout));
+                timeout.it_value.tv_sec = oneshot;
+                if (timer_settime(timerid, 0, &timeout, NULL)) {
+                        perror("timer_settime");
+                        return -1;
+                }
+                pause();
+                timer_delete(timerid);
+        }
+        if (periodic) {
+                install_handler(SIGALRM, handle_alarm);
+                /* Create a timer. */
+                sigevent.sigev_notify = SIGEV_SIGNAL;
+                sigevent.sigev_signo = SIGALRM;
+                if (timer_create(clkid, &sigevent, &timerid)) {
+                        perror("timer_create");
+                        return -1;
+                }
+                /* Start the timer. */
+                memset(&timeout, 0, sizeof(timeout));
+                timeout.it_interval.tv_sec = periodic;
+                timeout.it_value.tv_sec = periodic;
+                if (timer_settime(timerid, 0, &timeout, NULL)) {
+                        perror("timer_settime");
+                        return -1;
+                }
+                while (1) {
+                        pause();
+                }
+                timer_delete(timerid);
+        }
+        if (perout >= 0) {
+                if (clock_gettime(clkid, &ts)) {
+                        perror("clock_gettime");
+                        return -1;
+                }
+                memset(&perout_request, 0, sizeof(perout_request));
+                perout_request.index = 0;
+                perout_request.start.sec = ts.tv_sec + 2;
+                perout_request.start.nsec = 0;
+                perout_request.period.sec = 0;
+                perout_request.period.nsec = perout;
+                if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) {
+                        perror("PTP_PEROUT_REQUEST");
+                } else {
+                        puts("periodic output request okay");
+                }
+        }
+        if (pps != -1) {
+                int enable = pps ? 1 : 0;
+                if (ioctl(fd, PTP_ENABLE_PPS, enable)) {
+                        perror("PTP_ENABLE_PPS");
+                } else {
+                        puts("pps for system time request okay");
+                }
+        }
+        close(fd);
+        return 0;
+}
diff --git a/Documentation/ptp/testptp.mk b/Documentation/ptp/testptp.mk
new file mode 100644
index 00000000000..4ef2d975542
--- /dev/null
+++ b/Documentation/ptp/testptp.mk
@@ -0,0 +1,33 @@
+# PTP 1588 clock support - User space test program
+#
+# Copyright (C) 2010 OMICRON electronics GmbH
+#
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program; if not, write to the Free Software
+#  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+CC        = $(CROSS_COMPILE)gcc
+INC       = -I$(KBUILD_OUTPUT)/usr/include
+CFLAGS    = -Wall $(INC)
+LDLIBS    = -lrt
+PROGS     = testptp
+all: $(PROGS)
+testptp: testptp.o
+clean:
+        rm -f testptp.o
+distclean: clean
+        rm -f $(PROGS)
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 9822afb6313..89757012c7f 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -1230,6 +1230,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
    This module supports multiple cards.
    The driver requires the firmware loader support on kernel.
+  Module snd-lola
+  ---------------
+    Module for Digigram Lola PCI-e boards
+    This module supports multiple cards.
  Module snd-lx6464es
  -------------------
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 0caf77e59be..d70c93bdcad 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -94,7 +94,7 @@ ALC662/663/272
  3stack-dig    3-stack (2-channel) with SPDIF
  3stack-6ch     3-stack (6-channel)
  3stack-6ch-dig 3-stack (6-channel) with SPDIF
-  6stack-dig     6-stack with SPDIF
+  5stack-dig     5-stack with SPDIF
  lenovo-101e    Lenovo laptop
  eeepc-p701    ASUS Eeepc P701
  eeepc-ep20    ASUS Eeepc EP20
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
index 847b342b7b2..db3be892afb 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -122,7 +122,7 @@ operating system to suffer.
 In both of these instances, all developers agreed that these were
 important changes that needed to be made, and they were made, with
-relatively little pain.  If Linux had to ensure that it preserve a
+relatively little pain.  If Linux had to ensure that it will preserve a
 stable source interface, a new interface would have been created, and
 the older, broken one would have had to be maintained over time, leading
 to extra work for the USB developers.  Since all Linux USB developers do
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 4af0614147e..88fd7f5c8dc 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -231,13 +231,6 @@ its creation).
 This directory contains configuration options for the epoll(7) interface.
-max_user_instances
------------------
-This is the maximum number of epoll file descriptors that a single user can
-have open at a given time. The default value is 128, and should be enough
-for normal users.
 max_user_watches
 ----------------
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 30289fab86e..96f0ee825be 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -481,10 +481,10 @@ the DMA zone.
 Type(A) is called as "Node" order. Type (B) is "Zone" order.
 "Node order" orders the zonelists by node, then by zone within each node.
-Specify "[Nn]ode" for zone order
+Specify "[Nn]ode" for node order
 "Zone Order" orders the zonelists by zone type, then by node within each
-zone.  Specify "[Zz]one"for zode order.
+zone.  Specify "[Zz]one" for zone order.
 Specify "[Dd]efault" to request automatic configuration.  Autoconfiguration
 will select "node" order in following case.
diff --git a/Documentation/timers/timers-howto.txt b/Documentation/timers/timers-howto.txt
index c9ef29d2ede..038f8c77a07 100644
--- a/Documentation/timers/timers-howto.txt
+++ b/Documentation/timers/timers-howto.txt
@@ -24,7 +24,7 @@ ATOMIC CONTEXT:
        ndelay(unsigned long nsecs)
        udelay(unsigned long usecs)
-        mdelay(unsgined long msecs)
+        mdelay(unsigned long msecs)
        udelay is the generally preferred API; ndelay-level
        precision may not actually exist on many non-PC devices.
diff --git a/Documentation/usb/callbacks.txt b/Documentation/usb/callbacks.txt
index bfb36b34b79..9e85846bdb9 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/usb/callbacks.txt
@@ -95,9 +95,11 @@ pre_reset
 int (*pre_reset)(struct usb_interface *intf);
-Another driver or user space is triggering a reset on the device which
+A driver or user space is triggering a reset on the device which
-contains the interface passed as an argument. Cease IO and save any
+contains the interface passed as an argument. Cease IO, wait for all
-device state you need to restore.
+outstanding URBs to complete, and save any device state you need to
+restore.  No more URBs may be submitted until the post_reset method
+is called.
 If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
 are in atomic context.
diff --git a/Documentation/usb/linux-cdc-acm.inf b/Documentation/usb/linux-cdc-acm.inf
index 612e7220fb2..37a02ce5484 100644
--- a/Documentation/usb/linux-cdc-acm.inf
+++ b/Documentation/usb/linux-cdc-acm.inf
@@ -90,10 +90,10 @@ ServiceBinary=%12%\USBSER.sys
 [SourceDisksFiles]
 [SourceDisksNames]
 [DeviceList]
-%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02
+%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02
 [DeviceList.NTamd64]
-%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02
+%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02
 ;------------------------------------------------------------------------------
diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf
index 4dee9585122..4ffa715b0ae 100644
--- a/Documentation/usb/linux.inf
+++ b/Documentation/usb/linux.inf
@@ -18,15 +18,15 @@ DriverVer           = 06/21/2006,6.0.6000.16384
 ; Decoration for x86 architecture
 [LinuxDevices.NTx86]
-%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00
+%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00
 ; Decoration for x64 architecture
 [LinuxDevices.NTamd64]
-%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00
+%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00
 ; Decoration for ia64 architecture
 [LinuxDevices.NTia64]
-%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00
+%LinuxDevice%       = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_1d6b&PID_0104&MI_00
 ;@@@ This is the common setting for setup
 [ControlFlags]
diff --git a/Documentation/vgaarbiter.txt b/Documentation/vgaarbiter.txt
index 43a9b0694fd..b7d401e0eae 100644
--- a/Documentation/vgaarbiter.txt
+++ b/Documentation/vgaarbiter.txt
@@ -14,11 +14,10 @@ the legacy VGA arbitration task (besides other bus management tasks) when more
 than one legacy device co-exists on the same machine. But the problem happens
 when these devices are trying to be accessed by different userspace clients
 (e.g. two server in parallel). Their address assignments conflict. Moreover,
-ideally, being an userspace application, it is not the role of the the X
+ideally, being a userspace application, it is not the role of the X server to
-server to control bus resources. Therefore an arbitration scheme outside of
+control bus resources. Therefore an arbitration scheme outside of the X server
-the X server is needed to control the sharing of these resources. This
+is needed to control the sharing of these resources. This document introduces
-document introduces the operation of the VGA arbiter implemented for Linux
+the operation of the VGA arbiter implemented for the Linux kernel.
-kernel.
 ----------------------------------------------------------------------------
@@ -39,7 +38,7 @@ I.1 vgaarb
 The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
 scans all PCI devices and adds the VGA ones inside the arbitration. The
 arbiter then enables/disables the decoding on different devices of the VGA
-legacy instructions. Device which do not want/need to use the arbiter may
+legacy instructions. Devices which do not want/need to use the arbiter may
 explicitly tell it by calling vga_set_legacy_decoding().
 The kernel exports a char device interface (/dev/vga_arbiter) to the clients,
@@ -95,8 +94,8 @@ In the case of devices hot-{un,}plugged, there is a hook - pci_notify() - to
 notify them being added/removed in the system and automatically added/removed
 in the arbiter.
-There's also a in-kernel API of the arbiter in the case of DRM, vgacon and
+There is also an in-kernel API of the arbiter in case DRM, vgacon, or other
-others which may use the arbiter.
+drivers want to use it.
 I.2 libpciaccess
@@ -117,9 +116,8 @@ Besides it, in pci_system were added:
    struct pci_device *vga_default_dev;
-The vga_count is usually need to keep informed how many cards are being
+The vga_count is used to track how many cards are being arbitrated, so for
-arbitrated, so for instance if there's only one then it can totally escape the
+instance, if there is only one card, then it can completely escape arbitration.
-scheme.
 These functions below acquire VGA resources for the given card and mark those
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 31b485723bc..9aae449440d 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -54,7 +54,7 @@
 53 -> Pinnacle Hybrid Pro                      (em2881)
 54 -> Kworld VS-DVB-T 323UR                    (em2882)        [eb1a:e323]
 55 -> Terratec Cinnergy Hybrid T USB XS (em2882) (em2882)        [0ccd:005e,0ccd:0042]
- 56 -> Pinnacle Hybrid Pro (2)                  (em2882)        [2304:0226]
+ 56 -> Pinnacle Hybrid Pro (330e)               (em2882)        [2304:0226]
 57 -> Kworld PlusTV HD Hybrid 330              (em2883)        [eb1a:a316]
 58 -> Compro VideoMate ForYou/Stereo           (em2820/em2840) [185b:2041]
 60 -> Hauppauge WinTV HVR 850                  (em2883)        [2040:651f]
diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran
index c40e3bab08f..9ed629d4874 100644
--- a/Documentation/video4linux/Zoran
+++ b/Documentation/video4linux/Zoran
@@ -130,7 +130,6 @@ Card number: 4
 Note: No module for the mse3000 is available yet
 Note: No module for the vpx3224 is available yet
-Note: use encoder=X or decoder=X for non-default i2c chips
 ===========================
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 5c542e60f51..5bfa9a777d2 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -275,6 +275,7 @@ pac7302		093a:2629	Genious iSlim 300
 pac7302         093a:262a       Webcam 300k
 pac7302         093a:262c       Philips SPC 230 NC
 jeilinj         0979:0280       Sakar 57379
+jeilinj         0979:0280       Sportscam DV15
 zc3xx           0ac8:0302       Z-star Vimicro zc0302
 vc032x          0ac8:0321       Vimicro generic vc0321
 vc032x          0ac8:0323       Vimicro Vc0323
diff --git a/Documentation/video4linux/uvcvideo.txt b/Documentation/video4linux/uvcvideo.txt
new file mode 100644
index 00000000000..848d620dcc5
--- /dev/null
+++ b/Documentation/video4linux/uvcvideo.txt
@@ -0,0 +1,239 @@
+Linux USB Video Class (UVC) driver
+==================================
+This file documents some driver-specific aspects of the UVC driver, such as
+driver-specific ioctls and implementation notes.
+Questions and remarks can be sent to the Linux UVC development mailing list at
+linux-uvc-devel@lists.berlios.de.
+Extension Unit (XU) support
+---------------------------
+1. Introduction
+The UVC specification allows for vendor-specific extensions through extension
+units (XUs). The Linux UVC driver supports extension unit controls (XU controls)
+through two separate mechanisms:
+  - through mappings of XU controls to V4L2 controls
+  - through a driver-specific ioctl interface
+The first one allows generic V4L2 applications to use XU controls by mapping
+certain XU controls onto V4L2 controls, which then show up during ordinary
+control enumeration.
+The second mechanism requires uvcvideo-specific knowledge for the application to
+access XU controls but exposes the entire UVC XU concept to user space for
+maximum flexibility.
+Both mechanisms complement each other and are described in more detail below.
+2. Control mappings
+The UVC driver provides an API for user space applications to define so-called
+control mappings at runtime. These allow for individual XU controls or byte
+ranges thereof to be mapped to new V4L2 controls. Such controls appear and
+function exactly like normal V4L2 controls (i.e. the stock controls, such as
+brightness, contrast, etc.). However, reading or writing of such a V4L2 controls
+triggers a read or write of the associated XU control.
+The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP.
+Previous driver versions (before 0.2.0) required another ioctl to be used
+beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver.
+This is no longer necessary as newer uvcvideo versions query the information
+directly from the device.
+For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled
+"IOCTL reference" below.
+3. Driver specific XU control interface
+For applications that need to access XU controls directly, e.g. for testing
+purposes, firmware upload, or accessing binary controls, a second mechanism to
+access XU controls is provided in the form of a driver-specific ioctl, namely
+UVCIOC_CTRL_QUERY.
+A call to this ioctl allows applications to send queries to the UVC driver that
+directly map to the low-level UVC control requests.
+In order to make such a request the UVC unit ID of the control's extension unit
+and the control selector need to be known. This information either needs to be
+hardcoded in the application or queried using other ways such as by parsing the
+UVC descriptor or, if available, using the media controller API to enumerate a
+device's entities.
+Unless the control size is already known it is necessary to first make a
+UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer
+and set the buffer size to the correct value. Similarly, to find out whether
+UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a
+UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET
+supported) of the resulting byte indicate which requests are valid.
+With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and
+UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a
+subset of the former ioctl. For the time being they are still supported but
+application developers are encouraged to use UVCIOC_CTRL_QUERY instead.
+For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled
+"IOCTL reference" below.
+4. Security
+The API doesn't currently provide a fine-grained access control facility. The
+UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions.
+Suggestions on how to improve this are welcome.
+5. Debugging
+In order to debug problems related to XU controls or controls in general it is
+recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'.
+This causes extra output to be written into the system log.
+6. IOCTL reference
+---- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ----
+Argument: struct uvc_xu_control_mapping
+Description:
+        This ioctl creates a mapping between a UVC control or part of a UVC
+        control and a V4L2 control. Once mappings are defined, userspace
+        applications can access vendor-defined UVC control through the V4L2
+        control API.
+        To create a mapping, applications fill the uvc_xu_control_mapping
+        structure with information about an existing UVC control defined with
+        UVCIOC_CTRL_ADD and a new V4L2 control.
+        A UVC control can be mapped to several V4L2 controls. For instance,
+        a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
+        controls. The UVC control is divided into non overlapping fields using
+        the 'size' and 'offset' fields and are then independantly mapped to
+        V4L2 control.
+        For signed integer V4L2 controls the data_type field should be set to
+        UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored.
+Return value:
+        On success 0 is returned. On error -1 is returned and errno is set
+        appropriately.
+        ENOMEM
+                Not enough memory to perform the operation.
+        EPERM
+                Insufficient privileges (super user privileges are required).
+        EINVAL
+                No such UVC control.
+        EOVERFLOW
+                The requested offset and size would overflow the UVC control.
+        EEXIST
+                Mapping already exists.
+Data types:
+        * struct uvc_xu_control_mapping
+        __u32   id              V4L2 control identifier
+        __u8    name[32]        V4L2 control name
+        __u8    entity[16]      UVC extension unit GUID
+        __u8    selector        UVC control selector
+        __u8    size            V4L2 control size (in bits)
+        __u8    offset          V4L2 control offset (in bits)
+        enum v4l2_ctrl_type
+                v4l2_type       V4L2 control type
+        enum uvc_control_data_type
+                data_type       UVC control data type
+        struct uvc_menu_info
+                *menu_info      Array of menu entries (for menu controls only)
+        __u32   menu_count      Number of menu entries (for menu controls only)
+        * struct uvc_menu_info
+        __u32   value           Menu entry value used by the device
+        __u8    name[32]        Menu entry name
+        * enum uvc_control_data_type
+        UVC_CTRL_DATA_TYPE_RAW          Raw control (byte array)
+        UVC_CTRL_DATA_TYPE_SIGNED       Signed integer
+        UVC_CTRL_DATA_TYPE_UNSIGNED     Unsigned integer
+        UVC_CTRL_DATA_TYPE_BOOLEAN      Boolean
+        UVC_CTRL_DATA_TYPE_ENUM         Enumeration
+        UVC_CTRL_DATA_TYPE_BITMASK      Bitmask
+---- UVCIOC_CTRL_QUERY - Query a UVC XU control ----
+Argument: struct uvc_xu_control_query
+Description:
+        This ioctl queries a UVC XU control identified by its extension unit ID
+        and control selector.
+        There are a number of different queries available that closely
+        correspond to the low-level control requests described in the UVC
+        specification. These requests are:
+        UVC_GET_CUR
+                Obtain the current value of the control.
+        UVC_GET_MIN
+                Obtain the minimum value of the control.
+        UVC_GET_MAX
+                Obtain the maximum value of the control.
+        UVC_GET_DEF
+                Obtain the default value of the control.
+        UVC_GET_RES
+                Query the resolution of the control, i.e. the step size of the
+                allowed control values.
+        UVC_GET_LEN
+                Query the size of the control in bytes.
+        UVC_GET_INFO
+                Query the control information bitmap, which indicates whether
+                get/set requests are supported.
+        UVC_SET_CUR
+                Update the value of the control.
+        Applications must set the 'size' field to the correct length for the
+        control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for
+        which the size must be set to 2 and 1, respectively. The 'data' field
+        must point to a valid writable buffer big enough to hold the indicated
+        number of data bytes.
+        Data is copied directly from the device without any driver-side
+        processing. Applications are responsible for data buffer formatting,
+        including little-endian/big-endian conversion. This is particularly
+        important for the result of the UVC_GET_LEN requests, which is always
+        returned as a little-endian 16-bit integer by the device.
+Return value:
+        On success 0 is returned. On error -1 is returned and errno is set
+        appropriately.
+        ENOENT
+                The device does not support the given control or the specified
+                extension unit could not be found.
+        ENOBUFS
+                The specified buffer size is incorrect (too big or too small).
+        EINVAL
+                An invalid request code was passed.
+        EBADRQC
+                The given request is not supported by the given control.
+        EFAULT
+                The data pointer references an inaccessible memory area.
+Data types:
+        * struct uvc_xu_control_query
+        __u8    unit            Extension unit ID
+        __u8    selector        Control selector
+        __u8    query           Request code to send to the device
+        __u16   size            Control data size (in bytes)
+        __u8    *data           Control value
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9bef4e4cec5..42542eb802c 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -175,7 +175,10 @@ Parameters: vcpu id (apic id on x86)
 Returns: vcpu fd on success, -1 on error
 This API adds a vcpu to a virtual machine.  The vcpu id is a small integer
-in the range [0, max_vcpus).
+in the range [0, max_vcpus).  You can use KVM_CAP_NR_VCPUS of the
+KVM_CHECK_EXTENSION ioctl() to determine the value for max_vcpus at run-time.
+If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4
+cpus max.
 4.8 KVM_GET_DIRTY_LOG (vm ioctl)
@@ -261,7 +264,7 @@ See KVM_GET_REGS for the data structure.
 4.13 KVM_GET_SREGS
 Capability: basic
-Architectures: x86
+Architectures: x86, ppc
 Type: vcpu ioctl
 Parameters: struct kvm_sregs (out)
 Returns: 0 on success, -1 on error
@@ -279,6 +282,8 @@ struct kvm_sregs {
        __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64];
 };
+/* ppc -- see arch/powerpc/include/asm/kvm.h */
 interrupt_bitmap is a bitmap of pending external interrupts.  At most
 one bit may be set.  This interrupt has been acknowledged by the APIC
 but not yet injected into the cpu core.
@@ -286,7 +291,7 @@ but not yet injected into the cpu core.
 4.14 KVM_SET_SREGS
 Capability: basic
-Architectures: x86
+Architectures: x86, ppc
 Type: vcpu ioctl
 Parameters: struct kvm_sregs (in)
 Returns: 0 on success, -1 on error
@@ -1263,6 +1268,29 @@ struct kvm_assigned_msix_entry {
        __u16 padding[3];
 };
+4.54 KVM_SET_TSC_KHZ
+Capability: KVM_CAP_TSC_CONTROL
+Architectures: x86
+Type: vcpu ioctl
+Parameters: virtual tsc_khz
+Returns: 0 on success, -1 on error
+Specifies the tsc frequency for the virtual machine. The unit of the
+frequency is KHz.
+4.55 KVM_GET_TSC_KHZ
+Capability: KVM_CAP_GET_TSC_KHZ
+Architectures: x86
+Type: vcpu ioctl
+Parameters: none
+Returns: virtual tsc-khz on success, negative value on error
+Returns the tsc frequency of the guest. The unit of the return value is
+KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
+error.
 5. The kvm_run structure
 Application code obtains a pointer to the kvm_run structure by
diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
index 9b7e1904db1..5d0fc8bfcdb 100644
--- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
@@ -1182,6 +1182,16 @@
  forge.net/>  and explains these in detail, as well as
  some other issues.
+  There is also a related point-to-point only "ucast" transport.
+  This is useful when your network does not support multicast, and
+  all network connections are simple point to point links.
+  The full set of command line options for this transport are
+       ethn=ucast,ethernet address,remote address,listen port,remote port
  66..66..  TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr
diff --git a/Documentation/vm/locking b/Documentation/vm/locking
index 25fadb44876..f61228bd639 100644
--- a/Documentation/vm/locking
+++ b/Documentation/vm/locking
@@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by
 expand_stack(), it is hard to come up with a destructive scenario without 
 having the vmlist protection in this case.
-The page_table_lock nests with the inode i_mmap_lock and the kmem cache
+The page_table_lock nests with the inode i_mmap_mutex and the kmem cache
 c_spinlock spinlocks.  This is okay, since the kmem code asks for pages after
 dropping c_spinlock.  The page_table_lock also nests with pagecache_lock and
 pagemap_lru_lock spinlocks, and no code asks for memory with these locks