Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial

Pull trivial tree updates from Jiri Kosina:
 "The usual stuff from trivial tree"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (34 commits)
  treewide: relase -> release
  Documentation/cgroups/memory.txt: fix stat file documentation
  sysctl/net.txt: delete reference to obsolete 2.4.x kernel
  spinlock_api_smp.h: fix preprocessor comments
  treewide: Fix typo in printk
  doc: device tree: clarify stuff in usage-model.txt.
  open firmware: "/aliasas" -> "/aliases"
  md: bcache: Fixed a typo with the word 'arithmetic'
  irq/generic-chip: fix a few kernel-doc entries
  frv: Convert use of typedef ctl_table to struct ctl_table
  sgi: xpc: Convert use of typedef ctl_table to struct ctl_table
  doc: clk: Fix incorrect wording
  Documentation/arm/IXP4xx fix a typo
  Documentation/networking/ieee802154 fix a typo
  Documentation/DocBook/media/v4l fix a typo
  Documentation/video4linux/si476x.txt fix a typo
  Documentation/virtual/kvm/api.txt fix a typo
  Documentation/early-userspace/README fix a typo
  Documentation/video4linux/soc-camera.txt fix a typo
  lguest: fix CONFIG_PAE -> CONFIG_x86_PAE in comment
  ...

Documentation/DocBook/drm.tmpl

@@ -434,7 +434,7 @@ char *date;</synopsis>
       The DRM core includes two memory managers, namely Translation Table Maps
       (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
       manager to be developed and tried to be a one-size-fits-them all
-      solution. It provides a single userspace API to accomodate the need of
+      solution. It provides a single userspace API to accommodate the need of
       all hardware, supporting both Unified Memory Architecture (UMA) devices
       and devices with dedicated video RAM (i.e. most discrete video cards).
       This resulted in a large, complex piece of code that turned out to be
@@ -701,7 +701,7 @@ char *date;</synopsis>
         <para>
           Similar to global names, GEM file descriptors are also used to share GEM
           objects across processes. They offer additional security: as file
-          descriptors must be explictly sent over UNIX domain sockets to be shared
+          descriptors must be explicitly sent over UNIX domain sockets to be shared
           between applications, they can't be guessed like the globally unique GEM
           names.
         </para>
@@ -1154,7 +1154,7 @@ int max_width, max_height;</synopsis>
           </para>
           <para>
             The <methodname>page_flip</methodname> operation schedules a page flip.
-            Once any pending rendering targetting the new frame buffer has
+            Once any pending rendering targeting the new frame buffer has
             completed, the CRTC will be reprogrammed to display that frame buffer
             after the next vertical refresh. The operation must return immediately
             without waiting for rendering or page flip to complete and must block

Documentation/DocBook/media/dvb/frontend.xml

@@ -233,7 +233,7 @@ typedef enum fe_status {
 <entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
 </row><row>
 <entry align="char">FE_HAS_SYNC</entry>
-<entry align="char">Syncronization bytes was found</entry>
+<entry align="char">Synchronization bytes was found</entry>
 </row><row>
 <entry align="char">FE_HAS_LOCK</entry>
 <entry align="char">The DVB were locked and everything is working</entry>

Documentation/DocBook/media/v4l/controls.xml

@@ -3147,7 +3147,7 @@ giving priority to the center of the metered area.</entry>
 		  <entry>A multi-zone metering. The light intensity is measured
 in several points of the frame and the the results are combined. The
 algorithm of the zones selection and their significance in calculating the
-final value is device dependant.</entry>
+final value is device dependent.</entry>
 		</row>
 	      </tbody>
 	    </entrytbl>

Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml

@@ -24,7 +24,7 @@ into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
 plane (and the image), but is half as tall in pixels. The chroma plane is also
 grouped into 64x32 macroblocks.</para>
 	<para>Width of the buffer has to be aligned to the multiple of 128, and
-height alignment is 32. Every four adjactent buffers - two horizontally and two
+height alignment is 32. Every four adjacent buffers - two horizontally and two
 vertically are grouped together and are located in memory in Z or flipped Z
 order. </para>
 	<para>Layout of macroblocks in memory is presented in the following

Documentation/DocBook/writing_usb_driver.tmpl

@@ -83,7 +83,7 @@
   </para>
   <para>
       Because each different protocol causes a new driver to be created, I have
-      written a generic USB driver skeleton, modeled after the pci-skeleton.c
+      written a generic USB driver skeleton, modelled after the pci-skeleton.c
       file in the kernel source tree upon which many PCI network drivers have
       been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
       in the kernel source tree. In this article I will walk through the basics

Documentation/arm/IXP4xx

@@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
 - Timers (watchdog, OS)
 
 The following components of the chips are not supported by Linux and
-require the use of Intel's proprietary CSR softare:
+require the use of Intel's proprietary CSR software:
 
 - USB device interface
 - Network interfaces (HSS, Utopia, NPEs, etc)

Documentation/bcache.txt

@@ -181,7 +181,7 @@ want for getting the best possible numbers when benchmarking.
 
    In practice this isn't an issue because as soon as a write comes along it'll
    cause the btree node to be split, and you need almost no write traffic for
-   this to not show up enough to be noticable (especially since bcache's btree
+   this to not show up enough to be noticeable (especially since bcache's btree
    nodes are huge and index large regions of the device). But when you're
    benchmarking, if you're trying to warm the cache by reading a bunch of data
    and there's no other traffic - that can be a problem.
@@ -222,7 +222,7 @@ running
   it's in passthrough mode or caching).
 
 sequential_cutoff
-  A sequential IO will bypass the cache once it passes this threshhold; the
+  A sequential IO will bypass the cache once it passes this threshold; the
   most recent 128 IOs are tracked so sequential IO can be detected even when
   it isn't all done at once.
 
@@ -296,7 +296,7 @@ cache_miss_collisions
   since the synchronization for cache misses was rewritten)
 
 cache_readaheads
-  Count of times readahead occured.
+  Count of times readahead occurred.
 
 SYSFS - CACHE SET:
 
@@ -362,7 +362,7 @@ unregister
 SYSFS - CACHE SET INTERNAL:
 
 This directory also exposes timings for a number of internal operations, with
-separate files for average duration, average frequency, last occurence and max
+separate files for average duration, average frequency, last occurrence and max
 duration: garbage collection, btree read, btree node sorts and btree splits.
 
 active_journal_entries
@@ -417,7 +417,7 @@ freelist_percent
   space.
 
 io_errors
-  Number of errors that have occured, decayed by io_error_halflife.
+  Number of errors that have occurred, decayed by io_error_halflife.
 
 metadata_written
   Sum of all non data writes (btree writes and all other metadata).

Documentation/block/queue-sysfs.txt

@@ -93,7 +93,7 @@ To avoid priority inversion through request starvation, a request
 queue maintains a separate request pool per each cgroup when
 CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
 per-block-cgroup request pool.  IOW, if there are N block cgroups,
-each request queue may have upto N request pools, each independently
+each request queue may have up to N request pools, each independently
 regulated by nr_requests.
 
 optimal_io_size (RO)

Documentation/cgroups/memory.txt

@@ -304,7 +304,7 @@ kernel memory, we prevent new processes from being created when the kernel
 memory usage is too high.
 
 * slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
-of each kmem_cache is created everytime the cache is touched by the first time
+of each kmem_cache is created every time the cache is touched by the first time
 from inside the memcg. The creation is done lazily, so some objects can still be
 skipped while the cache is being created. All objects in a slab page should
 belong to the same memcg. This only fails to hold when a task is migrated to a
@@ -490,10 +490,10 @@ pgpgin		- # of charging events to the memory cgroup. The charging
 pgpgout		- # of uncharging events to the memory cgroup. The uncharging
 		event happens each time a page is unaccounted from the cgroup.
 swap		- # of bytes of swap usage
-inactive_anon	- # of bytes of anonymous memory and swap cache memory on
+inactive_anon	- # of bytes of anonymous and swap cache memory on inactive
 		LRU list.
 active_anon	- # of bytes of anonymous and swap cache memory on active
-		inactive LRU list.
+		LRU list.
 inactive_file	- # of bytes of file-backed memory on inactive LRU list.
 active_file	- # of bytes of file-backed memory on active LRU list.
 unevictable	- # of bytes of memory that cannot be reclaimed (mlocked etc).

Documentation/clk.txt

@@ -32,7 +32,7 @@ hardware-specific bits for the hypothetical "foo" hardware.
 
 Tying the two halves of this interface together is struct clk_hw, which
 is defined in struct clk_foo and pointed to within struct clk.  This
-allows easy for navigation between the two discrete halves of the common
+allows for easy navigation between the two discrete halves of the common
 clock interface.
 
 	Part 2 - common data structures and api

Documentation/device-mapper/cache.txt

@@ -87,7 +87,7 @@ Migration throttling
 
 Migrating data between the origin and cache device uses bandwidth.
 The user can set a throttle to prevent more than a certain amount of
-migration occuring at any one time.  Currently we're not taking any
+migration occurring at any one time.  Currently we're not taking any
 account of normal io traffic going to the devices.  More work needs
 doing here to avoid migrating during those peak io moments.
 

Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt

@@ -5,7 +5,7 @@ can combine interrupt sources as a group and provide a single interrupt request
 for the group. The interrupt request from each group are connected to a parent
 interrupt controller, such as GIC in case of Exynos4210.
 
-The interrupt combiner controller consists of multiple combiners. Upto eight
+The interrupt combiner controller consists of multiple combiners. Up to eight
 interrupt sources can be connected to a combiner. The combiner outputs one
 combined interrupt for its eight interrupt sources. The combined interrupt
 is usually connected to a parent interrupt controller.
@@ -14,8 +14,8 @@ A single node in the device tree is used to describe the interrupt combiner
 controller module (which includes multiple combiners). A combiner in the
 interrupt controller module shares config/control registers with other
 combiners. For example, a 32-bit interrupt enable/disable config register
-can accommodate upto 4 interrupt combiners (with each combiner supporting
-upto 8 interrupt sources).
+can accommodate up to 4 interrupt combiners (with each combiner supporting
+up to 8 interrupt sources).
 
 Required properties:
 - compatible: should be "samsung,exynos4210-combiner".

Documentation/devicetree/bindings/arm/spear/shirq.txt

@@ -14,7 +14,7 @@ A single node in the device tree is used to describe the shared
 interrupt multiplexor (one node for all groups). A group in the
 interrupt controller shares config/control registers with other groups.
 For example, a 32-bit interrupt enable/disable config register can
-accommodate upto 4 interrupt groups.
+accommodate up to 4 interrupt groups.
 
 Required properties:
   - compatible: should be, either of

Documentation/devicetree/bindings/clock/silabs,si5351.txt

@@ -4,7 +4,7 @@ Reference
 [1] Si5351A/B/C Data Sheet
     http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
 
-The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+The Si5351a/b/c are programmable i2c clock generators with up to 8 output
 clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
 3 output clocks are accessible. The internal structure of the clock
 generators can be found in [1].

Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt

@@ -51,7 +51,7 @@ Optional properties:
 * card-detect-delay: Delay in milli-seconds before detecting card after card
   insert event. The default value is 0.
 
-* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+* supports-highspeed: Enables support for high speed cards (up to 50MHz)
 
 * broken-cd: as documented in mmc core bindings.
 

Documentation/devicetree/bindings/powerpc/4xx/emac.txt

@@ -1,7 +1,7 @@
     4xx/Axon EMAC ethernet nodes
 
     The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
-    the Axon bridge.  To operate this needs to interact with a ths
+    the Axon bridge.  To operate this needs to interact with a this
     special McMAL DMA controller, and sometimes an RGMII or ZMII
     interface.  In addition to the nodes and properties described
     below, the node for the OPB bus on which the EMAC sits must have a

Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt

@@ -2,7 +2,7 @@ Broadcom BCM2835 SPI0 controller
 
 The BCM2835 contains two forms of SPI master controller, one known simply as
 SPI0, and the other known as the "Universal SPI Master"; part of the
-auxilliary block. This binding applies to the SPI0 controller.
+auxiliary block. This binding applies to the SPI0 controller.
 
 Required properties:
 - compatible: Should be "brcm,bcm2835-spi".

Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt

@@ -44,7 +44,7 @@ Example 1: In this example, the system uses only the first global timer
 	};
 
 Example 2: In this example, the MCT global and local timer interrupts are
-	   connected to two seperate interrupt controllers. Hence, an
+	   connected to two separate interrupt controllers. Hence, an
 	   interrupt-map is created to map the interrupts to the respective
 	   interrupt controllers.
 

Documentation/devicetree/bindings/usb/am33xx-usb.txt

@@ -12,7 +12,7 @@ AM33XX MUSB GLUE
    represents PERIPHERAL.
  - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
    represents PERIPHERAL.
- - power : Should be "250". This signifies the controller can supply upto
+ - power : Should be "250". This signifies the controller can supply up to
    500mA when operating in host mode.
 
 Example:

Documentation/devicetree/bindings/usb/omap-usb.txt

@@ -16,7 +16,7 @@ OMAP MUSB GLUE
    specifying ULPI and UTMI respectively.
  - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
    represents PERIPHERAL.
- - power : Should be "50". This signifies the controller can supply upto
+ - power : Should be "50". This signifies the controller can supply up to
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device