27 files changed, 473 insertions, 101 deletions
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
new file mode 100644
index 000000000000..bcd907b4141f
--- /dev/null
+++ b/Documentation/.gitignore
@@ -0,0 +1,7 @@
+filesystems/dnotify_test
+laptops/dslm
+timers/hpet_example
+vm/hugepage-mmap
+vm/hugepage-shm
+vm/map_hugetlb
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7583dc7cf64d..910c923a9b86 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -389,7 +389,7 @@
      </para>
      <para>
        If your driver supports memory management (it should!), you'll
-        need to set that up at load time as well.  How you intialize
+        need to set that up at load time as well.  How you initialize
        it depends on which memory manager you're using, TTM or GEM.
      </para>
      <sect3>
@@ -399,7 +399,7 @@
          aperture space for graphics devices. TTM supports both UMA devices
          and devices with dedicated video RAM (VRAM), i.e. most discrete
          graphics devices.  If your device has dedicated RAM, supporting
-          TTM is desireable.  TTM also integrates tightly with your
+          TTM is desirable.  TTM also integrates tightly with your
          driver specific buffer execution function.  See the radeon
          driver for examples.
        </para>
@@ -443,7 +443,7 @@
          likely eventually calling ttm_bo_global_init and
          ttm_bo_global_release, respectively.  Also like the previous
          object, ttm_global_item_ref is used to create an initial reference
-          count for the TTM, which will call your initalization function.
+          count for the TTM, which will call your initialization function.
        </para>
      </sect3>
      <sect3>
@@ -557,7 +557,7 @@ void intel_crt_init(struct drm_device *dev)
          CRT connector and encoder combination is created.  A device
          specific i2c bus is also created, for fetching EDID data and
          performing monitor detection.  Once the process is complete,
-          the new connector is regsitered with sysfs, to make its
+          the new connector is registered with sysfs, to make its
          properties available to applications.
        </para>
        <sect4>
@@ -581,12 +581,12 @@ void intel_crt_init(struct drm_device *dev)
        <para>
          For each encoder, CRTC and connector, several functions must
          be provided, depending on the object type.  Encoder objects
-          need should provide a DPMS (basically on/off) function, mode fixup
+          need to provide a DPMS (basically on/off) function, mode fixup
          (for converting requested modes into native hardware timings),
          and prepare, set and commit functions for use by the core DRM
          helper functions.  Connector helpers need to provide mode fetch and
          validity functions as well as an encoder matching function for
-          returing an ideal encoder for a given connector.  The core
+          returning an ideal encoder for a given connector.  The core
          connector functions include a DPMS callback, (deprecated)
          save/restore routines, detection, mode probing, property handling,
          and cleanup functions.
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml
index 9737243377a3..7c3c098d5d08 100644
--- a/Documentation/DocBook/v4l/v4l2.xml
+++ b/Documentation/DocBook/v4l/v4l2.xml
@@ -58,7 +58,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
 </contrib>
        <affiliation>
          <address>
-            <email>awalls@radix.net</email>
+            <email>awalls@md.metrocast.net</email>
          </address>
        </affiliation>
      </author>
diff --git a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
index 87e4f0f6151c..402229ee06f6 100644
--- a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
+++ b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
@@ -53,8 +53,10 @@ input</refpurpose>
 automatically, similar to sensing the video standard. To do so, applications
 call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
 &v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
-returned in the preset field of &v4l2-dv-preset;. When detection is not
+returned in the preset field of &v4l2-dv-preset;. If the preset could not be
-possible or fails, the value V4L2_DV_INVALID is returned.</para>
+detected because there was no signal, or the signal was unreliable, or the
+signal did not map to a supported preset, then the value V4L2_DV_INVALID is
+returned.</para>
  </refsect1>
  <refsect1>
diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt
new file mode 100644
index 000000000000..dfab71848dc8
--- /dev/null
+++ b/Documentation/acpi/apei/einj.txt
@@ -0,0 +1,59 @@
+                        APEI Error INJection
+                        ~~~~~~~~~~~~~~~~~~~~
+EINJ provides a hardware error injection mechanism
+It is very useful for debugging and testing of other APEI and RAS features.
+To use EINJ, make sure the following are enabled in your kernel
+configuration:
+CONFIG_DEBUG_FS
+CONFIG_ACPI_APEI
+CONFIG_ACPI_APEI_EINJ
+The user interface of EINJ is debug file system, under the
+directory apei/einj. The following files are provided.
+- available_error_type
+  Reading this file returns the error injection capability of the
+  platform, that is, which error types are supported. The error type
+  definition is as follow, the left field is the error type value, the
+  right field is error description.
+    0x00000001  Processor Correctable
+    0x00000002  Processor Uncorrectable non-fatal
+    0x00000004  Processor Uncorrectable fatal
+    0x00000008  Memory Correctable
+    0x00000010  Memory Uncorrectable non-fatal
+    0x00000020  Memory Uncorrectable fatal
+    0x00000040  PCI Express Correctable
+    0x00000080  PCI Express Uncorrectable fatal
+    0x00000100  PCI Express Uncorrectable non-fatal
+    0x00000200  Platform Correctable
+    0x00000400  Platform Uncorrectable non-fatal
+    0x00000800  Platform Uncorrectable fatal
+  The format of file contents are as above, except there are only the
+  available error type lines.
+- error_type
+  This file is used to set the error type value. The error type value
+  is defined in "available_error_type" description.
+- error_inject
+  Write any integer to this file to trigger the error
+  injection. Before this, please specify all necessary error
+  parameters.
+- param1
+  This file is used to set the first error parameter value. Effect of
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address.
+- param2
+  This file is used to set the second error parameter value. Effect of
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address mask.
+For more information about EINJ, please refer to ACPI specification
+version 4.0, section 17.5.
diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
index 2af2cf39915f..816d6071669e 100644
--- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt
+++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
@@ -12,6 +12,8 @@ Introduction
  of the s3c2410 GPIO system, please read the Samsung provided
  data-sheet/users manual to find out the complete list.
+  See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
 GPIOLIB
 -------
@@ -24,8 +26,60 @@ GPIOLIB
  listed below will be removed (they may be marked as __deprecated
  in the near future).
-  - s3c2410_gpio_getpin
+  The following functions now either have a s3c_ specific variant
-  - s3c2410_gpio_setpin
+  or are merged into gpiolib. See the definitions in
+  arch/arm/plat-samsung/include/plat/gpio-cfg.h:
+  s3c2410_gpio_setpin()         gpio_set_value() or gpio_direction_output()
+  s3c2410_gpio_getpin()         gpio_get_value() or gpio_direction_input()
+  s3c2410_gpio_getirq()         gpio_to_irq()
+  s3c2410_gpio_cfgpin()         s3c_gpio_cfgpin()
+  s3c2410_gpio_getcfg()         s3c_gpio_getcfg()
+  s3c2410_gpio_pullup()         s3c_gpio_setpull()
+GPIOLIB conversion
+------------------
+If you need to convert your board or driver to use gpiolib from the exiting
+s3c2410 api, then here are some notes on the process.
+1) If your board is exclusively using an GPIO, say to control peripheral
+   power, then it will require to claim the gpio with gpio_request() before
+   it can use it.
+   It is recommended to check the return value, with at least WARN_ON()
+   during initialisation.
+2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
+   as they have the same arguments, and can either take the pin specific
+   values, or the more generic special-function-number arguments.
+3) s3c2410_gpio_pullup() changs have the problem that whilst the 
+   s3c2410_gpio_pullup(x, 1) can be easily translated to the
+   s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
+   are not so easy.
+   The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
+   of some of the devices, a pull-down) and as such the new API distinguishes
+   between the UP and DOWN case. There is currently no 'just turn on' setting
+   which may be required if this becomes a problem.
+4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
+   does not implicitly configure the relevant gpio to output. The gpio
+   direction should be changed before using gpio_set_value().
+5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
+   has been set to input. It is currently unknown what the behaviour is
+   when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
+   would return the value the pin is supposed to be outputting).
+6) s3c2410_gpio_getirq() should be directly replacable with the
+   gpio_to_irq() call.
+The s3c2410_gpio and gpio_ calls have always operated on the same gpio
+numberspace, so there is no problem with converting the gpio numbering
+between the calls.
 Headers
@@ -54,6 +108,11 @@ PIN Numbers
  eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
  the GPIO functions which pin is to be used.
+  With the conversion to gpiolib, there is no longer a direct conversion
+  from gpio pin number to register base address as in earlier kernels. This
+  is due to the number space required for newer SoCs where the later
+  GPIOs are not contiguous.
 Configuring a pin
 -----------------
@@ -71,6 +130,8 @@ Configuring a pin
   which would turn GPA(0) into the lowest Address line A0, and set
   GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
+   The s3c_gpio_cfgpin() call is a functional replacement for this call.
 Reading the current configuration
 ---------------------------------
@@ -82,6 +143,9 @@ Reading the current configuration
  The return value will be from the same set of values which can be
  passed to s3c2410_gpio_cfgpin().
+  The s3c_gpio_getcfg() call should be a functional replacement for
+  this call.
 Configuring a pull-up resistor
 ------------------------------
@@ -95,6 +159,10 @@ Configuring a pull-up resistor
  Where the to value is zero to set the pull-up off, and 1 to enable
  the specified pull-up. Any other values are currently undefined.
+  The s3c_gpio_setpull() offers similar functionality, but with the
+  ability to encode whether the pull is up or down. Currently there
+  is no 'just on' state, so up or down must be selected.
 Getting the state of a PIN
 --------------------------
@@ -106,6 +174,9 @@ Getting the state of a PIN
  This will return either zero or non-zero. Do not count on this
  function returning 1 if the pin is set.
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
 Setting the state of a PIN
 --------------------------
@@ -117,6 +188,9 @@ Setting the state of a PIN
  Which sets the given pin to the value. Use 0 to write 0, and 1 to
  set the output to 1.
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
 Getting the IRQ number associated with a PIN
 --------------------------------------------
@@ -128,6 +202,9 @@ Getting the IRQ number associated with a PIN
  Note, not all pins have an IRQ.
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
 Authour
 -------
diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt
index 081892df4fda..c12bfc1a00c9 100644
--- a/Documentation/arm/Samsung-S3C24XX/Overview.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt
@@ -8,10 +8,16 @@ Introduction
  The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
  by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
+  S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices
+  are supported.
  Support for the S3C2400 and S3C24A0 series are in progress.
+  The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
+  included under the arch/arm/mach-s3c2416 directory. Note, whilst core
+  support for these SoCs is in, work on some of the extra peripherals
+  and extra interrupts is still ongoing.
 Configuration
 -------------
@@ -209,6 +215,13 @@ GPIO
  Newer kernels carry GPIOLIB, and support is being moved towards
  this with some of the older support in line to be removed.
+  As of v2.6.34, the move towards using gpiolib support is almost
+  complete, and very little of the old calls are left.
+  See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
+  support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
+  implementation.
 Clock Management
 ----------------
diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt
new file mode 100644
index 000000000000..05850c62abeb
--- /dev/null
+++ b/Documentation/arm/Samsung/GPIO.txt
@@ -0,0 +1,42 @@
+                Samsung GPIO implementation
+                ===========================
+Introduction
+------------
+This outlines the Samsung GPIO implementation and the architecture
+specfic calls provided alongisde the drivers/gpio core.
+S3C24XX (Legacy)
+----------------
+See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
+about these devices. Their implementation is being brought into line
+with the core samsung implementation described in this document.
+GPIOLIB integration
+-------------------
+The gpio implementation uses gpiolib as much as possible, only providing
+specific calls for the items that require Samsung specific handling, such
+as pin special-function or pull resistor control.
+GPIO numbering is synchronised between the Samsung and gpiolib system.
+PIN configuration
+-----------------
+Pin configuration is specific to the Samsung architecutre, with each SoC
+registering the necessary information for the core gpio configuration
+implementation to configure pins as necessary.
+The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
+driver or machine to change gpio configuration.
+See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
+on these functions.
diff --git a/Documentation/arm/Samsung/Overview.txt b/Documentation/arm/Samsung/Overview.txt
index 7cced1fea9c3..c3094ea51aa7 100644
--- a/Documentation/arm/Samsung/Overview.txt
+++ b/Documentation/arm/Samsung/Overview.txt
@@ -13,9 +13,10 @@ Introduction
  - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
  - S3C64XX: S3C6400 and S3C6410
-  - S5PC6440
+  - S5P6440
+  - S5P6442
-  S5PC100 and S5PC110 support is currently being merged
+  - S5PC100
+  - S5PC110 / S5PV210
 S3C24XX Systems
@@ -35,7 +36,10 @@ Configuration
  unifying all the SoCs into one kernel.
  s5p6440_defconfig - S5P6440 specific default configuration
+  s5p6442_defconfig - S5P6442 specific default configuration
  s5pc100_defconfig - S5PC100 specific default configuration
+  s5pc110_defconfig - S5PC110 specific default configuration
+  s5pv210_defconfig - S5PV210 specific default configuration
 Layout
@@ -50,18 +54,27 @@ Layout
  specific information. It contains the base clock, GPIO and device definitions
  to get the system running.
-  plat-s3c is the s3c24xx/s3c64xx platform directory, although it is currently
-  involved in other builds this will be phased out once the relevant code is
-  moved elsewhere.
  plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs.
-  plat-s3c64xx is for the s3c64xx specific bits, see the S3C24XX docs.
+  plat-s5p is for s5p specific builds, and contains common support for the
+  S5P specific systems. Not all S5Ps use all the features in this directory
+  due to differences in the hardware.
+Layout changes
+--------------
+  The old plat-s3c and plat-s5pc1xx directories have been removed, with
+  support moved to either plat-samsung or plat-s5p as necessary. These moves
+  where to simplify the include and dependency issues involved with having
+  so many different platform directories.
-  plat-s5p is for s5p specific builds, more to be added.
+  It was decided to remove plat-s5pc1xx as some of the support was already
+  in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
+  the only user was the S5PC100. The S5PC100 specific items where moved to
+  arch/arm/mach-s5pc100.
-  [ to finish ]
 Port Contributors
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index 79c533223762..0b875e8da969 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -6,6 +6,8 @@ Written by Doug Thompson <dougthompson@xmission.com>
 7 Dec 2005
 17 Jul 2007     Updated
+(c) Mauro Carvalho Chehab <mchehab@redhat.com>
+05 Aug 2009     Nehalem interface
 EDAC is maintained and written by:
@@ -717,3 +719,153 @@ unique drivers for their hardware systems.
 The 'test_device_edac' sample driver is located at the
 bluesmoke.sourceforge.net project site for EDAC.
+=======================================================================
+NEHALEM USAGE OF EDAC APIs
+This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
+Nehalem EDAC driver. They will likely be changed on future versions
+of the driver.
+Due to the way Nehalem exports Memory Controller data, some adjustments
+were done at i7core_edac driver. This chapter will cover those differences
+1) On Nehalem, there are one Memory Controller per Quick Patch Interconnect
+   (QPI). At the driver, the term "socket" means one QPI. This is
+   associated with a physical CPU socket.
+   Each MC have 3 physical read channels, 3 physical write channels and
+   3 logic channels. The driver currenty sees it as just 3 channels.
+   Each channel can have up to 3 DIMMs.
+   The minimum known unity is DIMMs. There are no information about csrows.
+   As EDAC API maps the minimum unity is csrows, the driver sequencially
+   maps channel/dimm into different csrows.
+   For example, suposing the following layout:
+        Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
+          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+          dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
+        Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
+          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+        Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
+          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
+   The driver will map it as:
+        csrow0: channel 0, dimm0
+        csrow1: channel 0, dimm1
+        csrow2: channel 1, dimm0
+        csrow3: channel 2, dimm0
+exports one
+   DIMM per csrow.
+   Each QPI is exported as a different memory controller.
+2) Nehalem MC has the hability to generate errors. The driver implements this
+   functionality via some error injection nodes:
+   For injecting a memory error, there are some sysfs nodes, under
+   /sys/devices/system/edac/mc/mc?/:
+   inject_addrmatch/*:
+      Controls the error injection mask register. It is possible to specify
+      several characteristics of the address to match an error code:
+         dimm = the affected dimm. Numbers are relative to a channel;
+         rank = the memory rank;
+         channel = the channel that will generate an error;
+         bank = the affected bank;
+         page = the page address;
+         column (or col) = the address column.
+      each of the above values can be set to "any" to match any valid value.
+      At driver init, all values are set to any.
+      For example, to generate an error at rank 1 of dimm 2, for any channel,
+      any bank, any page, any column:
+                echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+                echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+        To return to the default behaviour of matching any, you can do:
+                echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
+                echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
+   inject_eccmask:
+       specifies what bits will have troubles,
+   inject_section:
+       specifies what ECC cache section will get the error:
+                3 for both
+                2 for the highest
+                1 for the lowest
+   inject_type:
+       specifies the type of error, being a combination of the following bits:
+                bit 0 - repeat
+                bit 1 - ecc
+                bit 2 - parity
+       inject_enable starts the error generation when something different
+       than 0 is written.
+   All inject vars can be read. root permission is needed for write.
+   Datasheet states that the error will only be generated after a write on an
+   address that matches inject_addrmatch. It seems, however, that reading will
+   also produce an error.
+   For example, the following code will generate an error for any write access
+   at socket 0, on any DIMM/address on channel 2:
+   echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
+   echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
+   echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
+   echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
+   echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
+   dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
+   For socket 1, it is needed to replace "mc0" by "mc1" at the above
+   commands.
+   The generated error message will look like:
+   EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
+3) Nehalem specific Corrected Error memory counters
+   Nehalem have some registers to count memory errors. The driver uses those
+   registers to report Corrected Errors on devices with Registered Dimms.
+   However, those counters don't work with Unregistered Dimms. As the chipset
+   offers some counters that also work with UDIMMS (but with a worse level of
+   granularity than the default ones), the driver exposes those registers for
+   UDIMM memories.
+   They can be read by looking at the contents of all_channel_counts/
+   $ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
+        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
+        0
+        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
+        0
+        /sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
+        0
+   What happens here is that errors on different csrows, but at the same
+   dimm number will increment the same counter.
+   So, in this memory mapping:
+        csrow0: channel 0, dimm0
+        csrow1: channel 0, dimm1
+        csrow2: channel 1, dimm0
+        csrow3: channel 2, dimm0
+   The hardware will increment udimm0 for an error at the first dimm at either
+        csrow0, csrow2  or csrow3;
+   The hardware will increment udimm1 for an error at the second dimm at either
+        csrow0, csrow2  or csrow3;
+   The hardware will increment udimm2 for an error at the third dimm at either
+        csrow0, csrow2  or csrow3;
+4) Standard error counters
+   The standard error counters are generated when an mcelog error is received
+   by the driver. Since, with udimm, this is counted by software, it is
+   possible that some errors could be lost. With rdimm's, they displays the
+   contents of the registers
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 672be0109d02..c268783bc4e7 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -578,15 +578,6 @@ Who:	Avi Kivity <avi@redhat.com>
 ----------------------------
-What:   "acpi=ht" boot option
-When:   2.6.35
-Why:    Useful in 2003, implementation is a hack.
-        Generally invoked by accident today.
-        Seen as doing more harm than good.
-Who:    Len Brown <len.brown@intel.com>
----------------------------
 What:   iwlwifi 50XX module parameters
 When:   2.6.40
 Why:    The "..50" modules parameters were used to configure 5000 series and
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 61c98f03baa1..96d4293607ec 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -380,7 +380,7 @@ prototypes:
        int (*open) (struct inode *, struct file *);
        int (*flush) (struct file *);
        int (*release) (struct inode *, struct file *);
-        int (*fsync) (struct file *, struct dentry *, int datasync);
+        int (*fsync) (struct file *, int datasync);
        int (*aio_fsync) (struct kiocb *, int datasync);
        int (*fasync) (int, struct file *, int);
        int (*lock) (struct file *, int, struct file_lock *);
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index b66858538df5..94677e7dcb13 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -401,11 +401,16 @@ otherwise noted.
        started might not be in the page cache at the end of the
        walk).
-  truncate: called by the VFS to change the size of a file.  The
+  truncate: Deprecated. This will not be called if ->setsize is defined.
+        Called by the VFS to change the size of a file.  The
        i_size field of the inode is set to the desired size by the
        VFS before this method is called.  This method is called by
        the truncate(2) system call and related functionality.
+        Note: ->truncate and vmtruncate are deprecated. Do not add new
+        instances/calls of these. Filesystems should be converted to do their
+        truncate sequence via ->setattr().
  permission: called by the VFS to check for access rights on a POSIX-like
        filesystem.
@@ -729,7 +734,7 @@ struct file_operations {
        int (*open) (struct inode *, struct file *);
        int (*flush) (struct file *);
        int (*release) (struct inode *, struct file *);
-        int (*fsync) (struct file *, struct dentry *, int datasync);
+        int (*fsync) (struct file *, int datasync);
        int (*aio_fsync) (struct kiocb *, int datasync);
        int (*fasync) (int, struct file *, int);
        int (*lock) (struct file *, int, struct file_lock *);
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt
index d8119e9d2d60..96d0df28bed3 100644
--- a/Documentation/filesystems/xfs-delayed-logging-design.txt
+++ b/Documentation/filesystems/xfs-delayed-logging-design.txt
@@ -794,11 +794,6 @@ designed.
 Roadmap:
-2.6.35 Inclusion in mainline as an experimental mount option
-        => approximately 2-3 months to merge window
-        => needs to be in xfs-dev tree in 4-6 weeks
-        => code is nearing readiness for review
 2.6.37 Remove experimental tag from mount option
        => should be roughly 6 months after initial merge
        => enough time to:
diff --git a/Documentation/i2c/busses/i2c-ali1535 b/Documentation/i2c/busses/i2c-ali1535
index 0db3b4c74ad1..acbc65a08097 100644
--- a/Documentation/i2c/busses/i2c-ali1535
+++ b/Documentation/i2c/busses/i2c-ali1535
@@ -6,12 +6,12 @@ Supported adapters:
        http://www.ali.com.tw/eng/support/datasheet_request.php
 Authors:
-        Frodo Looijaard <frodol@dds.nl>, 
+        Frodo Looijaard <frodol@dds.nl>,
        Philip Edelbrock <phil@netroedge.com>,
        Mark D. Studebaker <mdsxyz123@yahoo.com>,
        Dan Eaton <dan.eaton@rocketlogix.com>,
        Stephen Rousset<stephen.rousset@rocketlogix.com>
-                                                                                                
 Description
 -----------
diff --git a/Documentation/i2c/busses/i2c-ali1563 b/Documentation/i2c/busses/i2c-ali1563
index 99ad4b9bcc32..54691698d2dd 100644
--- a/Documentation/i2c/busses/i2c-ali1563
+++ b/Documentation/i2c/busses/i2c-ali1563
@@ -18,7 +18,7 @@ For an overview of these chips see http://www.acerlabs.com
 The M1563 southbridge is deceptively similar to the M1533, with a few
 notable exceptions. One of those happens to be the fact they upgraded the
 i2c core to be SMBus 2.0 compliant, and happens to be almost identical to
-the i2c controller found in the Intel 801 south bridges. 
+the i2c controller found in the Intel 801 south bridges.
 Features
 --------
diff --git a/Documentation/i2c/busses/i2c-ali15x3 b/Documentation/i2c/busses/i2c-ali15x3
index ff28d381bebe..600da90b8f12 100644
--- a/Documentation/i2c/busses/i2c-ali15x3
+++ b/Documentation/i2c/busses/i2c-ali15x3
@@ -6,8 +6,8 @@ Supported adapters:
        http://www.ali.com.tw/eng/support/datasheet_request.php
 Authors:
-        Frodo Looijaard <frodol@dds.nl>, 
+        Frodo Looijaard <frodol@dds.nl>,
-        Philip Edelbrock <phil@netroedge.com>, 
+        Philip Edelbrock <phil@netroedge.com>,
        Mark D. Studebaker <mdsxyz123@yahoo.com>
 Module Parameters
@@ -40,10 +40,10 @@ M1541 and M1543C South Bridges.
 The M1543C is a South bridge for desktop systems.
 The M1541 is a South bridge for portable systems.
 They are part of the following ALI chipsets:
-   
- * "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and 
+ * "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
                100MHz CPU Front Side bus
- * "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz 
+ * "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
                CPU Front Side bus
   Some Aladdin V motherboards:
        Asus P5A
@@ -77,7 +77,7 @@ output of lspci will show something similar to the following:
 ** then run lspci.
 ** If you see the 1533 and 5229 devices but NOT the 7101 device,
 ** then you must enable ACPI, the PMU, SMB, or something similar
-** in the BIOS. 
+** in the BIOS.
 ** The driver won't work if it can't find the M7101 device.
 The SMB controller is part of the M7101 device, which is an ACPI-compliant
@@ -87,8 +87,8 @@ The whole M7101 device has to be enabled for the SMB to work. You can't
 just enable the SMB alone. The SMB and the ACPI have separate I/O spaces.
 We make sure that the SMB is enabled. We leave the ACPI alone.
-Features 
+Features
-------- 
+--------
 This driver controls the SMB Host only. The SMB Slave
 controller on the M15X3 is not enabled. This driver does not use
diff --git a/Documentation/i2c/busses/i2c-pca-isa b/Documentation/i2c/busses/i2c-pca-isa
index 6fc8f4c27c3c..b044e5265488 100644
--- a/Documentation/i2c/busses/i2c-pca-isa
+++ b/Documentation/i2c/busses/i2c-pca-isa
@@ -1,10 +1,10 @@
 Kernel driver i2c-pca-isa
 Supported adapters:
-This driver supports ISA boards using the Philips PCA 9564 
+This driver supports ISA boards using the Philips PCA 9564
-Parallel bus to I2C bus controller 
+Parallel bus to I2C bus controller
-Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems 
+Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems
 Module Parameters
 -----------------
@@ -12,12 +12,12 @@ Module Parameters
 * base int
 I/O base address
 * irq int
- IRQ interrupt 
+ IRQ interrupt
-* clock int 
+* clock int
 Clock rate as described in table 1 of PCA9564 datasheet
 Description
 -----------
-This driver supports ISA boards using the Philips PCA 9564 
+This driver supports ISA boards using the Philips PCA 9564
-Parallel bus to I2C bus controller 
+Parallel bus to I2C bus controller
diff --git a/Documentation/i2c/busses/i2c-sis5595 b/Documentation/i2c/busses/i2c-sis5595
index cc47db7d00a9..ecd21fb49a8f 100644
--- a/Documentation/i2c/busses/i2c-sis5595
+++ b/Documentation/i2c/busses/i2c-sis5595
@@ -1,41 +1,41 @@
 Kernel driver i2c-sis5595
-Authors: 
+Authors:
        Frodo Looijaard <frodol@dds.nl>,
        Mark D. Studebaker <mdsxyz123@yahoo.com>,
-        Philip Edelbrock <phil@netroedge.com> 
+        Philip Edelbrock <phil@netroedge.com>
 Supported adapters:
  * Silicon Integrated Systems Corp. SiS5595 Southbridge
    Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
-Note: all have mfr. ID 0x1039. 
+Note: all have mfr. ID 0x1039.
-   SUPPORTED            PCI ID           
+   SUPPORTED            PCI ID
-        5595            0008 
+        5595            0008
- 
-   Note: these chips contain a 0008 device which is incompatible with the 
+   Note: these chips contain a 0008 device which is incompatible with the
-         5595. We recognize these by the presence of the listed 
+         5595. We recognize these by the presence of the listed
-         "blacklist" PCI ID and refuse to load. 
+         "blacklist" PCI ID and refuse to load.
- 
-   NOT SUPPORTED        PCI ID          BLACKLIST PCI ID         
+   NOT SUPPORTED        PCI ID          BLACKLIST PCI ID
-         540            0008            0540 
+         540            0008            0540
-         550            0008            0550 
+         550            0008            0550
-        5513            0008            5511 
+        5513            0008            5511
-        5581            0008            5597 
+        5581            0008            5597
-        5582            0008            5597 
+        5582            0008            5597
-        5597            0008            5597 
+        5597            0008            5597
-        5598            0008            5597/5598 
+        5598            0008            5597/5598
-         630            0008            0630 
+         630            0008            0630
-         645            0008            0645 
+         645            0008            0645
-         646            0008            0646 
+         646            0008            0646
-         648            0008            0648 
+         648            0008            0648
-         650            0008            0650 
+         650            0008            0650
-         651            0008            0651 
+         651            0008            0651
-         730            0008            0730 
+         730            0008            0730
-         735            0008            0735 
+         735            0008            0735
-         745            0008            0745 
+         745            0008            0745
-         746            0008            0746 
+         746            0008            0746
 Module Parameters
 -----------------
diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630
index 9aca6889f748..629ea2c356fd 100644
--- a/Documentation/i2c/busses/i2c-sis630
+++ b/Documentation/i2c/busses/i2c-sis630
@@ -14,9 +14,9 @@ Module Parameters
 * force = [1|0] Forcibly enable the SIS630. DANGEROUS!
                This can be interesting for chipsets not named
                above to check if it works for you chipset, but DANGEROUS!
-                
-* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default, 
+* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
-                        what your BIOS use). DANGEROUS! This should be a bit 
+                        what your BIOS use). DANGEROUS! This should be a bit
                        faster, but freeze some systems (i.e. my Laptop).
@@ -44,6 +44,6 @@ Philip Edelbrock <phil@netroedge.com>
 - testing SiS730 support
 Mark M. Hoffman <mhoffman@lightlink.com>
 - bug fixes
- 
 To anyone else which I forgot here ;), thanks!
diff --git a/Documentation/i2c/ten-bit-addresses b/Documentation/i2c/ten-bit-addresses
index 200074f81360..e9890709c508 100644
--- a/Documentation/i2c/ten-bit-addresses
+++ b/Documentation/i2c/ten-bit-addresses
@@ -1,17 +1,17 @@
-The I2C protocol knows about two kinds of device addresses: normal 7 bit 
+The I2C protocol knows about two kinds of device addresses: normal 7 bit
 addresses, and an extended set of 10 bit addresses. The sets of addresses
 do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
 address 0x10 (though a single device could respond to both of them). You
 select a 10 bit address by adding an extra byte after the address
 byte:
-  S Addr7 Rd/Wr ....  
+  S Addr7 Rd/Wr ....
 becomes
  S 11110 Addr10 Rd/Wr
 S is the start bit, Rd/Wr the read/write bit, and if you count the number
 of bits, you will see the there are 8 after the S bit for 7 bit addresses,
 and 16 after the S bit for 10 bit addresses.
-WARNING! The current 10 bit address support is EXPERIMENTAL. There are 
+WARNING! The current 10 bit address support is EXPERIMENTAL. There are
 several places in the code that will cause SEVERE PROBLEMS with 10 bit
 addresses, even though there is some basic handling and hooks. Also,
 almost no supported adapter handles the 10 bit addresses correctly.
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 6f8c1cabbc5d..634c625da8ce 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -65,7 +65,7 @@ CROSS_COMPILE
 Specify an optional fixed part of the binutils filename.
 CROSS_COMPILE can be a part of the filename or the full path.
-CROSS_COMPILE is also used for ccache is some setups.
+CROSS_COMPILE is also used for ccache in some setups.
 CF
 --------------------------------------------------
@@ -162,3 +162,7 @@ For tags/TAGS/cscope targets, you can specify more than one arch
 to be included in the databases, separated by blank space. E.g.:
    $ make ALLSOURCE_ARCHS="x86 mips arm" tags
+To get all available archs you can also specify all. E.g.:
+    $ make ALLSOURCE_ARCHS=all tags
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b56ea860da21..1808f1157f30 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -145,11 +145,10 @@ and is between 256 and 4096 characters. It is defined in the file
        acpi=           [HW,ACPI,X86]
                        Advanced Configuration and Power Interface
-                        Format: { force | off | ht | strict | noirq | rsdt }
+                        Format: { force | off | strict | noirq | rsdt }
                        force -- enable ACPI if default was off
                        off -- disable ACPI if default was on
                        noirq -- do not use ACPI for IRQ routing
-                        ht -- run only enough ACPI to enable Hyper Threading
                        strict -- Be less tolerant of platforms that are not
                                strictly ACPI specification compliant.
                        rsdt -- prefer RSDT over (default) XSDT
@@ -758,6 +757,10 @@ and is between 256 and 4096 characters. It is defined in the file
                        Default value is 0.
                        Value can be changed at runtime via /selinux/enforce.
+        erst_disable    [ACPI]
+                        Disable Error Record Serialization Table (ERST)
+                        support.
        ether=          [HW,NET] Ethernet cards parameters
                        This option is obsoleted by the "netdev=" option, which
                        has equivalent usage. See its documentation for details.
@@ -852,6 +855,11 @@ and is between 256 and 4096 characters. It is defined in the file
        hd=             [EIDE] (E)IDE hard drive subsystem geometry
                        Format: <cyl>,<head>,<sect>
+        hest_disable    [ACPI]
+                        Disable Hardware Error Source Table (HEST) support;
+                        corresponding firmware-first mode error processing
+                        logic will be disabled.
        highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact
                        size of <nn>. This works even on boxes that have no
                        highmem otherwise. This also works to reduce highmem
@@ -1252,6 +1260,8 @@ and is between 256 and 4096 characters. It is defined in the file
                        * nohrst, nosrst, norst: suppress hard, soft
                          and both resets.
+                        * dump_id: dump IDENTIFY data.
                        If there are multiple matching configurations changing
                        the same attribute, the last one is used.
diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt
index aa60d1f627e5..c91ccc0720fa 100644
--- a/Documentation/mutex-design.txt
+++ b/Documentation/mutex-design.txt
@@ -66,14 +66,14 @@ of advantages of mutexes:
    c0377ccb <mutex_lock>:
    c0377ccb:       f0 ff 08                lock decl (%eax)
-    c0377cce:       78 0e                   js     c0377cde <.text.lock.mutex>
+    c0377cce:       78 0e                   js     c0377cde <.text..lock.mutex>
    c0377cd0:       c3                      ret
   the unlocking fastpath is equally tight:
    c0377cd1 <mutex_unlock>:
    c0377cd1:       f0 ff 00                lock incl (%eax)
-    c0377cd4:       7e 0f                   jle    c0377ce5 <.text.lock.mutex+0x7>
+    c0377cd4:       7e 0f                   jle    c0377ce5 <.text..lock.mutex+0x7>
    c0377cd6:       c3                      ret
 - 'struct mutex' semantics are well-defined and are enforced if
diff --git a/Documentation/timers/Makefile b/Documentation/timers/Makefile
index c85625f4ab25..73f75f8a87dc 100644
--- a/Documentation/timers/Makefile
+++ b/Documentation/timers/Makefile
@@ -2,7 +2,7 @@
 obj- := dummy.o
 # List of programs to build
-hostprogs-y := hpet_example
+hostprogs-$(CONFIG_X86) := hpet_example
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 070f2576707e..1387a69ae3aa 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -176,5 +176,6 @@
 175 -> Leadtek Winfast DTV1000S                 [107d:6655]
 176 -> Beholder BeholdTV 505 RDS                [0000:5051]
 177 -> Hawell HW-404M7
-179 -> Beholder BeholdTV H7                     [5ace:7190]
+178 -> Beholder BeholdTV H7                     [5ace:7190]
-180 -> Beholder BeholdTV A7                     [5ace:7090]
+179 -> Beholder BeholdTV A7                     [5ace:7090]
+180 -> Avermedia M733A                          [1461:4155,1461:4255]
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 8f3f5d33327c..f13eb036c439 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -290,6 +290,7 @@ sonixb		0c45:602e	Genius VideoCam Messenger
 sonixj          0c45:6040       Speed NVC 350K
 sonixj          0c45:607c       Sonix sn9c102p Hv7131R
 sonixj          0c45:60c0       Sangha Sn535
+sonixj          0c45:60ce       USB-PC-Camera-168 (TALK-5067)
 sonixj          0c45:60ec       SN9C105+MO4000
 sonixj          0c45:60fb       Surfer NoName
 sonixj          0c45:60fc       LG-LIC300