Merge branch 'poll' into staging/for_v3.4

* poll: (5970 commits) poll: add poll_requested_events() and poll_does_not_wait() functions crc32: select an algorithm via Kconfig crc32: add self-test code for crc32c crypto: crc32c should use library implementation crc32: bolt on crc32c crc32: add note about this patchset to crc32.c crc32: optimize loop counter for x86 crc32: add slice-by-8 algorithm to existing code crc32: make CRC_*_BITS definition correspond to actual bit counts crc32: fix mixing of endian-specific types crc32: miscellaneous cleanups crc32: simplify unit test code crc32: move long comment about crc32 fundamentals to Documentation/ crc32: remove two instances of trailing whitespaces checkpatch: check for quoted strings broken across lines checkpatch: whitespace - add/remove blank lines checkpatch: warn on use of yield() checkpatch: add --strict tests for braces, comments and casts checkpatch: add [] to type extensions checkpatch: high precedence operators do not require additional parentheses in #defines ...
2012-03-27 11:32:29 -03:00 · 2012-03-27 11:32:29 -03:00 · 50953e0640
parent f92c97c8bd 626cf23660
commit 50953e0640
5768 changed files with 344313 additions and 215087 deletions
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@ -7,8 +7,8 @@ Please try and keep the descriptions small enough to fit on one line.
 Following translations are available on the WWW:
-   - Japanese, maintained by the JF Project (JF@linux.or.jp), at
+   - Japanese, maintained by the JF Project (jf@listserv.linux.or.jp), at
-     http://www.linux.or.jp/JF/
+     http://linuxjf.sourceforge.jp/
 00-INDEX
 	- this file.
@ -104,6 +104,8 @@ cpuidle/
 	- info on CPU_IDLE, CPU idle state management subsystem.
 cputopology.txt
 	- documentation on how CPU topology info is exported via sysfs.
 crc32.txt
 	- brief tutorial on CRC computation
 cris/
 	- directory with info about Linux on CRIS architecture.
 crypto/
--- a/Documentation/ABI/obsolete/sysfs-class-rfkill
+++ b/Documentation/ABI/obsolete/sysfs-class-rfkill
@ -7,7 +7,7 @@ Date:		09-Jul-2007
 KernelVersion	v2.6.22
 Contact:	linux-wireless@vger.kernel.org
 Description: 	Current state of the transmitter.
-		This file is deprecated and sheduled to be removed in 2014,
+		This file is deprecated and scheduled to be removed in 2014,
 		because its not possible to express the 'soft and hard block'
 		state of the rfkill driver.
 Values: 	A numeric value.
--- a/Documentation/ABI/removed/devfs
+++ b/Documentation/ABI/removed/devfs
@ -1,6 +1,6 @@
 What:		devfs
 Date:		July 2005 (scheduled), finally removed in kernel v2.6.18
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 	devfs has been unmaintained for a number of years, has unfixable
 	races, contains a naming policy within the kernel that is
--- a/Documentation/ABI/stable/sysfs-driver-usb-usbtmc
+++ b/Documentation/ABI/stable/sysfs-driver-usb-usbtmc
@ -1,7 +1,7 @@
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
 Date:		August 2008
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		These files show the various USB TMC capabilities as described
 		by the device itself.  The full description of the bitfields
@ -15,7 +15,7 @@ Description:
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
 Date:		August 2008
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		These files show the various USB TMC capabilities as described
 		by the device itself.  The full description of the bitfields
@ -29,7 +29,7 @@ Description:
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/TermChar
 Date:		August 2008
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		This file is the TermChar value to be sent to the USB TMC
 		device as described by the document, "Universal Serial Bus Test
@ -42,7 +42,7 @@ Description:
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
 Date:		August 2008
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		This file determines if the TermChar is to be sent to the
 		device on every transaction or not.  For more details about
@ -53,7 +53,7 @@ Description:
 What:		/sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
 Date:		August 2008
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		This file determines if the the transaction of the USB TMC
 		device is to be automatically aborted if there is any error.
--- a/Documentation/ABI/stable/sysfs-module
+++ b/Documentation/ABI/stable/sysfs-module
@ -6,7 +6,7 @@ Description:
 		The name of the module that is in the kernel.  This
 		module name will show up either if the module is built
 		directly into the kernel, or if it is loaded as a
-		dyanmic module.
+		dynamic module.
 	/sys/module/MODULENAME/parameters
 		This directory contains individual files that are each
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@ -182,3 +182,14 @@ Description:
 		USB2 hardware LPM is enabled for the device. Developer can
 		write y/Y/1 or n/N/0 to the file to enable/disable the
 		feature.
 What:		/sys/bus/usb/devices/.../removable
 Date:		February 2012
 Contact:	Matthew Garrett <mjg@redhat.com>
 Description:
 		Some information about whether a given USB device is
 		physically fixed to the platform can be inferred from a
 		combination of hub decriptor bits and platform-specific data
 		such as ACPI. This file will read either "removable" or
 		"fixed" if the information is available, and "unknown"
 		otherwise.
--- a/Documentation/ABI/testing/sysfs-class
+++ b/Documentation/ABI/testing/sysfs-class
@ -1,6 +1,6 @@
 What:		/sys/class/
 Date:		Febuary 2006
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		The /sys/class directory will consist of a group of
 		subdirectories describing individual classes of devices
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@ -65,6 +65,13 @@ Description:
 		Defines the penalty which will be applied to an
 		originator message's tq-field on every hop.
 What:		/sys/class/net/<mesh_iface>/mesh/routing_algo
 Date:		Dec 2011
 Contact:	Marek Lindner <lindner_marek@yahoo.de>
 Description:
 		Defines the routing procotol this mesh instance
 		uses to find the optimal paths through the mesh.
 What:           /sys/class/net/<mesh_iface>/mesh/vis_mode
 Date:           May 2010
 Contact:        Marek Lindner <lindner_marek@yahoo.de>
--- a/Documentation/ABI/testing/sysfs-devices
+++ b/Documentation/ABI/testing/sysfs-devices
@ -1,6 +1,6 @@
 What:		/sys/devices
 Date:		February 2006
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:
 		The /sys/devices tree contains a snapshot of the
 		internal state of the kernel device tree.  Devices will
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@ -165,3 +165,21 @@ Description:
 		Not all drivers support this attribute.  If it isn't supported,
 		attempts to read or write it will yield I/O errors.
 What:		/sys/devices/.../power/pm_qos_latency_us
 Date:		March 2012
 Contact:	Rafael J. Wysocki <rjw@sisk.pl>
 Description:
 		The /sys/devices/.../power/pm_qos_resume_latency_us attribute
 		contains the PM QoS resume latency limit for the given device,
 		which is the maximum allowed time it can take to resume the
 		device, after it has been suspended at run time, from a resume
 		request to the moment the device will be ready to process I/O,
 		in microseconds.  If it is equal to 0, however, this means that
 		the PM QoS resume latency may be arbitrary.
 		Not all drivers support this attribute.  If it isn't supported,
 		it is not present.
 		This attribute has no effect on system-wide suspend/resume and
 		hibernation.
--- a/Documentation/ABI/testing/sysfs-devices-soc
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@ -0,0 +1,58 @@
 What:		/sys/devices/socX
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		The /sys/devices/ directory contains a sub-directory for each
 		System-on-Chip (SoC) device on a running platform. Information
 		regarding each SoC can be obtained by reading sysfs files. This
 		functionality is only available if implemented by the platform.
 		The directory created for each SoC will also house information
 		about devices which are commonly contained in /sys/devices/platform.
 		It has been agreed that if an SoC device exists, its supported
 		devices would be better suited to appear as children of that SoC.
 What:		/sys/devices/socX/machine
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		Read-only attribute common to all SoCs. Contains the SoC machine
 		name (e.g. Ux500).
 What:		/sys/devices/socX/family
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		Read-only attribute common to all SoCs. Contains SoC family name
 		(e.g. DB8500).
 What:		/sys/devices/socX/soc_id
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		Read-only attribute supported by most SoCs. In the case of
 		ST-Ericsson's chips this contains the SoC serial number.
 What:		/sys/devices/socX/revision
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		Read-only attribute supported by most SoCs. Contains the SoC's
 		manufacturing revision number.
 What:		/sys/devices/socX/process
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		Read-only attribute supported ST-Ericsson's silicon. Contains the
 		the process by which the silicon chip was manufactured.
 What:		/sys/bus/soc
 Date:		January 2012
 contact:	Lee Jones <lee.jones@linaro.org>
 Description:
 		The /sys/bus/soc/ directory contains the usual sub-folders
 		expected under most buses. /sys/bus/soc/devices is of particular
 		interest, as it contains a symlink for each SoC device found on
 		the system. Each symlink points back into the aforementioned
 		/sys/devices/socX devices.
--- a/Documentation/ABI/testing/sysfs-driver-samsung-laptop
+++ b/Documentation/ABI/testing/sysfs-driver-samsung-laptop
@ -1,7 +1,7 @@
 What:		/sys/devices/platform/samsung/performance_level
 Date:		January 1, 2010
 KernelVersion:	2.6.33
-Contact:	Greg Kroah-Hartman <gregkh@suse.de>
+Contact:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Description:	Some Samsung laptops have different "performance levels"
 		that are can be modified by a function key, and by this
 		sysfs file.  These values don't always make a whole lot
--- a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
@ -1,11 +0,0 @@
 What:		/sys/kernel/mm/cleancache/
 Date:		April 2011
 Contact:	Dan Magenheimer <dan.magenheimer@oracle.com>
 Description:
 		/sys/kernel/mm/cleancache/ contains a number of files which
 		record a count of various cleancache operations
 		(sum across all filesystems):
 			succ_gets
 			failed_gets
 			puts
 			flushes
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@ -129,7 +129,6 @@
 !Finclude/net/cfg80211.h cfg80211_pmksa
 !Finclude/net/cfg80211.h cfg80211_send_rx_auth
 !Finclude/net/cfg80211.h cfg80211_send_auth_timeout
 !Finclude/net/cfg80211.h __cfg80211_auth_canceled
 !Finclude/net/cfg80211.h cfg80211_send_rx_assoc
 !Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
 !Finclude/net/cfg80211.h cfg80211_send_deauth
--- a/Documentation/DocBook/filesystems.tmpl
+++ b/Documentation/DocBook/filesystems.tmpl
@ -387,7 +387,7 @@ an example.
     <title>See also</title>
 	<para>
 	  <citation>
-	   <ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
+	   <ulink url="http://kernel.org/pub/linux/kernel/people/sct/ext3/journal-design.ps.gz">
 	   	Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie
 	   </ulink>
 	  </citation>
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@ -361,6 +361,23 @@
   <para>It is possible to use this option with kgdboc on a tty that is not a system console.
   </para>
  </para>
  </sect1>
   <sect1 id="kgdbreboot">
   <title>Run time parameter: kgdbreboot</title>
   <para> The kgdbreboot feature allows you to change how the debugger
   deals with the reboot notification.  You have 3 choices for the
   behavior.  The default behavior is always set to 0.</para>
   <orderedlist>
   <listitem><para>echo -1 > /sys/module/debug_core/parameters/kgdbreboot</para>
   <para>Ignore the reboot notification entirely.</para>
   </listitem>
   <listitem><para>echo 0 > /sys/module/debug_core/parameters/kgdbreboot</para>
   <para>Send the detach message to any attached debugger client.</para>
   </listitem>
   <listitem><para>echo 1 > /sys/module/debug_core/parameters/kgdbreboot</para>
   <para>Enter the debugger on reboot notify.</para>
   </listitem>
   </orderedlist>
  </sect1>
  </chapter>
  <chapter id="usingKDB">
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@ -22,8 +22,8 @@
   <para>
   The contents of this file are subject to the Open
   Software License version 1.1 that can be found at
-   <ulink url="http://www.opensource.org/licenses/osl-1.1.txt">http://www.opensource.org/licenses/osl-1.1.txt</ulink> and is included herein
+   <ulink url="http://fedoraproject.org/wiki/Licensing:OSL1.1">http://fedoraproject.org/wiki/Licensing:OSL1.1</ulink>
-   by reference.
+   and is included herein by reference.
   </para>
   <para>
@ -945,7 +945,7 @@ and other resources, etc.
        <listitem>
 	<para>
-	!BSY &amp;&amp; ERR after CDB tranfer starts but before the
+	!BSY &amp;&amp; ERR after CDB transfer starts but before the
        last byte of CDB is transferred.  ATA/ATAPI standard states
        that &quot;The device shall not terminate the PACKET command
        with an error before the last byte of the command packet has
@ -1050,7 +1050,7 @@ and other resources, etc.
 	   to complete a command.  Combined with the fact that MWDMA
 	   and PIO transfer errors aren't allowed to use ICRC bit up to
 	   ATA/ATAPI-7, it seems to imply that ABRT bit alone could
-	   indicate tranfer errors.
+	   indicate transfer errors.
 	   </para>
 	   <para>
 	   However, ATA/ATAPI-8 draft revision 1f removes the part
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@ -444,7 +444,7 @@ linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entr
 		<entry><para><link
 linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote>
 		      <para>Presumably all V4L RGB formats are
-little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue
+little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue
 swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
 		    </footnote></para></entry>
 	      </row>
@ -823,7 +823,7 @@ standard); 35468950&nbsp;Hz PAL and SECAM (625-line standards)</entry>
 		<row>
 		  <entry>sample_format</entry>
 		  <entry>V4L2_PIX_FMT_GREY. The last four bytes (a
-machine endianess integer) contain a frame counter.</entry>
+machine endianness integer) contain a frame counter.</entry>
 		</row>
 		<row>
 		  <entry>start[]</entry>
--- a/Documentation/EDID/1024x768.S
+++ b/Documentation/EDID/1024x768.S
@ -0,0 +1,44 @@
 /*
   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
   Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */
 /* EDID */
 #define VERSION 1
 #define REVISION 3
 /* Display */
 #define CLOCK 65000 /* kHz */
 #define XPIX 1024
 #define YPIX 768
 #define XY_RATIO XY_RATIO_4_3
 #define XBLANK 320
 #define YBLANK 38
 #define XOFFSET 8
 #define XPULSE 144
 #define YOFFSET (63+3)
 #define YPULSE (63+6)
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux XGA"
 #define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
 #define HSYNC_POL 0
 #define VSYNC_POL 0
 #define CRC 0x55
 #include "edid.S"
--- a/Documentation/EDID/1280x1024.S
+++ b/Documentation/EDID/1280x1024.S
@ -0,0 +1,44 @@
 /*
   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
   Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */
 /* EDID */
 #define VERSION 1
 #define REVISION 3
 /* Display */
 #define CLOCK 108000 /* kHz */
 #define XPIX 1280
 #define YPIX 1024
 #define XY_RATIO XY_RATIO_5_4
 #define XBLANK 408
 #define YBLANK 42
 #define XOFFSET 48
 #define XPULSE 112
 #define YOFFSET (63+1)
 #define YPULSE (63+3)
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux SXGA"
 #define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0xa0
 #include "edid.S"
--- a/Documentation/EDID/1680x1050.S
+++ b/Documentation/EDID/1680x1050.S
@ -0,0 +1,44 @@
 /*
   1680x1050.S: EDID data set for standard 1680x1050 60 Hz monitor
   Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */
 /* EDID */
 #define VERSION 1
 #define REVISION 3
 /* Display */
 #define CLOCK 146250 /* kHz */
 #define XPIX 1680
 #define YPIX 1050
 #define XY_RATIO XY_RATIO_16_10
 #define XBLANK 560
 #define YBLANK 39
 #define XOFFSET 104
 #define XPULSE 176
 #define YOFFSET (63+3)
 #define YPULSE (63+6)
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux WSXGA"
 #define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x26
 #include "edid.S"
--- a/Documentation/EDID/1920x1080.S
+++ b/Documentation/EDID/1920x1080.S
@ -0,0 +1,44 @@
 /*
   1920x1080.S: EDID data set for standard 1920x1080 60 Hz monitor
   Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */
 /* EDID */
 #define VERSION 1
 #define REVISION 3
 /* Display */
 #define CLOCK 148500 /* kHz */
 #define XPIX 1920
 #define YPIX 1080
 #define XY_RATIO XY_RATIO_16_9
 #define XBLANK 280
 #define YBLANK 45
 #define XOFFSET 88
 #define XPULSE 44
 #define YOFFSET (63+4)
 #define YPULSE (63+5)
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux FHD"
 #define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x05
 #include "edid.S"
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@ -0,0 +1,39 @@
 In the good old days when graphics parameters were configured explicitly
 in a file called xorg.conf, even broken hardware could be managed.
 Today, with the advent of Kernel Mode Setting, a graphics board is
 either correctly working because all components follow the standards -
 or the computer is unusable, because the screen remains dark after
 booting or it displays the wrong area. Cases when this happens are:
 - The graphics board does not recognize the monitor.
 - The graphics board is unable to detect any EDID data.
 - The graphics board incorrectly forwards EDID data to the driver.
 - The monitor sends no or bogus EDID data.
 - A KVM sends its own EDID data instead of querying the connected monitor.
 Adding the kernel parameter "nomodeset" helps in most cases, but causes
 restrictions later on.
 As a remedy for such situations, the kernel configuration item
 CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
 individually prepared or corrected EDID data set in the /lib/firmware
 directory from where it is loaded via the firmware interface. The code
 (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
 commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
 1920x1080) as binary blobs, but the kernel source tree does not contain
 code to create these data. In order to elucidate the origin of the
 built-in binary EDID blobs and to facilitate the creation of individual
 data for a specific misbehaving monitor, commented sources and a
 Makefile environment are given here.
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
 If you want to create your own EDID file, copy the file 1024x768.S and
 replace the settings with your own data. The CRC value in the last line
  #define CRC 0x55
 is a bit tricky. After a first version of the binary data set is
 created, it must be be checked with the "edid-decode" utility which will
 most probably complain about a wrong CRC. Fortunately, the utility also
 displays the correct CRC which must then be inserted into the source
 file. After the make procedure is repeated, the EDID data set is ready
 to be used.
--- a/Documentation/EDID/Makefile
+++ b/Documentation/EDID/Makefile
@ -0,0 +1,26 @@
 SOURCES	:= $(wildcard [0-9]*x[0-9]*.S)
 BIN	:= $(patsubst %.S, %.bin, $(SOURCES))
 IHEX	:= $(patsubst %.S, %.bin.ihex, $(SOURCES))
 CODE	:= $(patsubst %.S, %.c, $(SOURCES))
 all:	$(BIN) $(IHEX) $(CODE)
 clean:
 	@rm -f *.o *.bin.ihex *.bin *.c
 %.o:	%.S
 	@cc -c $^
 %.bin:	%.o
 	@objcopy -Obinary $^ $@
 %.bin.ihex:	%.o
 	@objcopy -Oihex $^ $@
 	@dos2unix $@ 2>/dev/null
 %.c:	%.bin
 	@echo "{" >$@; hexdump -f hex $^ >>$@; echo "};" >>$@
--- a/Documentation/EDID/edid.S
+++ b/Documentation/EDID/edid.S
@ -0,0 +1,261 @@
 /*
   edid.S: EDID data template
   Copyright (C) 2012 Carsten Emde <C.Emde@osadl.org>
   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., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
 */
 /* Manufacturer */
 #define MFG_LNX1 'L'
 #define MFG_LNX2 'N'
 #define MFG_LNX3 'X'
 #define SERIAL 0
 #define YEAR 2012
 #define WEEK 5
 /* EDID 1.3 standard definitions */
 #define XY_RATIO_16_10	0b00
 #define XY_RATIO_4_3	0b01
 #define XY_RATIO_5_4	0b10
 #define XY_RATIO_16_9	0b11
 #define mfgname2id(v1,v2,v3) \
 	((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
 #define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
 #define msbs2(v1,v2) ((((v1>>8)&0x0f)<<4)+((v2>>8)&0x0f))
 #define msbs4(v1,v2,v3,v4) \
 	(((v1&0x03)>>2)+((v2&0x03)>>4)+((v3&0x03)>>6)+((v4&0x03)>>8))
 #define pixdpi2mm(pix,dpi) ((pix*25)/dpi)
 #define xsize pixdpi2mm(XPIX,DPI)
 #define ysize pixdpi2mm(YPIX,DPI)
 		.data
 /* Fixed header pattern */
 header:		.byte	0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00
 mfg_id:		.word	swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
 prod_code:	.word	0
 /* Serial number. 32 bits, little endian. */
 serial_number:	.long	SERIAL
 /* Week of manufacture */
 week:		.byte	WEEK
 /* Year of manufacture, less 1990. (1990-2245)
   If week=255, it is the model year instead */
 year:		.byte	YEAR-1990
 version:	.byte	VERSION 	/* EDID version, usually 1 (for 1.3) */
 revision:	.byte	REVISION	/* EDID revision, usually 3 (for 1.3) */
 /* If Bit 7=1	Digital input. If set, the following bit definitions apply:
     Bits 6-1	Reserved, must be 0
     Bit 0	Signal is compatible with VESA DFP 1.x TMDS CRGB,
 		  1 pixel per clock, up to 8 bits per color, MSB aligned,
   If Bit 7=0	Analog input. If clear, the following bit definitions apply:
     Bits 6-5	Video white and sync levels, relative to blank
 		  00=+0.7/-0.3 V; 01=+0.714/-0.286 V;
 		  10=+1.0/-0.4 V; 11=+0.7/0 V
   Bit 4	Blank-to-black setup (pedestal) expected
   Bit 3	Separate sync supported
   Bit 2	Composite sync (on HSync) supported
   Bit 1	Sync on green supported
   Bit 0	VSync pulse must be serrated when somposite or
 		  sync-on-green is used. */
 video_parms:	.byte	0x6d
 /* Maximum horizontal image size, in centimetres
   (max 292 cm/115 in at 16:9 aspect ratio) */
 max_hor_size:	.byte	xsize/10
 /* Maximum vertical image size, in centimetres.
   If either byte is 0, undefined (e.g. projector) */
 max_vert_size:	.byte	ysize/10
 /* Display gamma, minus 1, times 100 (range 1.00-3.5 */
 gamma:		.byte	120
 /* Bit 7	DPMS standby supported
   Bit 6	DPMS suspend supported
   Bit 5	DPMS active-off supported
   Bits 4-3	Display type: 00=monochrome; 01=RGB colour;
 		  10=non-RGB multicolour; 11=undefined
   Bit 2	Standard sRGB colour space. Bytes 25-34 must contain
 		  sRGB standard values.
   Bit 1	Preferred timing mode specified in descriptor block 1.
   Bit 0	GTF supported with default parameter values. */
 dsp_features:	.byte	0xea
 /* Chromaticity coordinates. */
 /* Red and green least-significant bits
   Bits 7-6	Red x value least-significant 2 bits
   Bits 5-4	Red y value least-significant 2 bits
   Bits 3-2	Green x value lst-significant 2 bits
   Bits 1-0	Green y value least-significant 2 bits */
 red_green_lsb:	.byte	0x5e
 /* Blue and white least-significant 2 bits */
 blue_white_lsb:	.byte	0xc0
 /* Red x value most significant 8 bits.
   0-255 encodes 0-0.996 (255/256); 0-0.999 (1023/1024) with lsbits */
 red_x_msb:	.byte	0xa4
 /* Red y value most significant 8 bits */
 red_y_msb:	.byte	0x59
 /* Green x and y value most significant 8 bits */
 green_x_y_msb:	.byte	0x4a,0x98
 /* Blue x and y value most significant 8 bits */
 blue_x_y_msb:	.byte	0x25,0x20
 /* Default white point x and y value most significant 8 bits */
 white_x_y_msb:	.byte	0x50,0x54
 /* Established timings */
 /* Bit 7	720x400 @ 70 Hz
   Bit 6	720x400 @ 88 Hz
   Bit 5	640x480 @ 60 Hz
   Bit 4	640x480 @ 67 Hz
   Bit 3	640x480 @ 72 Hz
   Bit 2	640x480 @ 75 Hz
   Bit 1	800x600 @ 56 Hz
   Bit 0	800x600 @ 60 Hz */
 estbl_timing1:	.byte	0x00
 /* Bit 7	800x600 @ 72 Hz
   Bit 6	800x600 @ 75 Hz
   Bit 5	832x624 @ 75 Hz
   Bit 4	1024x768 @ 87 Hz, interlaced (1024x768)
   Bit 3	1024x768 @ 60 Hz
   Bit 2	1024x768 @ 72 Hz
   Bit 1	1024x768 @ 75 Hz
   Bit 0	1280x1024 @ 75 Hz */
 estbl_timing2:	.byte	ESTABLISHED_TIMINGS_BITS
 /* Bit 7	1152x870 @ 75 Hz (Apple Macintosh II)
   Bits 6-0 	Other manufacturer-specific display mod */
 estbl_timing3:	.byte	0x00
 /* Standard timing */
 /* X resolution, less 31, divided by 8 (256-2288 pixels) */
 std_xres:	.byte	(XPIX/8)-31
 /* Y resolution, X:Y pixel ratio
   Bits 7-6	X:Y pixel ratio: 00=16:10; 01=4:3; 10=5:4; 11=16:9.
   Bits 5-0	Vertical frequency, less 60 (60-123 Hz) */
 std_vres:	.byte	(XY_RATIO<<6)+VFREQ-60
 		.fill	7,2,0x0101	/* Unused */
 descriptor1:
 /* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
 clock:		.word	CLOCK/10
 /* Horizontal active pixels 8 lsbits (0-4095) */
 x_act_lsb:	.byte	XPIX&0xff
 /* Horizontal blanking pixels 8 lsbits (0-4095)
   End of active to start of next active. */
 x_blk_lsb:	.byte	XBLANK&0xff
 /* Bits 7-4 	Horizontal active pixels 4 msbits
   Bits 3-0	Horizontal blanking pixels 4 msbits */
 x_msbs:		.byte	msbs2(XPIX,XBLANK)
 /* Vertical active lines 8 lsbits (0-4095) */
 y_act_lsb:	.byte	YPIX&0xff
 /* Vertical blanking lines 8 lsbits (0-4095) */
 y_blk_lsb:	.byte	YBLANK&0xff
 /* Bits 7-4 	Vertical active lines 4 msbits
   Bits 3-0 	Vertical blanking lines 4 msbits */
 y_msbs:		.byte	msbs2(YPIX,YBLANK)
 /* Horizontal sync offset pixels 8 lsbits (0-1023) From blanking start */
 x_snc_off_lsb:	.byte	XOFFSET&0xff
 /* Horizontal sync pulse width pixels 8 lsbits (0-1023) */
 x_snc_pls_lsb:	.byte	XPULSE&0xff
 /* Bits 7-4 	Vertical sync offset lines 4 lsbits -63)
   Bits 3-0 	Vertical sync pulse width lines 4 lsbits -63) */
 y_snc_lsb:	.byte	((YOFFSET-63)<<4)+(YPULSE-63)
 /* Bits 7-6 	Horizontal sync offset pixels 2 msbits
   Bits 5-4 	Horizontal sync pulse width pixels 2 msbits
   Bits 3-2 	Vertical sync offset lines 2 msbits
   Bits 1-0 	Vertical sync pulse width lines 2 msbits */
 xy_snc_msbs:	.byte	msbs4(XOFFSET,XPULSE,YOFFSET,YPULSE)
 /* Horizontal display size, mm, 8 lsbits (0-4095 mm, 161 in) */
 x_dsp_size:	.byte	xsize&0xff
 /* Vertical display size, mm, 8 lsbits (0-4095 mm, 161 in) */
 y_dsp_size:	.byte	ysize&0xff
 /* Bits 7-4 	Horizontal display size, mm, 4 msbits
   Bits 3-0 	Vertical display size, mm, 4 msbits */
 dsp_size_mbsb:	.byte	msbs2(xsize,ysize)
 /* Horizontal border pixels (each side; total is twice this) */
 x_border:	.byte	0
 /* Vertical border lines (each side; total is twice this) */
 y_border:	.byte	0
 /* Bit 7 	Interlaced
   Bits 6-5 	Stereo mode: 00=No stereo; other values depend on bit 0:
   Bit 0=0: 01=Field sequential, sync=1 during right; 10=similar,
     sync=1 during left; 11=4-way interleaved stereo
   Bit 0=1 2-way interleaved stereo: 01=Right image on even lines;
     10=Left image on even lines; 11=side-by-side
   Bits 4-3 	Sync type: 00=Analog composite; 01=Bipolar analog composite;
     10=Digital composite (on HSync); 11=Digital separate
   Bit 2 	If digital separate: Vertical sync polarity (1=positive)
   Other types: VSync serrated (HSync during VSync)
   Bit 1 	If analog sync: Sync on all 3 RGB lines (else green only)
   Digital: HSync polarity (1=positive)
   Bit 0 	2-way line-interleaved stereo, if bits 4-3 are not 00. */
 features:	.byte	0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1)
 descriptor2:	.byte	0,0	/* Not a detailed timing descriptor */
 		.byte	0	/* Must be zero */
 		.byte	0xff	/* Descriptor is monitor serial number (text) */
 		.byte	0	/* Must be zero */
 start1:		.ascii	"Linux #0"
 end1:		.byte	0x0a	/* End marker */
 		.fill	12-(end1-start1), 1, 0x20 /* Padded spaces */
 descriptor3:	.byte	0,0	/* Not a detailed timing descriptor */
 		.byte	0	/* Must be zero */
 		.byte	0xfd	/* Descriptor is monitor range limits */
 		.byte	0	/* Must be zero */
 start2:		.byte	VFREQ-1	/* Minimum vertical field rate (1-255 Hz) */
 		.byte	VFREQ+1	/* Maximum vertical field rate (1-255 Hz) */
 		.byte	(CLOCK/(XPIX+XBLANK))-1 /* Minimum horizontal line rate
 						    (1-255 kHz) */
 		.byte	(CLOCK/(XPIX+XBLANK))+1 /* Maximum horizontal line rate
 						    (1-255 kHz) */
 		.byte	(CLOCK/10000)+1	/* Maximum pixel clock rate, rounded up
 					   to 10 MHz multiple (10-2550 MHz) */
 		.byte	0	/* No extended timing information type */
 end2:		.byte	0x0a	/* End marker */
 		.fill	12-(end2-start2), 1, 0x20 /* Padded spaces */
 descriptor4:	.byte	0,0	/* Not a detailed timing descriptor */
 		.byte	0	/* Must be zero */
 		.byte	0xfc	/* Descriptor is text */
 		.byte	0	/* Must be zero */
 start3:		.ascii	TIMING_NAME
 end3:		.byte	0x0a	/* End marker */
 		.fill	12-(end3-start3), 1, 0x20 /* Padded spaces */
 extensions:	.byte	0	/* Number of extensions to follow */
 checksum:	.byte	CRC	/* Sum of all bytes must be 0 */
--- a/Documentation/EDID/hex
+++ b/Documentation/EDID/hex
@ -0,0 +1 @@
 "\t" 8/1 "0x%02x, " "\n"
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@ -0,0 +1,117 @@
 irq_domain interrupt number mapping library
 The current design of the Linux kernel uses a single large number
 space where each separate IRQ source is assigned a different number.
 This is simple when there is only one interrupt controller, but in
 systems with multiple interrupt controllers the kernel must ensure
 that each one gets assigned non-overlapping allocations of Linux
 IRQ numbers.
 The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
 irq numbers, but they don't provide any support for reverse mapping of
 the controller-local IRQ (hwirq) number into the Linux IRQ number
 space.
 The irq_domain library adds mapping between hwirq and IRQ numbers on
 top of the irq_alloc_desc*() API.  An irq_domain to manage mapping is
 preferred over interrupt controller drivers open coding their own
 reverse mapping scheme.
 irq_domain also implements translation from Device Tree interrupt
 specifiers to hwirq numbers, and can be easily extended to support
 other IRQ topology data sources.
 === irq_domain usage ===
 An interrupt controller driver creates and registers an irq_domain by
 calling one of the irq_domain_add_*() functions (each mapping method
 has a different allocator function, more on that later).  The function
 will return a pointer to the irq_domain on success.  The caller must
 provide the allocator function with an irq_domain_ops structure with
 the .map callback populated as a minimum.
 In most cases, the irq_domain will begin empty without any mappings
 between hwirq and IRQ numbers.  Mappings are added to the irq_domain
 by calling irq_create_mapping() which accepts the irq_domain and a
 hwirq number as arguments.  If a mapping for the hwirq doesn't already
 exist then it will allocate a new Linux irq_desc, associate it with
 the hwirq, and call the .map() callback so the driver can perform any
 required hardware setup.
 When an interrupt is received, irq_find_mapping() function should
 be used to find the Linux IRQ number from the hwirq number.
 If the driver has the Linux IRQ number or the irq_data pointer, and
 needs to know the associated hwirq number (such as in the irq_chip
 callbacks) then it can be directly obtained from irq_data->hwirq.
 === Types of irq_domain mappings ===
 There are several mechanisms available for reverse mapping from hwirq
 to Linux irq, and each mechanism uses a different allocation function.
 Which reverse map type should be used depends on the use case.  Each
 of the reverse map types are described below:
 ==== Linear ====
 irq_domain_add_linear()
 The linear reverse map maintains a fixed size table indexed by the
 hwirq number.  When a hwirq is mapped, an irq_desc is allocated for
 the hwirq, and the IRQ number is stored in the table.
 The Linear map is a good choice when the maximum number of hwirqs is
 fixed and a relatively small number (~ < 256).  The advantages of this
 map are fixed time lookup for IRQ numbers, and irq_descs are only
 allocated for in-use IRQs.  The disadvantage is that the table must be
 as large as the largest possible hwirq number.
 The majority of drivers should use the linear map.
 ==== Tree ====
 irq_domain_add_tree()
 The irq_domain maintains a radix tree map from hwirq numbers to Linux
 IRQs.  When an hwirq is mapped, an irq_desc is allocated and the
 hwirq is used as the lookup key for the radix tree.
 The tree map is a good choice if the hwirq number can be very large
 since it doesn't need to allocate a table as large as the largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 Very few drivers should need this mapping.  At the moment, powerpc
 iseries is the only user.
 ==== No Map ===-
 irq_domain_add_nomap()
 The No Map mapping is to be used when the hwirq number is
 programmable in the hardware.  In this case it is best to program the
 Linux IRQ number into the hardware itself so that no mapping is
 required.  Calling irq_create_direct_mapping() will allocate a Linux
 IRQ number and call the .map() callback so that driver can program the
 Linux IRQ number into the hardware.
 Most drivers cannot use this mapping.
 ==== Legacy ====
 irq_domain_add_legacy()
 irq_domain_add_legacy_isa()
 The Legacy mapping is a special case for drivers that already have a
 range of irq_descs allocated for the hwirqs.  It is used when the
 driver cannot be immediately converted to use the linear mapping.  For
 example, many embedded system board support files use a set of #defines
 for IRQ numbers that are passed to struct device registrations.  In that
 case the Linux IRQ numbers cannot be dynamically assigned and the legacy
 mapping should be used.
 The legacy map assumes a contiguous range of IRQ numbers has already
 been allocated for the controller and that the IRQ number can be
 calculated by adding a fixed offset to the hwirq number, and
 visa-versa.  The disadvantage is that it requires the interrupt
 controller to manage IRQ allocations and it requires an irq_desc to be
 allocated for every hwirq, even if it is unused.
 The legacy map should only be used if fixed IRQ mappings must be
 supported.  For example, ISA controllers would use the legacy map for
 mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
 numbers.
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@ -180,6 +180,20 @@ over a rather long period of time, but improvements are always welcome!
 	operations that would not normally be undertaken while a real-time
 	workload is running.
 	In particular, if you find yourself invoking one of the expedited
 	primitives repeatedly in a loop, please do everyone a favor:
 	Restructure your code so that it batches the updates, allowing
 	a single non-expedited primitive to cover the entire batch.
 	This will very likely be faster than the loop containing the
 	expedited primitive, and will be much much easier on the rest
 	of the system, especially to real-time workloads running on
 	the rest of the system.
 	In addition, it is illegal to call the expedited forms from
 	a CPU-hotplug notifier, or while holding a lock that is acquired
 	by a CPU-hotplug notifier.  Failing to observe this restriction
 	will result in deadlock.
 7.	If the updater uses call_rcu() or synchronize_rcu(), then the
 	corresponding readers must use rcu_read_lock() and
 	rcu_read_unlock().  If the updater uses call_rcu_bh() or
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@ -12,14 +12,38 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
 	This kernel configuration parameter defines the period of time
 	that RCU will wait from the beginning of a grace period until it
 	issues an RCU CPU stall warning.  This time period is normally
-	ten seconds.
+	sixty seconds.
-RCU_SECONDS_TILL_STALL_RECHECK
+	This configuration parameter may be changed at runtime via the
 	/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
 	this parameter is checked only at the beginning of a cycle.
 	So if you are 30 seconds into a 70-second stall, setting this
 	sysfs parameter to (say) five will shorten the timeout for the
 	-next- stall, or the following warning for the current stall
 	(assuming the stall lasts long enough).  It will not affect the
 	timing of the next warning for the current stall.
-	This macro defines the period of time that RCU will wait after
+	Stall-warning messages may be enabled and disabled completely via
-	issuing a stall warning until it issues another stall warning
+	/sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
-	for the same stall.  This time period is normally set to three
+
-	times the check interval plus thirty seconds.
+CONFIG_RCU_CPU_STALL_VERBOSE
 	This kernel configuration parameter causes the stall warning to
 	also dump the stacks of any tasks that are blocking the current
 	RCU-preempt grace period.
 RCU_CPU_STALL_INFO
 	This kernel configuration parameter causes the stall warning to
 	print out additional per-CPU diagnostic information, including
 	information on scheduling-clock ticks and RCU's idle-CPU tracking.
 RCU_STALL_DELAY_DELTA
 	Although the lockdep facility is extremely useful, it does add
 	some overhead.  Therefore, under CONFIG_PROVE_RCU, the
 	RCU_STALL_DELAY_DELTA macro allows five extra seconds before
 	giving an RCU CPU stall warning message.
 RCU_STALL_RAT_DELAY
@ -64,6 +88,54 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffi
 This is rare, but does happen from time to time in real life.
 If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
 more information is printed with the stall-warning message, for example:
 	INFO: rcu_preempt detected stall on CPU
 	0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
 	   (t=65000 jiffies)
 In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
 printed:
 	INFO: rcu_preempt detected stall on CPU
 	0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer=-1
 	   (t=65000 jiffies)
 The "(64628 ticks this GP)" indicates that this CPU has taken more
 than 64,000 scheduling-clock interrupts during the current stalled
 grace period.  If the CPU was not yet aware of the current grace
 period (for example, if it was offline), then this part of the message
 indicates how many grace periods behind the CPU is.
 The "idle=" portion of the message prints the dyntick-idle state.
 The hex number before the first "/" is the low-order 12 bits of the
 dynticks counter, which will have an even-numbered value if the CPU is
 in dyntick-idle mode and an odd-numbered value otherwise.  The hex
 number between the two "/"s is the value of the nesting, which will
 be a small positive number if in the idle loop and a very large positive
 number (as shown above) otherwise.
 For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the
 CPU is not in the process of trying to force itself into dyntick-idle
 state, the "." indicates that the CPU has not given up forcing RCU
 into dyntick-idle mode (it would be "H" otherwise), and the "timer=-1"
 indicates that the CPU has not recented forced RCU into dyntick-idle
 mode (it would otherwise indicate the number of microseconds remaining
 in this forced state).
 Multiple Warnings From One Stall
 If a stall lasts long enough, multiple stall-warning messages will be
 printed for it.  The second and subsequent messages are printed at
 longer intervals, so that the time between (say) the first and second
 message will be about three times the interval between the beginning
 of the stall and the first message.
 What Causes RCU CPU Stall Warnings?
 So your kernel printed an RCU CPU stall warning.  The next question is
 "What caused it?"  The following problems can result in RCU CPU stall
 warnings:
@ -128,4 +200,5 @@ is occurring, which will usually be in the function nearest the top of
 that portion of the stack which remains the same from trace to trace.
 If you can reliably trigger the stall, ftrace can be quite helpful.
-RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.
+RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
 and with RCU's event tracing.
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@ -69,6 +69,13 @@ onoff_interval
 		CPU-hotplug operations regardless of what value is
 		specified for onoff_interval.
 onoff_holdoff	The number of seconds to wait until starting CPU-hotplug
 		operations.  This would normally only be used when
 		rcutorture was built into the kernel and started
 		automatically at boot time, in which case it is useful
 		in order to avoid confusing boot-time code with CPUs
 		coming and going.
 shuffle_interval
 		The number of seconds to keep the test threads affinitied
 		to a particular subset of the CPUs, defaults to 3 seconds.
@ -79,6 +86,24 @@ shutdown_secs	The number of seconds to run the test before terminating
 		zero, which disables test termination and system shutdown.
 		This capability is useful for automated testing.
 stall_cpu	The number of seconds that a CPU should be stalled while
 		within both an rcu_read_lock() and a preempt_disable().
 		This stall happens only once per rcutorture run.
 		If you need multiple stalls, use modprobe and rmmod to
 		repeatedly run rcutorture.  The default for stall_cpu
 		is zero, which prevents rcutorture from stalling a CPU.
 		Note that attempts to rmmod rcutorture while the stall
 		is ongoing will hang, so be careful what value you
 		choose for this module parameter!  In addition, too-large
 		values for stall_cpu might well induce failures and
 		warnings in other parts of the kernel.  You have been
 		warned!
 stall_cpu_holdoff
 		The number of seconds to wait after rcutorture starts
 		before stalling a CPU.  Defaults to 10 seconds.
 stat_interval	The number of seconds between output of torture
 		statistics (via printk()).  Regardless of the interval,
 		statistics are printed when the module is unloaded.
@ -271,11 +296,13 @@ The following script may be used to torture RCU:
 	#!/bin/sh
 	modprobe rcutorture
-	sleep 100
+	sleep 3600
 	rmmod rcutorture
 	dmesg | grep torture:
 The output can be manually inspected for the error flag of "!!!".
 One could of course create a more elaborate script that automatically
-checked for such errors.  The "rmmod" command forces a "SUCCESS" or
+checked for such errors.  The "rmmod" command forces a "SUCCESS",
-"FAILURE" indication to be printk()ed.
+"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed.  The first
 two are self-explanatory, while the last indicates that while there
 were no RCU failures, CPU-hotplug problems were detected.
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@ -33,23 +33,23 @@ rcu/rcuboost:
 The output of "cat rcu/rcudata" looks as follows:
 rcu_sched:
-  0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
+  0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
-  1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
+  1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
-  2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
+  2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
-  3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
+  3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
-  4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
+  4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
-  5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
+  5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
-  6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
+  6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
-  7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
+  7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
 rcu_bh:
-  0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
+  0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
-  1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
+  1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
-  2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
+  2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
-  3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
+  3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
-  4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
+  4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
-  5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
+  5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
-  6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
+  6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
-  7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
+  7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
 The first section lists the rcu_data structures for rcu_sched, the second
 for rcu_bh.  Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
@ -119,10 +119,6 @@ o	"of" is the number of times that some other CPU has forced a
 	CPU is offline when it is really alive and kicking) is a fatal
 	error, so it makes sense to err conservatively.
 o	"ri" is the number of times that RCU has seen fit to send a
 	reschedule IPI to this CPU in order to get it to report a
 	quiescent state.
 o	"ql" is the number of RCU callbacks currently residing on
 	this CPU.  This is the total number of callbacks, regardless
 	of what state they are in (new, waiting for grace period to
--- a/Documentation/arm/kernel_user_helpers.txt
+++ b/Documentation/arm/kernel_user_helpers.txt
@ -25,7 +25,7 @@ inline (either in the code emitted directly by the compiler, or part of
 the implementation of a library call) when optimizing for a recent enough
 processor that has the necessary native support, but only if resulting
 binaries are already to be incompatible with earlier ARM processors due to
-useage of similar native instructions for other things.  In other words
+usage of similar native instructions for other things.  In other words
 don't make binaries unable to run on earlier processors just for the sake
 of not using these kernel helpers if your compiled code is not going to
 use new instructions for other purpose.
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@ -0,0 +1,78 @@
 Kernel driver lp855x
 ====================
 Backlight driver for LP855x ICs
 Supported chips:
 	Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
 Author: Milo(Woogyom) Kim <milo.kim@ti.com>
 Description
 -----------
 * Brightness control
 Brightness can be controlled by the pwm input or the i2c command.
 The lp855x driver supports both cases.
 * Device attributes
 1) bl_ctl_mode
 Backlight control mode.
 Value : pwm based or register based
 2) chip_id
 The lp855x chip id.
 Value : lp8550/lp8551/lp8552/lp8553/lp8556
 Platform data for lp855x
 ------------------------
 For supporting platform specific data, the lp855x platform data can be used.
 * name : Backlight driver name. If it is not defined, default name is set.
 * mode : Brightness control mode. PWM or register based.
 * device_control : Value of DEVICE CONTROL register.
 * initial_brightness : Initial value of backlight brightness.
 * pwm_data : Platform specific pwm generation functions.
 	     Only valid when brightness is pwm input mode.
 	     Functions should be implemented by PWM driver.
 	     - pwm_set_intensity() : set duty of PWM
 	     - pwm_get_intensity() : get current duty of PWM
 * load_new_rom_data :
 	0 : use default configuration data
 	1 : update values of eeprom or eprom registers on loading driver
 * size_program : Total size of lp855x_rom_data.
 * rom_data : List of new eeprom/eprom registers.
 example 1) lp8552 platform data : i2c register mode with new eeprom data
 #define EEPROM_A5_ADDR	0xA5
 #define EEPROM_A5_VAL	0x4f	/* EN_VSYNC=0 */
 static struct lp855x_rom_data lp8552_eeprom_arr[] = {
 	{EEPROM_A5_ADDR, EEPROM_A5_VAL},
 };
 static struct lp855x_platform_data lp8552_pdata = {
 	.name = "lcd-bl",
 	.mode = REGISTER_BASED,
 	.device_control = I2C_CONFIG(LP8552),
 	.initial_brightness = INITIAL_BRT,
 	.load_new_rom_data = 1,
 	.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
 	.rom_data = lp8552_eeprom_arr,
 };
 example 2) lp8556 platform data : pwm input mode with default rom data
 static struct lp855x_platform_data lp8556_pdata = {
 	.mode = PWM_BASED,
 	.device_control = PWM_CONFIG(LP8556),
 	.initial_brightness = INITIAL_BRT,
 	.pwm_data = {
 		     .pwm_set_intensity = platform_pwm_set_intensity,
 		     .pwm_get_intensity = platform_pwm_get_intensity,
 		     },
 };
--- a/Documentation/cgroups/blkio-controller.txt
+++ b/Documentation/cgroups/blkio-controller.txt
@ -94,11 +94,11 @@ Throttling/Upper Limit policy
 Hierarchical Cgroups
 ====================
- Currently none of the IO control policy supports hierarhical groups. But
+- Currently none of the IO control policy supports hierarchical groups. But
-  cgroup interface does allow creation of hierarhical cgroups and internally
+  cgroup interface does allow creation of hierarchical cgroups and internally
  IO policies treat them as flat hierarchy.
-  So this patch will allow creation of cgroup hierarhcy but at the backend
+  So this patch will allow creation of cgroup hierarchcy but at the backend
  everything will be treated as flat. So if somebody created a hierarchy like
  as follows.
@ -266,7 +266,7 @@ Proportional weight policy files
 - blkio.idle_time
 	- Debugging aid only enabled if CONFIG_DEBUG_BLK_CGROUP=y.
 	  This is the amount of time spent by the IO scheduler idling for a
-	  given cgroup in anticipation of a better request than the exising ones
+	  given cgroup in anticipation of a better request than the existing ones
 	  from other queues/cgroups. This is in nanoseconds. If this is read
 	  when the cgroup is in an idling state, the stat will only report the
 	  idle_time accumulated till the last idle period and will not include
@ -283,34 +283,34 @@ Throttling/Upper limit policy files
 -----------------------------------
 - blkio.throttle.read_bps_device
 	- Specifies upper limit on READ rate from the device. IO rate is
-	  specified in bytes per second. Rules are per deivce. Following is
+	  specified in bytes per second. Rules are per device. Following is
 	  the format.
  echo "<major>:<minor>  <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device
 - blkio.throttle.write_bps_device
 	- Specifies upper limit on WRITE rate to the device. IO rate is
-	  specified in bytes per second. Rules are per deivce. Following is
+	  specified in bytes per second. Rules are per device. Following is
 	  the format.
  echo "<major>:<minor>  <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device
 - blkio.throttle.read_iops_device
 	- Specifies upper limit on READ rate from the device. IO rate is
-	  specified in IO per second. Rules are per deivce. Following is
+	  specified in IO per second. Rules are per device. Following is
 	  the format.
  echo "<major>:<minor>  <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device
 - blkio.throttle.write_iops_device
 	- Specifies upper limit on WRITE rate to the device. IO rate is
-	  specified in io per second. Rules are per deivce. Following is
+	  specified in io per second. Rules are per device. Following is
 	  the format.
  echo "<major>:<minor>  <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device
 Note: If both BW and IOPS rules are specified for a device, then IO is
-      subjectd to both the constraints.
+      subjected to both the constraints.
 - blkio.throttle.io_serviced
 	- Number of IOs (bio) completed to/from the disk by the group (as
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@ -558,8 +558,7 @@ Each subsystem may export the following methods. The only mandatory
 methods are create/destroy. Any others that are null are presumed to
 be successful no-ops.
-struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
+struct cgroup_subsys_state *create(struct cgroup *cgrp)
 				   struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 Called to create a subsystem state object for a cgroup. The
@ -574,7 +573,7 @@ identified by the passed cgroup object having a NULL parent (since
 it's the root of the hierarchy) and may be an appropriate place for
 initialization code.
-void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
+void destroy(struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 The cgroup system is about to destroy the passed cgroup; the subsystem
@ -585,7 +584,7 @@ cgroup->parent is still valid. (Note - can also be called for a
 newly-created cgroup if an error occurs after this subsystem's
 create() method has been called for the new cgroup).
-int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
+int pre_destroy(struct cgroup *cgrp);
 Called before checking the reference count on each subsystem. This may
 be useful for subsystems which have some extra references even if
@ -593,8 +592,7 @@ there are not tasks in the cgroup. If pre_destroy() returns error code,
 rmdir() will fail with it. From this behavior, pre_destroy() can be
 called multiple times against a cgroup.
-int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
+int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 	       struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 Called prior to moving one or more tasks into a cgroup; if the
@ -615,8 +613,7 @@ fork. If this method returns 0 (success) then this should remain valid
 while the caller holds cgroup_mutex and it is ensured that either
 attach() or cancel_attach() will be called in future.
-void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
+void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 		   struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 Called when a task attach operation has failed after can_attach() has succeeded.
@ -625,23 +622,22 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
 This will be called only about subsystems whose can_attach() operation have
 succeeded. The parameters are identical to can_attach().
-void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
+void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 	    struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 Called after the task has been attached to the cgroup, to allow any
 post-attachment activity that requires memory allocations or blocking.
 The parameters are identical to can_attach().
-void fork(struct cgroup_subsy *ss, struct task_struct *task)
+void fork(struct task_struct *task)
 Called when a task is forked into a cgroup.
-void exit(struct cgroup_subsys *ss, struct task_struct *task)
+void exit(struct task_struct *task)
 Called during task exit.
-int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
+int populate(struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 Called after creation of a cgroup to allow a subsystem to populate
@ -651,7 +647,7 @@ include/linux/cgroup.h for details).  Note that although this
 method can return an error code, the error code is currently not
 always handled well.
-void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
+void post_clone(struct cgroup *cgrp)
 (cgroup_mutex held by caller)
 Called during cgroup_create() to do any parameter
@ -659,7 +655,7 @@ initialization which might be required before a task could attach.  For
 example in cpusets, no task may attach before 'cpus' and 'mems' are set
 up.
-void bind(struct cgroup_subsys *ss, struct cgroup *root)
+void bind(struct cgroup *root)
 (cgroup_mutex and ss->hierarchy_mutex held by caller)
 Called when a cgroup subsystem is rebound to a different hierarchy
--- a/Documentation/crc32.txt
+++ b/Documentation/crc32.txt
@ -0,0 +1,182 @@
 A brief CRC tutorial.
 A CRC is a long-division remainder.  You add the CRC to the message,
 and the whole thing (message+CRC) is a multiple of the given
 CRC polynomial.  To check the CRC, you can either check that the
 CRC matches the recomputed value, *or* you can check that the
 remainder computed on the message+CRC is 0.  This latter approach
 is used by a lot of hardware implementations, and is why so many
 protocols put the end-of-frame flag after the CRC.
 It's actually the same long division you learned in school, except that
 - We're working in binary, so the digits are only 0 and 1, and
 - When dividing polynomials, there are no carries.  Rather than add and
  subtract, we just xor.  Thus, we tend to get a bit sloppy about
  the difference between adding and subtracting.
 Like all division, the remainder is always smaller than the divisor.
 To produce a 32-bit CRC, the divisor is actually a 33-bit CRC polynomial.
 Since it's 33 bits long, bit 32 is always going to be set, so usually the
 CRC is written in hex with the most significant bit omitted.  (If you're
 familiar with the IEEE 754 floating-point format, it's the same idea.)
 Note that a CRC is computed over a string of *bits*, so you have
 to decide on the endianness of the bits within each byte.  To get
 the best error-detecting properties, this should correspond to the
 order they're actually sent.  For example, standard RS-232 serial is
 little-endian; the most significant bit (sometimes used for parity)
 is sent last.  And when appending a CRC word to a message, you should
 do it in the right order, matching the endianness.
 Just like with ordinary division, you proceed one digit (bit) at a time.
 Each step of the division you take one more digit (bit) of the dividend
 and append it to the current remainder.  Then you figure out the
 appropriate multiple of the divisor to subtract to being the remainder
 back into range.  In binary, this is easy - it has to be either 0 or 1,
 and to make the XOR cancel, it's just a copy of bit 32 of the remainder.
 When computing a CRC, we don't care about the quotient, so we can
 throw the quotient bit away, but subtract the appropriate multiple of
 the polynomial from the remainder and we're back to where we started,
 ready to process the next bit.
 A big-endian CRC written this way would be coded like:
 for (i = 0; i < input_bits; i++) {
 	multiple = remainder & 0x80000000 ? CRCPOLY : 0;
 	remainder = (remainder << 1 | next_input_bit()) ^ multiple;
 }
 Notice how, to get at bit 32 of the shifted remainder, we look
 at bit 31 of the remainder *before* shifting it.
 But also notice how the next_input_bit() bits we're shifting into
 the remainder don't actually affect any decision-making until
 32 bits later.  Thus, the first 32 cycles of this are pretty boring.
 Also, to add the CRC to a message, we need a 32-bit-long hole for it at
 the end, so we have to add 32 extra cycles shifting in zeros at the
 end of every message,
 These details lead to a standard trick: rearrange merging in the
 next_input_bit() until the moment it's needed.  Then the first 32 cycles
 can be precomputed, and merging in the final 32 zero bits to make room
 for the CRC can be skipped entirely.  This changes the code to:
 for (i = 0; i < input_bits; i++) {
 	remainder ^= next_input_bit() << 31;
 	multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
 	remainder = (remainder << 1) ^ multiple;
 }
 With this optimization, the little-endian code is particularly simple:
 for (i = 0; i < input_bits; i++) {
 	remainder ^= next_input_bit();
 	multiple = (remainder & 1) ? CRCPOLY : 0;
 	remainder = (remainder >> 1) ^ multiple;
 }
 The most significant coefficient of the remainder polynomial is stored
 in the least significant bit of the binary "remainder" variable.
 The other details of endianness have been hidden in CRCPOLY (which must
 be bit-reversed) and next_input_bit().
 As long as next_input_bit is returning the bits in a sensible order, we don't
 *have* to wait until the last possible moment to merge in additional bits.
 We can do it 8 bits at a time rather than 1 bit at a time:
 for (i = 0; i < input_bytes; i++) {
 	remainder ^= next_input_byte() << 24;
 	for (j = 0; j < 8; j++) {
 		multiple = (remainder & 0x80000000) ? CRCPOLY : 0;
 		remainder = (remainder << 1) ^ multiple;
 	}
 }
 Or in little-endian:
 for (i = 0; i < input_bytes; i++) {
 	remainder ^= next_input_byte();
 	for (j = 0; j < 8; j++) {
 		multiple = (remainder & 1) ? CRCPOLY : 0;
 		remainder = (remainder >> 1) ^ multiple;
 	}
 }
 If the input is a multiple of 32 bits, you can even XOR in a 32-bit
 word at a time and increase the inner loop count to 32.
 You can also mix and match the two loop styles, for example doing the
 bulk of a message byte-at-a-time and adding bit-at-a-time processing
 for any fractional bytes at the end.
 To reduce the number of conditional branches, software commonly uses
 the byte-at-a-time table method, popularized by Dilip V. Sarwate,
 "Computation of Cyclic Redundancy Checks via Table Look-Up", Comm. ACM
 v.31 no.8 (August 1998) p. 1008-1013.
 Here, rather than just shifting one bit of the remainder to decide
 in the correct multiple to subtract, we can shift a byte at a time.
 This produces a 40-bit (rather than a 33-bit) intermediate remainder,
 and the correct multiple of the polynomial to subtract is found using
 a 256-entry lookup table indexed by the high 8 bits.
 (The table entries are simply the CRC-32 of the given one-byte messages.)
 When space is more constrained, smaller tables can be used, e.g. two
 4-bit shifts followed by a lookup in a 16-entry table.
 It is not practical to process much more than 8 bits at a time using this
 technique, because tables larger than 256 entries use too much memory and,
 more importantly, too much of the L1 cache.
 To get higher software performance, a "slicing" technique can be used.
 See "High Octane CRC Generation with the Intel Slicing-by-8 Algorithm",
 ftp://download.intel.com/technology/comms/perfnet/download/slicing-by-8.pdf
 This does not change the number of table lookups, but does increase
 the parallelism.  With the classic Sarwate algorithm, each table lookup
 must be completed before the index of the next can be computed.
 A "slicing by 2" technique would shift the remainder 16 bits at a time,
 producing a 48-bit intermediate remainder.  Rather than doing a single
 lookup in a 65536-entry table, the two high bytes are looked up in
 two different 256-entry tables.  Each contains the remainder required
 to cancel out the corresponding byte.  The tables are different because the
 polynomials to cancel are different.  One has non-zero coefficients from
 x^32 to x^39, while the other goes from x^40 to x^47.
 Since modern processors can handle many parallel memory operations, this
 takes barely longer than a single table look-up and thus performs almost
 twice as fast as the basic Sarwate algorithm.
 This can be extended to "slicing by 4" using 4 256-entry tables.
 Each step, 32 bits of data is fetched, XORed with the CRC, and the result
 broken into bytes and looked up in the tables.  Because the 32-bit shift
 leaves the low-order bits of the intermediate remainder zero, the
 final CRC is simply the XOR of the 4 table look-ups.
 But this still enforces sequential execution: a second group of table
 look-ups cannot begin until the previous groups 4 table look-ups have all
 been completed.  Thus, the processor's load/store unit is sometimes idle.
 To make maximum use of the processor, "slicing by 8" performs 8 look-ups
 in parallel.  Each step, the 32-bit CRC is shifted 64 bits and XORed
 with 64 bits of input data.  What is important to note is that 4 of
 those 8 bytes are simply copies of the input data; they do not depend
 on the previous CRC at all.  Thus, those 4 table look-ups may commence
 immediately, without waiting for the previous loop iteration.
 By always having 4 loads in flight, a modern superscalar processor can
 be kept busy and make full use of its L1 cache.
 Two more details about CRC implementation in the real world:
 Normally, appending zero bits to a message which is already a multiple
 of a polynomial produces a larger multiple of that polynomial.  Thus,
 a basic CRC will not detect appended zero bits (or bytes).  To enable
 a CRC to detect this condition, it's common to invert the CRC before
 appending it.  This makes the remainder of the message+crc come out not
 as zero, but some fixed non-zero value.  (The CRC of the inversion
 pattern, 0xffffffff.)
 The same problem applies to zero bits prepended to the message, and a
 similar solution is used.  Instead of starting the CRC computation with
 a remainder of 0, an initial remainder of all ones is used.  As long as
 you start the same way on decoding, it doesn't make a difference.
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@ -28,7 +28,7 @@ The target is named "raid" and it accepts the following parameters:
  raid6_nc	RAID6 N continue
 		- rotating parity N (right-to-left) with data continuation
-  Refererence: Chapter 4 of
+  Reference: Chapter 4 of
  http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
 <#raid_params>: The number of parameters that follow.
--- a/Documentation/device-mapper/persistent-data.txt
+++ b/Documentation/device-mapper/persistent-data.txt
@ -3,7 +3,7 @@ Introduction
 The more-sophisticated device-mapper targets require complex metadata
 that is managed in kernel.  In late 2010 we were seeing that various
-different targets were rolling their own data strutures, for example:
+different targets were rolling their own data structures, for example:
 - Mikulas Patocka's multisnap implementation
 - Heinz Mauelshagen's thin provisioning target
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@ -1,7 +1,7 @@
 Introduction
 ============
-This document descibes a collection of device-mapper targets that
+This document describes a collection of device-mapper targets that
 between them implement thin-provisioning and snapshots.
 The main highlight of this implementation, compared to the previous
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@ -0,0 +1,21 @@
 * Samsung Exynos Power Domains
 Exynos processors include support for multiple power domains which are used
 to gate power to one or more peripherals on the processor.
 Required Properties:
 - compatiable: should be one of the following.
    * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
    region.
 Optional Properties:
 - samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
    state during boot and remains to be turned-off until explicitly turned-on.
 Example:
 	lcd0: power-domain-lcd0 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10023C00 0x10>;
 	};
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@ -5,7 +5,7 @@ IPs present in the SoC.
 On top of that an omap_device is created to extend the platform_device
 capabilities and to allow binding with one or several hwmods.
 The hwmods will contain all the information to build the device:
-adresse range, irq lines, dma lines, interconnect, PRCM register,
+address range, irq lines, dma lines, interconnect, PRCM register,
 clock domain, input clocks.
 For the moment just point to the existing hwmod, the next step will be
 to move data from hwmod to device-tree representation.
@ -41,3 +41,9 @@ Boards:
 - OMAP4 PandaBoard : Low cost community board
  compatible = "ti,omap4-panda", "ti,omap4430"
 - OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
  compatible = "ti,omap3-evm", "ti,omap3"
 - AM335X EVM : Software Developement Board for AM335x
  compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
--- a/Documentation/devicetree/bindings/arm/sirf.txt
+++ b/Documentation/devicetree/bindings/arm/sirf.txt
@ -1,3 +1,3 @@
-prima2 "cb" evalutation board
+prima2 "cb" evaluation board
 Required root node properties:
    - compatible = "sirf,prima2-cb", "sirf,prima2";
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@ -0,0 +1,19 @@
 A simple common binding for matrix-connected key boards. Currently targeted at
 defining the keys in the scope of linux key codes since that is a stable and
 standardized interface at this time.
 Required properties:
 - linux,keymap: an array of packed 1-cell entries containing the equivalent
  of row, column and linux key-code. The 32-bit big endian cell is packed
  as:
 	row << 24 | column << 16 | key-code
 Optional properties:
 Some users of this binding might choose to specify secondary keymaps for
 cases where there is a modifier key such as a Fn key. Proposed names
 for said properties are "linux,fn-keymap" or with another descriptive
 word for the modifier other from "Fn".
 Example:
 	linux,keymap = < 0x00030012
 			 0x0102003a >;
--- a/Documentation/devicetree/bindings/input/tegra-kbc.txt
+++ b/Documentation/devicetree/bindings/input/tegra-kbc.txt
@ -3,16 +3,21 @@
 Required properties:
 - compatible: "nvidia,tegra20-kbc"
-Optional properties:
+Optional properties, in addition to those specified by the shared
- debounce-delay: delay in milliseconds per row scan for debouncing
+matrix-keyboard bindings:
- repeat-delay: delay in milliseconds before repeat starts
+
- ghost-filter: enable ghost filtering for this device
+- linux,fn-keymap: a second keymap, same specification as the
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
+  matrix-keyboard-controller spec but to be used when the KEY_FN modifier
  key is pressed.
 - nvidia,debounce-delay-ms: delay in milliseconds per row scan for debouncing
 - nvidia,repeat-delay-ms: delay in milliseconds before repeat starts
 - nvidia,ghost-filter: enable ghost filtering for this device
 - nvidia,wakeup-source: configure keyboard as a wakeup source for suspend/resume
 Example:
 keyboard: keyboard {
 	compatible = "nvidia,tegra20-kbc";
 	reg = <0x7000e200 0x100>;
-	ghost-filter;
+	nvidia,ghost-filter;
 };
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@ -0,0 +1,28 @@
 * STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
 Required properties:
 - compatible: Should be "st,spear600-gmac"
 - reg: Address and length of the register set for the device
 - interrupt-parent: Should be the phandle for the interrupt controller
  that services interrupts for this device
 - interrupts: Should contain the STMMAC interrupts
 - interrupt-names: Should contain the interrupt names "macirq"
  "eth_wake_irq" if this interrupt is supported in the "interrupts"
  property
 - phy-mode: String, operation mode of the PHY interface.
  Supported values are: "mii", "rmii", "gmii", "rgmii".
 Optional properties:
 - mac-address: 6 bytes, mac address
 Examples:
 	gmac0: ethernet@e0800000 {
 		compatible = "st,spear600-gmac";
 		reg = <0xe0800000 0x8000>;
 		interrupt-parent = <&vic1>;
 		interrupts = <24 23>;
 		interrupt-names = "macirq", "eth_wake_irq";
 		mac-address = [000000000000]; /* Filled in by U-Boot */
 		phy-mode = "gmii";
 	};
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
@ -0,0 +1,63 @@
 * FSL MPIC Message Registers
 This binding specifies what properties must be available in the device tree
 representation of the message register blocks found in some FSL MPIC
 implementations.
 Required properties:
    - compatible: Specifies the compatibility list for the message register
      block.  The type shall be <string-list> and the value shall be of the form
      "fsl,mpic-v<version>-msgr", where <version> is the version number of
      the MPIC containing the message registers.
    - reg: Specifies the base physical address(s) and size(s) of the
      message register block's addressable register space.  The type shall be
      <prop-encoded-array>.
    - interrupts: Specifies a list of interrupt-specifiers which are available
      for receiving interrupts. Interrupt-specifier consists of two cells: first
      cell is interrupt-number and second cell is level-sense. The type shall be
      <prop-encoded-array>.
 Optional properties:
    - mpic-msgr-receive-mask: Specifies what registers in the containing block
      are allowed to receive interrupts. The value is a bit mask where a set
      bit at bit 'n' indicates that message register 'n' can receive interrupts.
      Note that "bit 'n'" is numbered from LSB for PPC hardware. The type shall
      be <u32>. If not present, then all of the message registers in the block
      are available.
 Aliases:
    An alias should be created for every message register block.  They are not
    required, though.  However, a particular implementation of this binding
    may require aliases to be present.  Aliases are of the form
    'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
    Numbers shall start at 0.
 Example:
 	aliases {
 		mpic-msgr-block0 = &mpic_msgr_block0;
 		mpic-msgr-block1 = &mpic_msgr_block1;
 	};
 	mpic_msgr_block0: mpic-msgr-block@41400 {
 		compatible = "fsl,mpic-v3.1-msgr";
 		reg = <0x41400 0x200>;
 		// Message registers 0 and 2 in this block can receive interrupts on
 		// sources 0xb0 and 0xb2, respectively.
 		interrupts = <0xb0 2 0xb2 2>;
 		mpic-msgr-receive-mask = <0x5>;
 	};
 	mpic_msgr_block1: mpic-msgr-block@42400 {
 		compatible = "fsl,mpic-v3.1-msgr";
 		reg = <0x42400 0x200>;
 		// Message registers 0 and 2 in this block can receive interrupts on
 		// sources 0xb4 and 0xb6, respectively.
 		interrupts = <0xb4 2 0xb6 2>;
 		mpic-msgr-receive-mask = <0x5>;
 	};
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
@ -56,7 +56,27 @@ PROPERTIES
          to the client.  The presence of this property also mandates
          that any initialization related to interrupt sources shall
          be limited to sources explicitly referenced in the device tree.
-       
+
  - big-endian
      Usage: optional
      Value type: <empty>
          If present the MPIC will be assumed to be big-endian.  Some
          device-trees omit this property on MPIC nodes even when the MPIC is
          in fact big-endian, so certain boards override this property.
  - single-cpu-affinity
      Usage: optional
      Value type: <empty>
          If present the MPIC will be assumed to only be able to route
          non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC).
  - last-interrupt-source
      Usage: optional
      Value type: <u32>
          Some MPICs do not correctly report the number of hardware sources
          in the global feature registers.  If specified, this field will
          override the value read from MPIC_GREG_FEATURE_LAST_SRC.
 INTERRUPT SPECIFIER DEFINITION
  Interrupt specifiers consists of 4 cells encoded as
--- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
@ -6,8 +6,10 @@ Required properties:
  etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
  the parent type.
- reg : should contain the address and the length of the shared message
+- reg : It may contain one or two regions. The first region should contain
-  interrupt register set.
+  the address and the length of the shared message interrupt register set.
  The second region should contain the address of aliased MSIIR register for
  platforms that have such an alias.
 - msi-available-ranges: use <start count> style section to define which
  msi interrupt can be used in the 256 msi interrupts. This property is
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@ -0,0 +1,68 @@
 TWL family of regulators
 Required properties:
 For twl6030 regulators/LDOs
 - compatible:
  - "ti,twl6030-vaux1" for VAUX1 LDO
  - "ti,twl6030-vaux2" for VAUX2 LDO
  - "ti,twl6030-vaux3" for VAUX3 LDO
  - "ti,twl6030-vmmc" for VMMC LDO
  - "ti,twl6030-vpp" for VPP LDO
  - "ti,twl6030-vusim" for VUSIM LDO
  - "ti,twl6030-vana" for VANA LDO
  - "ti,twl6030-vcxio" for VCXIO LDO
  - "ti,twl6030-vdac" for VDAC LDO
  - "ti,twl6030-vusb" for VUSB LDO
  - "ti,twl6030-v1v8" for V1V8 LDO
  - "ti,twl6030-v2v1" for V2V1 LDO
  - "ti,twl6030-clk32kg" for CLK32KG RESOURCE
  - "ti,twl6030-vdd1" for VDD1 SMPS
  - "ti,twl6030-vdd2" for VDD2 SMPS
  - "ti,twl6030-vdd3" for VDD3 SMPS
 For twl6025 regulators/LDOs
 - compatible:
  - "ti,twl6025-ldo1" for LDO1 LDO
  - "ti,twl6025-ldo2" for LDO2 LDO
  - "ti,twl6025-ldo3" for LDO3 LDO
  - "ti,twl6025-ldo4" for LDO4 LDO
  - "ti,twl6025-ldo5" for LDO5 LDO
  - "ti,twl6025-ldo6" for LDO6 LDO
  - "ti,twl6025-ldo7" for LDO7 LDO
  - "ti,twl6025-ldoln" for LDOLN LDO
  - "ti,twl6025-ldousb" for LDOUSB LDO
  - "ti,twl6025-smps3" for SMPS3 SMPS
  - "ti,twl6025-smps4" for SMPS4 SMPS
  - "ti,twl6025-vio" for VIO SMPS
 For twl4030 regulators/LDOs
 - compatible:
  - "ti,twl4030-vaux1" for VAUX1 LDO
  - "ti,twl4030-vaux2" for VAUX2 LDO
  - "ti,twl5030-vaux2" for VAUX2 LDO
  - "ti,twl4030-vaux3" for VAUX3 LDO
  - "ti,twl4030-vaux4" for VAUX4 LDO
  - "ti,twl4030-vmmc1" for VMMC1 LDO
  - "ti,twl4030-vmmc2" for VMMC2 LDO
  - "ti,twl4030-vpll1" for VPLL1 LDO
  - "ti,twl4030-vpll2" for VPLL2 LDO
  - "ti,twl4030-vsim" for VSIM LDO
  - "ti,twl4030-vdac" for VDAC LDO
  - "ti,twl4030-vintana2" for VINTANA2 LDO
  - "ti,twl4030-vio" for VIO LDO
  - "ti,twl4030-vdd1" for VDD1 SMPS
  - "ti,twl4030-vdd2" for VDD2 SMPS
  - "ti,twl4030-vintana1" for VINTANA1 LDO
  - "ti,twl4030-vintdig" for VINTDIG LDO
  - "ti,twl4030-vusb1v5" for VUSB1V5 LDO
  - "ti,twl4030-vusb1v8" for VUSB1V8 LDO
  - "ti,twl4030-vusb3v1" for VUSB3V1 LDO
 Optional properties:
 - Any optional property defined in bindings/regulator/regulator.txt
 Example:
 	xyz: regulator@0 {
 		compatible = "ti,twl6030-vaux1";
 		regulator-min-microvolt  = <1000000>;
 		regulator-max-microvolt  = <3000000>;
 	};
--- a/Documentation/devicetree/bindings/sound/alc5632.txt
+++ b/Documentation/devicetree/bindings/sound/alc5632.txt
@ -0,0 +1,24 @@
 ALC5632 audio CODEC
 This device supports I2C only.
 Required properties:
  - compatible : "realtek,alc5632"
  - reg : the I2C address of the device.
  - gpio-controller : Indicates this device is a GPIO controller.
  - #gpio-cells : Should be two. The first cell is the pin number and the
    second cell is used to specify optional parameters (currently unused).
 Example:
 alc5632: alc5632@1e {
 	compatible = "realtek,alc5632";
 	reg = <0x1a>;
 	gpio-controller;
 	#gpio-cells = <2>;
 };
--- a/Documentation/devicetree/bindings/sound/imx-audmux.txt
+++ b/Documentation/devicetree/bindings/sound/imx-audmux.txt
@ -0,0 +1,13 @@
 Freescale Digital Audio Mux (AUDMUX) device
 Required properties:
 - compatible : "fsl,imx21-audmux" for AUDMUX version firstly used on i.MX21,
  or "fsl,imx31-audmux" for the version firstly used on i.MX31.
 - reg : Should contain AUDMUX registers location and length
 Example:
 audmux@021d8000 {
 	compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux";
 	reg = <0x021d8000 0x4000>;
 };
--- a/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
+++ b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt
--- a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt
+++ b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt
@ -0,0 +1,59 @@
 NVIDIA Tegra audio complex
 Required properties:
 - compatible : "nvidia,tegra-audio-alc5632"
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
  the second being the connection's source. Valid names for sources and
  sinks are the ALC5632's pins:
  ALC5632 pins:
  * SPK_OUTP
  * SPK_OUTN
  * HP_OUT_L
  * HP_OUT_R
  * AUX_OUT_P
  * AUX_OUT_N
  * LINE_IN_L
  * LINE_IN_R
  * PHONE_P
  * PHONE_N
  * MIC1_P
  * MIC1_N
  * MIC2_P
  * MIC2_N
  * MICBIAS1
  * DMICDAT
  Board connectors:
  * Headset Stereophone
  * Int Spk
  * Headset Mic
  * Digital Mic
 - nvidia,i2s-controller : The phandle of the Tegra I2S controller
 - nvidia,audio-codec : The phandle of the ALC5632 audio codec
 Example:
 sound {
 	compatible = "nvidia,tegra-audio-alc5632-paz00",
 				 "nvidia,tegra-audio-alc5632";
 	nvidia,model = "Compal PAZ00";
 	nvidia,audio-routing =
 				"Int Spk", "SPK_OUTP",
 				"Int Spk", "SPK_OUTN",
 				"Headset Mic","MICBIAS1",
 				"MIC1_N", "Headset Mic",
 				"MIC1_P", "Headset Mic",
 				"Headset Stereophone", "HP_OUT_R",
 				"Headset Stereophone", "HP_OUT_L";
 	nvidia,i2s-controller = <&tegra_i2s1>;
 	nvidia,audio-codec = <&alc5632>;
 };
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@ -0,0 +1,20 @@
 OMAP2+ McSPI device
 Required properties:
 - compatible :
  - "ti,omap2-spi" for OMAP2 & OMAP3.
  - "ti,omap4-spi" for OMAP4+.
 - ti,spi-num-cs : Number of chipselect supported  by the instance.
 - ti,hwmods: Name of the hwmod associated to the McSPI
 Example:
 mcspi1: mcspi@1 {
    #address-cells = <1>;
    #size-cells = <0>;
    compatible = "ti,omap4-mcspi";
    ti,hwmods = "mcspi1";
    ti,spi-num-cs = <4>;
 };
--- a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt
@ -0,0 +1,14 @@
 * Energymicro efm32 UART
 Required properties:
 - compatible : Should be "efm32,uart"
 - reg : Address and length of the register set
 - interrupts : Should contain uart interrupt
 Example:
 uart@0x4000c400 {
 	compatible = "efm32,uart";
 	reg = <0x4000c400 0x400>;
 	interrupts = <15>;
 };
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@ -34,6 +34,7 @@ picochip	Picochip Ltd
 powervr	Imagination Technologies
 qcom	Qualcomm, Inc.
 ramtron	Ramtron International
 realtek Realtek Semiconductor Corp.
 samsung	Samsung Semiconductor
 sbs	Smart Battery System
 schindler	Schindler
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@ -169,7 +169,7 @@ it with special cases.
        b) Entry with a flattened device-tree block.  Firmware loads the
        physical address of the flattened device tree block (dtb) into r2,
-        r1 is not used, but it is considered good practise to use a valid
+        r1 is not used, but it is considered good practice to use a valid
        machine number as described in Documentation/arm/Booting.
                r0 : 0
--- a/Documentation/dmaengine.txt
+++ b/Documentation/dmaengine.txt
@ -63,7 +63,7 @@ The slave DMA usage consists of following steps:
 				  struct dma_slave_config *config)
   Please see the dma_slave_config structure definition in dmaengine.h
-   for a detailed explaination of the struct members.  Please note
+   for a detailed explanation of the struct members.  Please note
   that the 'direction' member will be going away as it duplicates the
   direction given in the prepare call.
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@ -271,3 +271,8 @@ IOMAP
  pcim_iounmap()
  pcim_iomap_table()	: array of mapped addresses indexed by BAR
  pcim_iomap_regions()	: do request_region() and iomap() on multiple BARs
 REGULATOR
  devm_regulator_get()
  devm_regulator_put()
  devm_regulator_bulk_get()
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@ -12,7 +12,7 @@ dynamically enabled per-callsite.
 Dynamic debug has even more useful features:
 * Simple query language allows turning on and off debugging statements by
-   matching any combination of:
+   matching any combination of 0 or 1 of:
   - source filename
   - function name
@ -79,31 +79,24 @@ Command Language Reference
 ==========================
 At the lexical level, a command comprises a sequence of words separated
-by whitespace characters.  Note that newlines are treated as word
+by spaces or tabs.  So these are all equivalent:
 separators and do *not* end a command or allow multiple commands to
 be done together.  So these are all equivalent:
 nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >
 				<debugfs>/dynamic_debug/control
 nullarbor:~ # echo -c '  file   svcsock.c     line  1603 +p  ' >
 				<debugfs>/dynamic_debug/control
 nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >
 				<debugfs>/dynamic_debug/control
 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
 				<debugfs>/dynamic_debug/control
-Commands are bounded by a write() system call.  If you want to do
+Command submissions are bounded by a write() system call.
-multiple commands you need to do a separate "echo" for each, like:
+Multiple commands can be written together, separated by ';' or '\n'.
-nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\
+  ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
-> echo 'file svcsock.c line 1563 +p' > /proc/dprintk
+     > <debugfs>/dynamic_debug/control
-or even like:
+If your query set is big, you can batch them too:
-nullarbor:~ # (
+  ~# cat query-batch-file > <debugfs>/dynamic_debug/control
 > echo 'file svcsock.c line 1603 +p' ;\
 > echo 'file svcsock.c line 1563 +p' ;\
 > ) > /proc/dprintk
 At the syntactical level, a command comprises a sequence of match
 specifications, followed by a flags change specification.
@ -144,11 +137,12 @@ func
    func svc_tcp_accept
 file
-    The given string is compared against either the full
+    The given string is compared against either the full pathname, the
-    pathname or the basename of the source file of each
+    src-root relative pathname, or the basename of the source file of
-    callsite.  Examples:
+    each callsite.  Examples:
    file svcsock.c
    file kernel/freezer.c
    file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
 module
--- a/Documentation/fb/matroxfb.txt
+++ b/Documentation/fb/matroxfb.txt
@ -177,8 +177,8 @@ sgram    - tells to driver that you have Gxx0 with SGRAM memory. It has no
           effect without `init'.
 sdram    - tells to driver that you have Gxx0 with SDRAM memory.
           It is a default.
-inv24    - change timings parameters for 24bpp modes on Millenium and
+inv24    - change timings parameters for 24bpp modes on Millennium and
-           Millenium II. Specify this if you see strange color shadows around
+           Millennium II. Specify this if you see strange color shadows around
 	   characters.
 noinv24  - use standard timings. It is the default.
 inverse  - invert colors on screen (for LCD displays)
@ -204,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
 	    can paint colors.
 nograyscale - disable grayscale summing. It is default.
 cross4MB - enables that pixel line can cross 4MB boundary. It is default for
-           non-Millenium.
+           non-Millennium.
 nocross4MB - pixel line must not cross 4MB boundary. It is default for
-             Millenium I or II, because of these devices have hardware
+             Millennium I or II, because of these devices have hardware
 	     limitations which do not allow this. But this option is
 	     incompatible with some (if not all yet released) versions of
 	     XF86_FBDev.
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@ -524,3 +524,22 @@ Files:	arch/arm/mach-at91/at91cap9.c
 Why:	The code is not actively maintained and platforms are now hard to find.
 Who:	Nicolas Ferre <nicolas.ferre@atmel.com>
 	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
 ----------------------------
 What:	Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
 When:	3.6
 Why:	This driver provides support for USB storage devices like "USB
 	sticks". As of now, it is deactivated in Debian, Fedora and
        Ubuntu. All current users can switch over to usb-storage
        (CONFIG_USB_STORAGE) which only drawback is the additional SCSI
        stack.
 Who:	Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
 ----------------------------
 What:	kmap_atomic(page, km_type)
 When:	3.5
 Why:	The old kmap_atomic() with two arguments is deprecated, we only
 	keep it for backward compatibility for few cycles and then drop it.
 Who:	Cong Wang <amwang@redhat.com>
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@ -14,7 +14,10 @@ Debugfs is typically mounted with a command like:
    mount -t debugfs none /sys/kernel/debug
-(Or an equivalent /etc/fstab line). 
+(Or an equivalent /etc/fstab line).
 The debugfs root directory is accessible by anyone by default. To
 restrict access to the tree the "uid", "gid" and "mode" mount
 options can be used.
 Note that the debugfs API is exported GPL-only to modules.
@ -133,7 +136,7 @@ file.
 	void __iomem *base;
    };
-    struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
+    struct dentry *debugfs_create_regset32(const char *name, umode_t mode,
 				     struct dentry *parent,
 				     struct debugfs_regset32 *regset);
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@ -308,7 +308,7 @@ min_batch_time=usec	This parameter sets the commit time (as
 			fast disks, at the cost of increasing latency.
 journal_ioprio=prio	The I/O priority (from 0 to 7, where 0 is the
-			highest priorty) which should be used for I/O
+			highest priority) which should be used for I/O
 			operations submitted by kjournald2 during a
 			commit operation.  This defaults to 3, which is
 			a slightly higher priority than the default I/O
@ -343,7 +343,7 @@ noinit_itable		Do not initialize any uninitialized inode table
 init_itable=n		The lazy itable init code will wait n times the
 			number of milliseconds it took to zero out the
 			previous block group's inode table.  This
-			minimizes the impact on the systme performance
+			minimizes the impact on the system performance
 			while file system's inode table is being initialized.
 discard			Controls whether ext4 should issue discard/TRIM
--- a/Documentation/filesystems/gfs2-uevents.txt
+++ b/Documentation/filesystems/gfs2-uevents.txt
@ -62,7 +62,7 @@ be fixed.
 The REMOVE uevent is generated at the end of an unsuccessful mount
 or at the end of a umount of the filesystem. All REMOVE uevents will
-have been preceded by at least an ADD uevent for the same fileystem,
+have been preceded by at least an ADD uevent for the same filesystem,
 and unlike the other uevents is generated automatically by the kernel's
 kobject subsystem.
--- a/Documentation/filesystems/nfs/idmapper.txt
+++ b/Documentation/filesystems/nfs/idmapper.txt
@ -4,13 +4,21 @@ ID Mapper
 =========
 Id mapper is used by NFS to translate user and group ids into names, and to
 translate user and group names into ids.  Part of this translation involves
-performing an upcall to userspace to request the information.  Id mapper will
+performing an upcall to userspace to request the information.  There are two
-user request-key to perform this upcall and cache the result.  The program
+ways NFS could obtain this information: placing a call to /sbin/request-key
-/usr/sbin/nfs.idmap should be called by request-key, and will perform the
+or by placing a call to the rpc.idmap daemon.
-translation and initialize a key with the resulting information.
+
 NFS will attempt to call /sbin/request-key first.  If this succeeds, the
 result will be cached using the generic request-key cache.  This call should
 only fail if /etc/request-key.conf is not configured for the id_resolver key
 type, see the "Configuring" section below if you wish to use the request-key
 method.
 If the call to /sbin/request-key fails (if /etc/request-key.conf is not
 configured with the id_resolver key type), then the idmapper will ask the
 legacy rpc.idmap daemon for the id mapping.  This result will be stored
 in a custom NFS idmap cache.
 NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
 feature.
 ===========
 Configuring
--- a/Documentation/filesystems/nfs/pnfs.txt
+++ b/Documentation/filesystems/nfs/pnfs.txt
@ -53,3 +53,57 @@ lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
 bit which holds it in the pnfs_layout_hdr's list.  When the final lseg
 is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
 bit is set, preventing any new lsegs from being added.
 layout drivers
 --------------
 PNFS utilizes what is called layout drivers. The STD defines 3 basic
 layout types: "files" "objects" and "blocks". For each of these types
 there is a layout-driver with a common function-vectors table which
 are called by the nfs-client pnfs-core to implement the different layout
 types.
 Files-layout-driver code is in: fs/nfs/nfs4filelayout.c && nfs4filelayoutdev.c
 Objects-layout-deriver code is in: fs/nfs/objlayout/.. directory
 Blocks-layout-deriver code is in: fs/nfs/blocklayout/.. directory
 objects-layout setup
 --------------------
 As part of the full STD implementation the objlayoutdriver.ko needs, at times,
 to automatically login to yet undiscovered iscsi/osd devices. For this the
 driver makes up-calles to a user-mode script called *osd_login*
 The path_name of the script to use is by default:
 	/sbin/osd_login.
 This name can be overridden by the Kernel module parameter:
 	objlayoutdriver.osd_login_prog
 If Kernel does not find the osd_login_prog path it will zero it out
 and will not attempt farther logins. An admin can then write new value
 to the objlayoutdriver.osd_login_prog Kernel parameter to re-enable it.
 The /sbin/osd_login is part of the nfs-utils package, and should usually
 be installed on distributions that support this Kernel version.
 The API to the login script is as follows:
 	Usage: $0 -u <URI> -o <OSDNAME> -s <SYSTEMID>
 	Options:
 		-u		target uri e.g. iscsi://<ip>:<port>
 				(allways exists)
 				(More protocols can be defined in the future.
 				 The client does not interpret this string it is
 				 passed unchanged as recieved from the Server)
 		-o		osdname of the requested target OSD
 				(Might be empty)
 				(A string which denotes the OSD name, there is a
 				 limit of 64 chars on this string)
 		-s 		systemid of the requested target OSD
 				(Might be empty)
 				(This string, if not empty is always an hex
 				 representation of the 20 bytes osd_system_id)
 blocks-layout setup
 -------------------
 TODO: Document the setup needs of the blocks layout driver
--- a/Documentation/filesystems/pohmelfs/network_protocol.txt
+++ b/Documentation/filesystems/pohmelfs/network_protocol.txt
@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
 so one can extend protocol as needed without breaking backward compatibility as long
 as old commands are supported. All string lengths include tail 0 byte.
-All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
+All commands are transferred over the network in big-endian. CPU endianness is used at the end peers.
@cmd - command number, which specifies command to be processed. Following
 	commands are used currently:
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@ -429,3 +429,9 @@ filemap_write_and_wait_range() so that all dirty pages are synced out properly.
 You must also keep in mind that ->fsync() is not called with i_mutex held
 anymore, so if you require i_mutex locking you must make sure to take it and
 release it yourself.
 --
 [mandatory]
 	d_alloc_root() is gone, along with a lot of bugs caused by code
 misusing it.  Replacement: d_make_root(inode).  The difference is,
 d_make_root() drops the reference to inode if dentry allocation fails.  
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@ -290,7 +290,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
  rsslim        current limit in bytes on the rss
  start_code    address above which program text can run
  end_code      address below which program text can run
-  start_stack   address of the start of the stack
+  start_stack   address of the start of the main process stack
  esp           current value of ESP
  eip           current value of EIP
  pending       bitmap of pending signals
@ -325,7 +325,7 @@ address           perms offset  dev   inode      pathname
 a7cb1000-a7cb2000 ---p 00000000 00:00 0
 a7cb2000-a7eb2000 rw-p 00000000 00:00 0
 a7eb2000-a7eb3000 ---p 00000000 00:00 0
-a7eb3000-a7ed5000 rw-p 00000000 00:00 0
+a7eb3000-a7ed5000 rw-p 00000000 00:00 0          [stack:1001]
 a7ed5000-a8008000 r-xp 00000000 03:00 4222       /lib/libc.so.6
 a8008000-a800a000 r--p 00133000 03:00 4222       /lib/libc.so.6
 a800a000-a800b000 rw-p 00135000 03:00 4222       /lib/libc.so.6
@ -357,11 +357,39 @@ is not associated with a file:
 [heap]                   = the heap of the program
 [stack]                  = the stack of the main process
 [stack:1001]             = the stack of the thread with tid 1001
 [vdso]                   = the "virtual dynamic shared object",
                            the kernel system call handler
 or if empty, the mapping is anonymous.
 The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint
 of the individual tasks of a process. In this file you will see a mapping marked
 as [stack] if that task sees it as a stack. This is a key difference from the
 content of /proc/PID/maps, where you will see all mappings that are being used
 as stack by all of those tasks. Hence, for the example above, the task-level
 map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this:
 08048000-08049000 r-xp 00000000 03:00 8312       /opt/test
 08049000-0804a000 rw-p 00001000 03:00 8312       /opt/test
 0804a000-0806b000 rw-p 00000000 00:00 0          [heap]
 a7cb1000-a7cb2000 ---p 00000000 00:00 0
 a7cb2000-a7eb2000 rw-p 00000000 00:00 0
 a7eb2000-a7eb3000 ---p 00000000 00:00 0
 a7eb3000-a7ed5000 rw-p 00000000 00:00 0          [stack]
 a7ed5000-a8008000 r-xp 00000000 03:00 4222       /lib/libc.so.6
 a8008000-a800a000 r--p 00133000 03:00 4222       /lib/libc.so.6
 a800a000-a800b000 rw-p 00135000 03:00 4222       /lib/libc.so.6
 a800b000-a800e000 rw-p 00000000 00:00 0
 a800e000-a8022000 r-xp 00000000 03:00 14462      /lib/libpthread.so.0
 a8022000-a8023000 r--p 00013000 03:00 14462      /lib/libpthread.so.0
 a8023000-a8024000 rw-p 00014000 03:00 14462      /lib/libpthread.so.0
 a8024000-a8027000 rw-p 00000000 00:00 0
 a8027000-a8043000 r-xp 00000000 03:00 8317       /lib/ld-linux.so.2
 a8043000-a8044000 r--p 0001b000 03:00 8317       /lib/ld-linux.so.2
 a8044000-a8045000 rw-p 0001c000 03:00 8317       /lib/ld-linux.so.2
 aff35000-aff4a000 rw-p 00000000 00:00 0
 ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
 The /proc/PID/smaps is an extension based on maps, showing the memory
 consumption for each of the process's mappings. For each of mappings there
--- a/Documentation/filesystems/qnx6.txt
+++ b/Documentation/filesystems/qnx6.txt
@ -0,0 +1,174 @@
 The QNX6 Filesystem
 ===================
 The qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino)
 It got introduced in QNX 6.4.0 and is used default since 6.4.1.
 Option
 ======
 mmi_fs		Mount filesystem as used for example by Audi MMI 3G system
 Specification
 =============
 qnx6fs shares many properties with traditional Unix filesystems. It has the
 concepts of blocks, inodes and directories.
 On QNX it is possible to create little endian and big endian qnx6 filesystems.
 This feature makes it possible to create and use a different endianness fs
 for the target (QNX is used on quite a range of embedded systems) plattform
 running on a different endianess.
 The Linux driver handles endianness transparently. (LE and BE)
 Blocks
 ------
 The space in the device or file is split up into blocks. These are a fixed
 size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
 created.
 Blockpointers are 32bit, so the maximum space that can be adressed is
 2^32 * 4096 bytes or 16TB
 The superblocks
 ---------------
 The superblock contains all global information about the filesystem.
 Each qnx6fs got two superblocks, each one having a 64bit serial number.
 That serial number is used to identify the "active" superblock.
 In write mode with reach new snapshot (after each synchronous write), the
 serial of the new master superblock is increased (old superblock serial + 1)
 So basically the snapshot functionality is realized by an atomic final
 update of the serial number. Before updating that serial, all modifications
 are done by copying all modified blocks during that specific write request
 (or period) and building up a new (stable) filesystem structure under the
 inactive superblock.
 Each superblock holds a set of root inodes for the different filesystem
 parts. (Inode, Bitmap and Longfilenames)
 Each of these root nodes holds information like total size of the stored
 data and the adressing levels in that specific tree.
 If the level value is 0, up to 16 direct blocks can be adressed by each
 node.
 Level 1 adds an additional indirect adressing level where each indirect
 adressing block holds up to blocksize / 4 bytes pointers to data blocks.
 Level 2 adds an additional indirect adressig block level (so, already up
 to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
 Unused block pointers are always set to ~0 - regardless of root node,
 indirect adressing blocks or inodes.
 Data leaves are always on the lowest level. So no data is stored on upper
 tree levels.
 The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
 The Audi MMI 3G first superblock directly starts at byte 0.
 Second superblock position can either be calculated from the superblock
 information (total number of filesystem blocks) or by taking the highest
 device address, zeroing the last 3 bytes and then substracting 0x1000 from
 that address.
 0x1000 is the size reserved for each superblock - regardless of the
 blocksize of the filesystem.
 Inodes
 ------
 Each object in the filesystem is represented by an inode. (index node)
 The inode structure contains pointers to the filesystem blocks which contain
 the data held in the object and all of the metadata about an object except
 its longname. (filenames longer than 27 characters)
 The metadata about an object includes the permissions, owner, group, flags,
 size, number of blocks used, access time, change time and modification time.
 Object mode field is POSIX format. (which makes things easier)
 There are also pointers to the first 16 blocks, if the object data can be
 adressed with 16 direct blocks.
 For more than 16 blocks an indirect adressing in form of another tree is
 used. (scheme is the same as the one used for the superblock root nodes)
 The filesize is stored 64bit. Inode counting starts with 1. (whilst long
 filename inodes start with 0)
 Directories
 -----------
 A directory is a filesystem object and has an inode just like a file.
 It is a specially formatted file containing records which associate each
 name with an inode number.
 '.' inode number points to the directory inode
 '..' inode number points to the parent directory inode
 Eeach filename record additionally got a filename length field.
 One special case are long filenames or subdirectory names.
 These got set a filename length field of 0xff in the corresponding directory
 record plus the longfile inode number also stored in that record.
 With that longfilename inode number, the longfilename tree can be walked
 starting with the superblock longfilename root node pointers.
 Special files
 -------------
 Symbolic links are also filesystem objects with inodes. They got a specific
 bit in the inode mode field identifying them as symbolic link.
 The directory entry file inode pointer points to the target file inode.
 Hard links got an inode, a directory entry, but a specific mode bit set,
 no block pointers and the directory file record pointing to the target file
 inode.
 Character and block special devices do not exist in QNX as those files
 are handled by the QNX kernel/drivers and created in /dev independant of the
 underlaying filesystem.
 Long filenames
 --------------
 Long filenames are stored in a seperate adressing tree. The staring point
 is the longfilename root node in the active superblock.
 Each data block (tree leaves) holds one long filename. That filename is
 limited to 510 bytes. The first two starting bytes are used as length field
 for the actual filename.
 If that structure shall fit for all allowed blocksizes, it is clear why there
 is a limit of 510 bytes for the actual filename stored.
 Bitmap
 ------
 The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap
 root node in the superblock and each bit in the bitmap represents one
 filesystem block.
 The first block is block 0, which starts 0x1000 after superblock start.
 So for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical
 address at which block 0 is located.
 Bits at the end of the last bitmap block are set to 1, if the device is
 smaller than addressing space in the bitmap.
 Bitmap system area
 ------------------
 The bitmap itself is devided into three parts.
 First the system area, that is split into two halfs.
 Then userspace.
 The requirement for a static, fixed preallocated system area comes from how
 qnx6fs deals with writes.
 Each superblock got it's own half of the system area. So superblock #1
 always uses blocks from the lower half whilst superblock #2 just writes to
 blocks represented by the upper half bitmap system area bits.
 Bitmap blocks, Inode blocks and indirect addressing blocks for those two
 tree structures are treated as system blocks.
 The rational behind that is that a write request can work on a new snapshot
 (system area of the inactive - resp. lower serial numbered superblock) while
 at the same time there is still a complete stable filesystem structer in the
 other half of the system area.
 When finished with writing (a sync write is completed, the maximum sync leap
 time or a filesystem sync is requested), serial of the previously inactive
 superblock atomically is increased and the fs switches over to that - then
 stable declared - superblock.
 For all data outside the system area, blocks are just copied while writing.
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@ -297,7 +297,7 @@ the above threads) is:
   either way about the archive format, and there are alternative tools,
   such as:
-     http://freshmeat.net/projects/afio/
+     http://freecode.com/projects/afio
 2) The cpio archive format chosen by the kernel is simpler and cleaner (and
   thus easier to create and parse) than any of the (literally dozens of)
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@ -993,7 +993,7 @@ struct dentry_operations {
 	If the 'rcu_walk' parameter is true, then the caller is doing a
 	pathwalk in RCU-walk mode.  Sleeping is not permitted in this mode,
-	and the caller can be asked to leave it and call again by returing
+	and the caller can be asked to leave it and call again by returning
 	-ECHILD.
 	This function is only used if DCACHE_MANAGE_TRANSIT is set on the
--- a/Documentation/hwmon/adm1275
+++ b/Documentation/hwmon/adm1275
@ -2,6 +2,10 @@ Kernel driver adm1275
 =====================
 Supported chips:
  * Analog Devices ADM1075
    Prefix: 'adm1075'
    Addresses scanned: -
    Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1075.pdf
  * Analog Devices ADM1275
    Prefix: 'adm1275'
    Addresses scanned: -
@ -17,13 +21,13 @@ Author: Guenter Roeck <guenter.roeck@ericsson.com>
 Description
 -----------
-This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276
+This driver supports hardware montoring for Analog Devices ADM1075, ADM1275,
-Hot-Swap Controller and Digital Power Monitor.
+and ADM1276 Hot-Swap Controller and Digital Power Monitor.
-ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be
+ADM1075, ADM1275, and ADM1276 are hot-swap controllers that allow a circuit
-removed from or inserted into a live backplane. They also feature current and
+board to be removed from or inserted into a live backplane. They also feature
-voltage readback via an integrated 12-bit analog-to-digital converter (ADC),
+current and voltage readback via an integrated 12-bit analog-to-digital
-accessed using a PMBus interface.
+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.
@ -36,6 +40,10 @@ This driver does not auto-detect devices. You will have to instantiate the
 devices explicitly. Please see Documentation/i2c/instantiating-devices for
 details.
 The ADM1075, unlike many other PMBus devices, does not support internal voltage
 or current scaling. Reported voltages, currents, and power are raw measurements,
 and will typically have to be scaled.
 Platform data support
 ---------------------
@ -51,9 +59,10 @@ The following attributes are supported. Limits are read-write, history reset
 attributes are write-only, all other attributes are read-only.
 in1_label		"vin1" or "vout1" depending on chip variant and
-			configuration.
+			configuration. On ADM1075, vout1 reports the voltage on
 			the VAUX pin.
 in1_input		Measured voltage.
-in1_min			Minumum Voltage.
+in1_min			Minimum Voltage.
 in1_max			Maximum voltage.
 in1_min_alarm		Voltage low alarm.
 in1_max_alarm		Voltage high alarm.
@ -74,3 +83,10 @@ curr1_crit		Critical maximum current. Depending on the chip
 curr1_crit_alarm	Critical current high alarm.
 curr1_highest		Historical maximum current.
 curr1_reset_history	Write any value to reset history.
 power1_label		"pin1"
 power1_input		Input power.
 power1_reset_history	Write any value to reset history.
 			Power attributes are supported on ADM1075 and ADM1276
 			only.
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@ -3,71 +3,50 @@ Kernel driver jc42
 Supported chips:
  * Analog Devices ADT7408
    Prefix: 'adt7408'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
  * Atmel AT30TS00
    Prefix: 'at30ts00'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.atmel.com/Images/doc8585.pdf
  * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
    Prefix: 'tse2002', 'ts3000'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
 	http://www.idt.com/sites/default/files/documents/IDT_TSE2002GB2A1_DST_20111107_120303145914.pdf
 	http://www.idt.com/sites/default/files/documents/IDT_TS3000B3A_DST_20101129_120303152013.pdf
 	http://www.idt.com/sites/default/files/documents/IDT_TS3000GB2A1_DST_20111104_120303151012.pdf
  * Maxim MAX6604
    Prefix: 'max6604'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
  * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
    Prefixes: 'mcp9804', 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
 	http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
-  * NXP Semiconductors SE97, SE97B
+  * NXP Semiconductors SE97, SE97B, SE98, SE98A
    Prefix: 'se97'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.nxp.com/documents/data_sheet/SE97.pdf
 	http://www.nxp.com/documents/data_sheet/SE97B.pdf
  * NXP Semiconductors SE98
    Prefix: 'se98'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.nxp.com/documents/data_sheet/SE98.pdf
 	http://www.nxp.com/documents/data_sheet/SE98A.pdf
  * ON Semiconductor CAT34TS02, CAT6095
    Prefix: 'cat34ts02', 'cat6095'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheet:
 	http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
 	http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
-  * ST Microelectronics STTS424, STTS424E02
+  * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
    Prefix: 'stts424'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf
 	http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf
  * ST Microelectronics STTS2002, STTS3000
    Prefix: 'stts2002', 'stts3000'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheets:
 	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
 	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
 	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
 	http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
  * JEDEC JC 42.4 compliant temperature sensor chips
    Prefix: 'jc42'
    Addresses scanned: I2C 0x18 - 0x1f
    Datasheet:
 	http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
  Common for all chips:
    Prefix: 'jc42'
    Addresses scanned: I2C 0x18 - 0x1f
 Author:
 	Guenter Roeck <guenter.roeck@ericsson.com>
--- a/Documentation/hwmon/lm80
+++ b/Documentation/hwmon/lm80
@ -7,6 +7,11 @@ Supported chips:
    Addresses scanned: I2C 0x28 - 0x2f
    Datasheet: Publicly available at the National Semiconductor website
               http://www.national.com/
  * National Semiconductor LM96080
    Prefix: 'lm96080'
    Addresses scanned: I2C 0x28 - 0x2f
    Datasheet: Publicly available at the National Semiconductor website
               http://www.national.com/
 Authors:
        Frodo Looijaard <frodol@dds.nl>,
@ -17,7 +22,9 @@ Description
 This driver implements support for the National Semiconductor LM80.
 It is described as a 'Serial Interface ACPI-Compatible Microprocessor
-System Hardware Monitor'.
+System Hardware Monitor'. The LM96080 is a more recent incarnation,
 it is pin and register compatible, with a few additional features not
 yet supported by the driver.
 The LM80 implements one temperature sensor, two fan rotation speed sensors,
 seven voltage sensors, alarms, and some miscellaneous stuff.
--- a/Documentation/hwmon/max16064
+++ b/Documentation/hwmon/max16064
@ -42,9 +42,9 @@ attributes are read-only.
 in[1-4]_label		"vout[1-4]"
 in[1-4]_input		Measured voltage. From READ_VOUT register.
-in[1-4]_min		Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[1-4]_min		Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
 in[1-4]_max		Maximum voltage. From VOUT_OV_WARN_LIMIT register.
-in[1-4]_lcrit		Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[1-4]_lcrit		Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
 in[1-4]_crit		Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
 in[1-4]_min_alarm	Voltage low alarm. From VOLTAGE_UV_WARNING status.
 in[1-4]_max_alarm	Voltage high alarm. From VOLTAGE_OV_WARNING status.
--- a/Documentation/hwmon/max34440
+++ b/Documentation/hwmon/max34440
@ -11,6 +11,11 @@ Supported chips:
    Prefixes: 'max34441'
    Addresses scanned: -
    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
  * Maxim MAX34446
    PMBus Power-Supply Data Logger
    Prefixes: 'max34446'
    Addresses scanned: -
    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
 Author: Guenter Roeck <guenter.roeck@ericsson.com>
@ -19,8 +24,8 @@ Description
 -----------
 This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
-Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
+Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
-and Intelligent Fan Controller.
+and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
 The driver is a client driver to the core PMBus driver. Please see
 Documentation/hwmon/pmbus for details on PMBus client drivers.
@ -33,6 +38,13 @@ This driver does not auto-detect devices. You will have to instantiate the
 devices explicitly. Please see Documentation/i2c/instantiating-devices for
 details.
 For MAX34446, the value of the currX_crit attribute determines if current or
 voltage measurement is enabled for a given channel. Voltage measurement is
 enabled if currX_crit is set to 0; current measurement is enabled if the
 attribute is set to a positive value. Power measurement is only enabled if
 channel 1 (3) is configured for voltage measurement, and channel 2 (4) is
 configured for current measurement.
 Platform data support
 ---------------------
@ -48,27 +60,39 @@ attributes are read-only.
 in[1-6]_label		"vout[1-6]".
 in[1-6]_input		Measured voltage. From READ_VOUT register.
-in[1-6]_min		Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[1-6]_min		Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
 in[1-6]_max		Maximum voltage. From VOUT_OV_WARN_LIMIT register.
-in[1-6]_lcrit		Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[1-6]_lcrit		Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
 in[1-6]_crit		Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
 in[1-6]_min_alarm	Voltage low alarm. From VOLTAGE_UV_WARNING status.
 in[1-6]_max_alarm	Voltage high alarm. From VOLTAGE_OV_WARNING status.
 in[1-6]_lcrit_alarm	Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
 in[1-6]_crit_alarm	Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
 in[1-6]_lowest		Historical minimum voltage.
 in[1-6]_highest		Historical maximum voltage.
 in[1-6]_reset_history	Write any value to reset history.
 			MAX34446 only supports in[1-4].
 curr[1-6]_label		"iout[1-6]".
 curr[1-6]_input		Measured current. From READ_IOUT register.
 curr[1-6]_max		Maximum current. From IOUT_OC_WARN_LIMIT register.
 curr[1-6]_crit		Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
 curr[1-6]_max_alarm	Current high alarm. From IOUT_OC_WARNING status.
 curr[1-6]_crit_alarm	Current critical high alarm. From IOUT_OC_FAULT status.
 curr[1-4]_average	Historical average current (MAX34446 only).
 curr[1-6]_highest	Historical maximum current.
 curr[1-6]_reset_history	Write any value to reset history.
 			in6 and curr6 attributes only exist for MAX34440.
 			MAX34446 only supports curr[1-4].
 power[1,3]_label	"pout[1,3]"
 power[1,3]_input	Measured power.
 power[1,3]_average	Historical average power.
 power[1,3]_highest	Historical maximum power.
 			Power attributes only exist for MAX34446.
 temp[1-8]_input		Measured temperatures. From READ_TEMPERATURE_1 register.
 			temp1 is the chip's internal temperature. temp2..temp5
@ -79,7 +103,9 @@ temp[1-8]_max		Maximum temperature. From OT_WARN_LIMIT register.
 temp[1-8]_crit		Critical high temperature. From OT_FAULT_LIMIT register.
 temp[1-8]_max_alarm	Temperature high alarm.
 temp[1-8]_crit_alarm	Temperature critical high alarm.
 temp[1-8]_average	Historical average temperature (MAX34446 only).
 temp[1-8]_highest	Historical maximum temperature.
 temp[1-8]_reset_history	Write any value to reset history.
 			temp7 and temp8 attributes only exist for MAX34440.
 			MAX34446 only supports temp[1-3].
--- a/Documentation/hwmon/max8688
+++ b/Documentation/hwmon/max8688
@ -42,9 +42,9 @@ attributes are read-only.
 in1_label		"vout1"
 in1_input		Measured voltage. From READ_VOUT register.
-in1_min			Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in1_min			Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
 in1_max			Maximum voltage. From VOUT_OV_WARN_LIMIT register.
-in1_lcrit		Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in1_lcrit		Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
 in1_crit		Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
 in1_min_alarm		Voltage low alarm. From VOLTAGE_UV_WARNING status.
 in1_max_alarm		Voltage high alarm. From VOLTAGE_OV_WARNING status.
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@ -15,13 +15,20 @@ Supported chips:
 	http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF
 	http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF
  * Lineage Power
-    Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020'
+    Prefixes: 'mdt040', 'pdt003', 'pdt006', 'pdt012', 'udt020'
    Addresses scanned: -
    Datasheets:
 	http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf
 	http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf
 	http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf
 	http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf
 	http://www.lineagepower.com/oem/pdf/MDT040A0X.pdf
  * Texas Instruments TPS40400, TPS40422
    Prefixes: 'tps40400', 'tps40422'
    Addresses scanned: -
    Datasheets:
 	http://www.ti.com/lit/gpn/tps40400
 	http://www.ti.com/lit/gpn/tps40422
  * Generic PMBus devices
    Prefix: 'pmbus'
    Addresses scanned: -
--- a/Documentation/hwmon/sch5627
+++ b/Documentation/hwmon/sch5627
@ -16,6 +16,11 @@ Description
 SMSC SCH5627 Super I/O chips include complete hardware monitoring
 capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.
 The SMSC SCH5627 hardware monitoring part also contains an integrated
 watchdog. In order for this watchdog to function some motherboard specific
 initialization most be done by the BIOS, so if the watchdog is not enabled
 by the BIOS the sch5627 driver will not register a watchdog device.
 The hardware monitoring part of the SMSC SCH5627 is accessed by talking
 through an embedded microcontroller. An application note describing the
 protocol for communicating with the microcontroller is available upon
--- a/Documentation/hwmon/sch5636
+++ b/Documentation/hwmon/sch5636
@ -26,6 +26,9 @@ temperatures. Note that the driver detects how many fan headers /
 temperature sensors are actually implemented on the motherboard, so you will
 likely see fewer temperature and fan inputs.
 The Fujitsu Theseus hwmon solution also contains an integrated watchdog.
 This watchdog is fully supported by the sch5636 driver.
 An application note describing the Theseus' registers, as well as an
 application note describing the protocol for communicating with the
 microcontroller is available upon request. Please mail me if you want a copy.
--- a/Documentation/hwmon/ucd9000
+++ b/Documentation/hwmon/ucd9000
@ -70,9 +70,9 @@ 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]_min		Minimum 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]_lcrit		Critical minimum 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.
@ -82,7 +82,7 @@ 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
+curr[1-12]_lcrit	Critical minimum 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.
--- a/Documentation/hwmon/ucd9200
+++ b/Documentation/hwmon/ucd9200
@ -54,9 +54,9 @@ 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_min			Minimum 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_lcrit		Critical minimum 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.
@ -65,9 +65,9 @@ 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]_min		Minimum 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]_lcrit		Critical minimum 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.
@ -80,7 +80,7 @@ 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
+curr[2-5]_lcrit		Critical minimum 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.
--- a/Documentation/hwmon/zl6100
+++ b/Documentation/hwmon/zl6100
@ -34,6 +34,14 @@ Supported chips:
    Prefix: 'zl6105'
    Addresses scanned: -
    Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
  * Intersil / Zilker Labs ZL9101M
    Prefix: 'zl9101'
    Addresses scanned: -
    Datasheet: http://www.intersil.com/data/fn/fn7669.pdf
  * Intersil / Zilker Labs ZL9117M
    Prefix: 'zl9117'
    Addresses scanned: -
    Datasheet: http://www.intersil.com/data/fn/fn7914.pdf
  * Ericsson BMR450, BMR451
    Prefix: 'bmr450', 'bmr451'
    Addresses scanned: -
@ -106,7 +114,7 @@ in1_label		"vin"
 in1_input		Measured input voltage.
 in1_min			Minimum input voltage.
 in1_max			Maximum input voltage.
-in1_lcrit		Critical minumum input voltage.
+in1_lcrit		Critical minimum input voltage.
 in1_crit		Critical maximum input voltage.
 in1_min_alarm		Input voltage low alarm.
 in1_max_alarm		Input voltage high alarm.
@ -115,7 +123,7 @@ in1_crit_alarm		Input voltage critical high alarm.
 in2_label		"vout1"
 in2_input		Measured output voltage.
-in2_lcrit		Critical minumum output Voltage.
+in2_lcrit		Critical minimum output Voltage.
 in2_crit		Critical maximum output voltage.
 in2_lcrit_alarm		Critical output voltage critical low alarm.
 in2_crit_alarm		Critical output voltage critical high alarm.
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@ -87,11 +87,11 @@ it may have different addresses from one board to the next (manufacturer
 changing its design without notice). In this case, you can call
 i2c_new_probed_device() instead of i2c_new_device().
-Example (from the pnx4008 OHCI driver):
+Example (from the nxp OHCI driver):
 static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
-static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
+static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev)
 {
 	(...)
 	struct i2c_adapter *i2c_adap;
@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
 	(...)
 	i2c_adap = i2c_get_adapter(2);
 	memset(&i2c_info, 0, sizeof(struct i2c_board_info));
-	strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE);
+	strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE);
 	isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
 						   normal_i2c, NULL);
 	i2c_put_adapter(i2c_adap);
--- a/Documentation/i2o/ioctl
+++ b/Documentation/i2o/ioctl
@ -138,7 +138,7 @@ VI. Setting Parameters
   The return value is the size in bytes of the data written into
   ops->resbuf if no errors occur.  If an error occurs, -1 is returned
-   and errno is set appropriatly:
+   and errno is set appropriately:
      EFAULT      Invalid user space pointer was passed
      ENXIO       Invalid IOP number
@ -222,7 +222,7 @@ VIII. Downloading Software
   RETURNS
   This function returns 0 no errors occur. If an error occurs, -1
-   is returned and errno is set appropriatly:
+   is returned and errno is set appropriately:
      EFAULT      Invalid user space pointer was passed
      ENXIO       Invalid IOP number
@ -264,7 +264,7 @@ IX. Uploading Software
   RETURNS
   This function returns 0 if no errors occur.  If an error occurs, -1
-   is returned and errno is set appropriatly:
+   is returned and errno is set appropriately:
      EFAULT      Invalid user space pointer was passed
      ENXIO       Invalid IOP number
@ -301,7 +301,7 @@ X. Removing Software
   RETURNS
   This function returns 0 if no errors occur.  If an error occurs, -1
-   is returned and errno is set appropriatly:
+   is returned and errno is set appropriately:
      EFAULT      Invalid user space pointer was passed
      ENXIO       Invalid IOP number
@ -325,7 +325,7 @@ X. Validating Configuration
   RETURNS
   This function returns 0 if no erro occur.  If an error occurs, -1 is
-   returned and errno is set appropriatly:
+   returned and errno is set appropriately:
      ETIMEDOUT   Timeout waiting for reply message
      ENXIO       Invalid IOP number
@ -360,7 +360,7 @@ XI. Configuration Dialog
   RETURNS
   This function returns 0 if no error occur. If an error occurs, -1
-   is returned and errno is set appropriatly:
+   is returned and errno is set appropriately:
      EFAULT      Invalid user space pointer was passed
      ENXIO       Invalid IOP number
--- a/Documentation/ide/ChangeLog.ide-cd.1994-2004
+++ b/Documentation/ide/ChangeLog.ide-cd.1994-2004
@ -175,7 +175,7 @@
 *                         since the .pdf version doesn't seem to work...
 *                     -- Updated the TODO list to something more current.
 *
- * 4.15  Aug 25, 1998  -- Updated ide-cd.h to respect mechine endianess,
+ * 4.15  Aug 25, 1998  -- Updated ide-cd.h to respect machine endianness,
 *                         patch thanks to "Eddie C. Dost" <ecd@skynet.be>
 *
 * 4.50  Oct 19, 1998  -- New maintainers!
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@ -132,8 +132,8 @@ number of contacts (f1 and f0 in the table below).
 byte 5:    0    1    ?    ?    ?    ?   f1   f0
 This packet only appears after a position packet with the mt bit set, and
-ususally only appears when there are two or more contacts (although
+usually only appears when there are two or more contacts (although
-ocassionally it's seen with only a single contact).
+occassionally it's seen with only a single contact).
 The final v3 packet type is the trackstick packet.
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@ -330,7 +330,7 @@ the USB documentation for how to setup an USB mouse.
  The TM DirectConnect (BSP) protocol is supported by the tmdc.c
 module. This includes, but is not limited to:
-* ThrustMaster Millenium 3D Inceptor
+* ThrustMaster Millennium 3D Interceptor
 * ThrustMaster 3D Rage Pad
 * ThrustMaster Fusion Digital Game Pad
--- a/Documentation/ioctl/hdio.txt
+++ b/Documentation/ioctl/hdio.txt
@ -596,7 +596,7 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	     if CHS/LBA28
 	  The association between in_flags.all and each enable
-	  bitfield flips depending on endianess; fortunately, TASKFILE
+	  bitfield flips depending on endianness; fortunately, TASKFILE
 	  only uses inflags.b.data bit and ignores all other bits.
 	  The end result is that, on any endian machines, it has no
 	  effect other than modifying in_flags on completion.
@ -720,7 +720,7 @@ HDIO_DRIVE_TASKFILE		execute raw taskfile
 	  [6] Do not access {in|out}_flags->all except for resetting
 	  all the bits.  Always access individual bit fields.  ->all
-	  value will flip depending on endianess.  For the same
+	  value will flip depending on endianness.  For the same
 	  reason, do not use IDE_{TASKFILE|HOB}_STD_{OUT|IN}_FLAGS
 	  constants defined in hdreg.h.
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@ -189,7 +189,7 @@ Code  Seq#(hex)	Include File		Comments
 'Y'	all	linux/cyclades.h
 'Z'	14-15	drivers/message/fusion/mptctl.h
 '['	00-07	linux/usb/tmc.h		USB Test and Measurement Devices
-					<mailto:gregkh@suse.de>
+					<mailto:gregkh@linuxfoundation.org>
 'a'	all	linux/atm*.h, linux/sonet.h	ATM on linux
 					<http://lrcwww.epfl.ch/>
 'b'	00-FF				conflict! bit3 vme host bridge
@ -218,6 +218,7 @@ Code  Seq#(hex)	Include File		Comments
 'h'	00-7F				conflict! Charon filesystem
 					<mailto:zapman@interlan.net>
 'h'	00-1F	linux/hpet.h		conflict!
 'h'	80-8F	fs/hfsplus/ioctl.c
 'i'	00-3F	linux/i2o-dev.h		conflict!
 'i'	0B-1F	linux/ipmi.h		conflict!
 'i'	80-8F	linux/i8k.h
@ -255,7 +256,7 @@ Code  Seq#(hex)	Include File		Comments
 		linux/ixjuser.h		<http://web.archive.org/web/*/http://www.quicknet.net>
 'r'	00-1F	linux/msdos_fs.h and fs/fat/dir.c
 's'	all	linux/cdk.h
-'t'	00-7F	linux/if_ppp.h
+'t'	00-7F	linux/ppp-ioctl.h
 't'	80-8F	linux/isdn_ppp.h
 't'	90	linux/toshiba.h
 'u'	00-1F	linux/smb_fs.h		gone
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@ -117,7 +117,7 @@ applicable everywhere (see syntax).
  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
+  similar to a conditional "prompt" attribute for individual menu
  entries. Default value of "visible" is true.
 - numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@ -713,6 +713,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			The filter can be disabled or changed to another
 			driver later using sysfs.
 	drm_kms_helper.edid_firmware=[<connector>:]<file>
 			Broken monitors, graphic adapters and KVMs may
 			send no or incorrect EDID data sets. This parameter
 			allows to specify an EDID data set in the
 			/lib/firmware directory that is used instead.
 			Generic built-in EDID data sets are used, if one of
 			edid/1024x768.bin, edid/1280x1024.bin,
 			edid/1680x1050.bin, or edid/1920x1080.bin is given
 			and no file with the same name exists. Details and
 			instructions how to build your own EDID data are
 			available in Documentation/EDID/HOWTO.txt. An EDID
 			data set will only be used for a particular connector,
 			if its name and a colon are prepended to the EDID
 			name.
 	dscc4.setup=	[NET]
 	earlycon=	[KNL] Output early console device and options.
@ -950,7 +965,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			     controller
 	i8042.nopnp	[HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
 			     controllers
-	i8042.notimeout	[HW] Ignore timeout condition signalled by conroller
+	i8042.notimeout	[HW] Ignore timeout condition signalled by controller
 	i8042.reset	[HW] Reset the controller during init and cleanup
 	i8042.unlock	[HW] Unlock (ignore) the keylock
@ -1657,6 +1672,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			of returning the full 64-bit number.
 			The default is to return 64-bit inode numbers.
 	nfs.max_session_slots=
 			[NFSv4.1] Sets the maximum number of session slots
 			the client will attempt to negotiate with the server.
 			This limits the number of simultaneous RPC requests
 			that the client can send to the NFSv4.1 server.
 			Note that there is little point in setting this
 			value higher than the max_tcp_slot_table_limit.
 	nfs.nfs4_disable_idmapping=
 			[NFSv4] When set to the default of '1', this option
 			ensures that both the RPC level authentication
@ -1670,6 +1693,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			back to using the idmapper.
 			To turn off this behaviour, set the value to '0'.
 	nfs.send_implementation_id =
 			[NFSv4.1] Send client implementation identification
 			information in exchange_id requests.
 			If zero, no implementation identification information
 			will be sent.
 			The default is to send the implementation identification
 			information.
 	objlayoutdriver.osd_login_prog=
 			[NFS] [OBJLAYOUT] sets the pathname to the program which
 			is used to automatically discover and login into new
 			osd-targets. Please see:
 			Documentation/filesystems/pnfs.txt for more explanations
 	nmi_debug=	[KNL,AVR32,SH] Specify one or more actions to take
 			when a NMI is triggered.
 			Format: [state][,regs][,debounce][,die]
@ -2440,7 +2478,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			For more information see Documentation/vm/slub.txt.
 	slub_min_order=	[MM, SLUB]
-			Determines the mininum page order for slabs. Must be
+			Determines the minimum page order for slabs. Must be
 			lower than slub_max_order.
 			For more information see Documentation/vm/slub.txt.
@ -2606,7 +2644,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 	threadirqs	[KNL]
 			Force threading of all interrupt handlers except those
-			marked explicitely IRQF_NO_THREAD.
+			marked explicitly IRQF_NO_THREAD.
 	topology=	[S390]
 			Format: {off | on}
@ -2635,6 +2673,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			to facilitate early boot debugging.
 			See also Documentation/trace/events.txt
 	transparent_hugepage=
 			[KNL]
 			Format: [always|madvise|never]
 			Can be used to control the default behavior of the system
 			with respect to transparent hugepages.
 			See Documentation/vm/transhuge.txt for more details.
 	tsc=		Disable clocksource stability checks for TSC.
 			Format: <string>
 			[x86] reliable: mark tsc clocksource as reliable, this
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@ -354,7 +354,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는
    git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
  quilt trees:
-    - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@suse.de>
+    - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@linuxfoundation.org>
    kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
    - x86-64, partly i386, Andi Kleen < ak@suse.de>
        ftp.firstfloor.org:/pub/ak/x86_64/quilt/
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@ -1,6 +1,6 @@
 Everything you never wanted to know about kobjects, ksets, and ktypes
-Greg Kroah-Hartman <gregkh@suse.de>
+Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 Based on an original article by Jon Corbet for lwn.net written October 1,
 2003 and located at http://lwn.net/Articles/51437/
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@ -43,17 +43,23 @@ Format: 10x mA i.e 10 means 1.0 mA
 example platform data:
 Note: chan_nr can have values between 0 and 2.
 The name of each channel can be configurable.
 If the name field is not defined, the default name will be set to 'xxxx:channelN'
 (XXXX : pdata->label or i2c client name, N : channel number)
 static struct lp5521_led_config lp5521_led_config[] = {
        {
 		.name = "red",
                .chan_nr        = 0,
                .led_current    = 50,
 		.max_current    = 130,
        }, {
 		.name = "green",
                .chan_nr        = 1,
                .led_current    = 0,
 		.max_current    = 130,
        }, {
 		.name = "blue",
                .chan_nr        = 2,
                .led_current    = 0,
 		.max_current    = 130,
@ -86,3 +92,60 @@ static struct lp5521_platform_data lp5521_platform_data = {
 If the current is set to 0 in the platform data, that channel is
 disabled and it is not visible in the sysfs.
 The 'update_config' : CONFIG register (ADDR 08h)
 This value is platform-specific data.
 If update_config is not defined, the CONFIG register is set with
 'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'.
 (Enable auto-powersave, set charge pump to auto, red to battery)
 example of update_config :
 #define LP5521_CONFIGS	(LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
 			LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
 			LP5521_CLK_INT)
 static struct lp5521_platform_data lp5521_pdata = {
 	.led_config = lp5521_led_config,
 	.num_channels = ARRAY_SIZE(lp5521_led_config),
 	.clock_mode = LP5521_CLOCK_INT,
 	.update_config = LP5521_CONFIGS,
 };
 LED patterns : LP5521 has autonomous operation without external control.
 Pattern data can be defined in the platform data.
 example of led pattern data :
 /* RGB(50,5,0) 500ms on, 500ms off, infinite loop */
 static u8 pattern_red[] = {
 		0x40, 0x32, 0x60, 0x00,	0x40, 0x00, 0x60, 0x00,
 		};
 static u8 pattern_green[] = {
 		0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
 		};
 static struct lp5521_led_pattern board_led_patterns[] = {
 	{
 		.r = pattern_red,
 		.g = pattern_green,
 		.size_r = ARRAY_SIZE(pattern_red),
 		.size_g = ARRAY_SIZE(pattern_green),
 	},
 };
 static struct lp5521_platform_data lp5521_platform_data = {
        .led_config     = lp5521_led_config,
        .num_channels   = ARRAY_SIZE(lp5521_led_config),
        .clock_mode     = LP5521_CLOCK_EXT,
 	.patterns = board_led_patterns,
 	.num_patterns = ARRAY_SIZE(board_led_patterns),
 };
 Then predefined led pattern(s) can be executed via the sysfs.
 To start the pattern #1,
 # echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern
 (xxxx : i2c bus & slave address)
 To end the pattern,
 # echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern
--- a/Documentation/lockup-watchdogs.txt
+++ b/Documentation/lockup-watchdogs.txt
@ -0,0 +1,63 @@
 ===============================================================
 Softlockup detector and hardlockup detector (aka nmi_watchdog)
 ===============================================================
 The Linux kernel can act as a watchdog to detect both soft and hard
 lockups.
 A 'softlockup' is defined as a bug that causes the kernel to loop in
 kernel mode for more than 20 seconds (see "Implementation" below for
 details), without giving other tasks a chance to run. The current
 stack trace is displayed upon detection and, by default, the system
 will stay locked up. Alternatively, the kernel can be configured to
 panic; a sysctl, "kernel.softlockup_panic", a kernel parameter,
 "softlockup_panic" (see "Documentation/kernel-parameters.txt" for
 details), and a compile option, "BOOTPARAM_HARDLOCKUP_PANIC", are
 provided for this.
 A 'hardlockup' is defined as a bug that causes the CPU to loop in
 kernel mode for more than 10 seconds (see "Implementation" below for
 details), without letting other interrupts have a chance to run.
 Similarly to the softlockup case, the current stack trace is displayed
 upon detection and the system will stay locked up unless the default
 behavior is changed, which can be done through a compile time knob,
 "BOOTPARAM_HARDLOCKUP_PANIC", and a kernel parameter, "nmi_watchdog"
 (see "Documentation/kernel-parameters.txt" for details).
 The panic option can be used in combination with panic_timeout (this
 timeout is set through the confusingly named "kernel.panic" sysctl),
 to cause the system to reboot automatically after a specified amount
 of time.
 === Implementation ===
 The soft and hard lockup detectors are built on top of the hrtimer and
 perf subsystems, respectively. A direct consequence of this is that,
 in principle, they should work in any architecture where these
 subsystems are present.
 A periodic hrtimer runs to generate interrupts and kick the watchdog
 task. An NMI perf event is generated every "watchdog_thresh"
 (compile-time initialized to 10 and configurable through sysctl of the
 same name) seconds to check for hardlockups. If any CPU in the system
 does not receive any hrtimer interrupt during that time the
 'hardlockup detector' (the handler for the NMI perf event) will
 generate a kernel warning or call panic, depending on the
 configuration.
 The watchdog task is a high priority kernel thread that updates a
 timestamp every time it is scheduled. If that timestamp is not updated
 for 2*watchdog_thresh seconds (the softlockup threshold) the
 'softlockup detector' (coded inside the hrtimer callback function)
 will dump useful debug information to the system log, after which it
 will call panic if it was instructed to do so or resume execution of
 other kernel code.
 The period of the hrtimer is 2*watchdog_thresh/5, which means it has
 two or three chances to generate an interrupt before the hardlockup
 detector kicks in.
 As explained above, a kernel knob is provided that allows
 administrators to configure the period of the hrtimer and the perf
 event. The right value for a particular environment is a trade-off
 between fast response to lockups and detection overhead.
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@ -89,7 +89,7 @@ TTY_DRIVER_MAGIC      0x5402      tty_driver        include/linux/tty_driver.h
 MGSLPC_MAGIC          0x5402      mgslpc_info       drivers/char/pcmcia/synclink_cs.c
 TTY_LDISC_MAGIC       0x5403      tty_ldisc         include/linux/tty_ldisc.h
 USB_SERIAL_MAGIC      0x6702      usb_serial        drivers/usb/serial/usb-serial.h
-FULL_DUPLEX_MAGIC     0x6969                        drivers/net/tulip/de2104x.c
+FULL_DUPLEX_MAGIC     0x6969                        drivers/net/ethernet/dec/tulip/de2104x.c
 USB_BLUETOOTH_MAGIC   0x6d02      usb_bluetooth     drivers/usb/class/bluetty.c
 RFCOMM_TTY_MAGIC      0x6d02                        net/bluetooth/rfcomm/tty.c
 USB_SERIAL_PORT_MAGIC 0x7301      usb_serial_port   drivers/usb/serial/usb-serial.h
--- a/Show More
+++ b/Show More