torvalds · jutaz · Dec 14, 2015 · macaris64 · Mar 17, 2016
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
@@ -234,14 +234,14 @@ don't take special care to determine the cache line size at run time
 only map virtual regions that begin and end on page boundaries (which
 are guaranteed also to be cache line boundaries).
 
-DMA_TO_DEVICE synchronisation must be done after the last modification
+DMA_TO_DEVICE synchronization must be done after the last modification
 of the memory region by the software and before it is handed off to
 the driver. Once this primitive is used, memory covered by this
 primitive should be treated as read-only by the device. If the device
 may write to it at any point, it should be DMA_BIDIRECTIONAL (see
 below).
 
-DMA_FROM_DEVICE synchronisation must be done before the driver
+DMA_FROM_DEVICE synchronization must be done before the driver
 accesses data that may be changed by the device. This memory should
 be treated as read-only by the driver. If the driver needs to write
 to it at any point, it should be DMA_BIDIRECTIONAL (see below).
@@ -349,7 +349,7 @@ void
 dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
  enum dma_data_direction direction)
 
-Synchronise a single contiguous or scatter/gather mapping for the CPU
+Synchronize a single contiguous or scatter/gather mapping for the CPU
 and device. With the sync_sg API, all the parameters must be the same
 as those passed into the single mapping API. With the sync_single API,
 you can use dma_handle and size parameters that aren't identical to
@@ -521,7 +521,7 @@ DMA_MEMORY_INCLUDES_CHILDREN - make the declared memory be allocated by
 dma_alloc_coherent of any child devices of this one (for memory residing
 on a bridge).
 
-DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. 
+DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions.
 Do not allow dma_alloc_coherent() to fall back to system memory when
 it's out of memory in the declared region.
 

diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt
@@ -42,7 +42,7 @@ requirements you pass the flag GFP_DMA to kmalloc.
 
 Unfortunately the memory available for ISA DMA is scarce so unless you
 allocate the memory during boot-up it's a good idea to also pass
-__GFP_REPEAT and __GFP_NOWARN to make the allocater try a bit harder.
+__GFP_REPEAT and __GFP_NOWARN to make the allocator try a bit harder.
 
 (This scarcity also means that you should allocate the buffer as
 early as possible and not release it until the driver is unloaded.)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
@@ -10,13 +10,13 @@ IRQ numbers.
 The number of interrupt controllers registered as unique irqchips
 show a rising tendency: for example subdrivers of different kinds
 such as GPIO controllers avoid reimplementing identical callback
-mechanisms as the IRQ core system by modelling their interrupt
+mechanisms as the IRQ core system by modeling their interrupt
 handlers as irqchips, i.e. in effect cascading interrupt controllers.
 
 Here the interrupt number loose all kind of correspondence to
 hardware interrupt numbers: whereas in the past, IRQ numbers could
 be chosen so they matched the hardware IRQ line into the root
-interrupt controller (i.e. the component actually fireing the
+interrupt controller (i.e. the component actually firing the
 interrupt line to the CPU) nowadays this number is just a number.
 
 For this reason we need a mechanism to separate controller-local

diff --git a/Documentation/SM501.txt b/Documentation/SM501.txt
@@ -19,7 +19,7 @@ management.
 The core registers drivers for both PCI and generic bus based
 chips via the platform device and driver system.
 
-On detection of a device, the core initialises the chip (which may
+On detection of a device, the core initializes the chip (which may
 be specified by the platform data) and then exports the selected
 peripheral set as platform devices for the specific drivers.
 
@@ -35,7 +35,7 @@ Each peripheral has a view of the device which is implicitly narrowed to
 the specific set of resources that peripheral requires in order to
 function correctly.
 
-The centralised memory allocation allows the driver to ensure that the
+The centralized memory allocation allows the driver to ensure that the
 maximum possible resource allocation can be made to the video subsystem
 as this is by-far the most resource-sensitive of the on-chip functions.
 
@@ -45,7 +45,7 @@ occurs the memory footprint of the video subsystem changes.
 
 Since video memory is difficult to move without changing the display
 (unless sufficient contiguous memory can be provided for the old and new
-modes simultaneously) the video driver fully utilises the memory area
+modes simultaneously) the video driver fully utilizes the memory area
 given to it by aligning fb0 to the start of the area and fb1 to the end
 of it. Any memory left over in the middle is used for the acceleration
 functions, which are transient and thus their location is less critical

diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt
@@ -82,7 +82,7 @@ by including a size argument in the structure:
  };
 
 As long as any subsequently added field, say param_4, is designed so that a
-zero value gives the previous behaviour, then this allows both directions of
+zero value gives the previous behavior, then this allows both directions of
 version mismatch:
 
  - To cope with a later userspace program calling an older kernel, the kernel

diff --git a/Documentation/assoc_array.txt b/Documentation/assoc_array.txt
@@ -184,11 +184,11 @@ MANIPULATION FUNCTIONS
 
 There are a number of functions for manipulating an associative array:
 
- (1) Initialise an associative array.
+ (1) Initialize an associative array.
 
  void assoc_array_init(struct assoc_array *array);
 
- This initialises the base structure for an associative array. It can't
+ This initializes the base structure for an associative array. It can't
  fail.
 
 
@@ -350,7 +350,7 @@ This will cause leaves with different length keys to scatter away from each
 other - and those with the same length keys to cluster together.
 
 It is also recommended that the index key begin with a hash of the rest of the
-key to maximise scattering throughout keyspace.
+key to maximize scattering throughout keyspace.
 
 The better the scattering, the wider and lower the internal tree will be.
 

diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
@@ -373,7 +373,7 @@ void obj_timeout(struct obj *obj)
 }
 
 (This is a simplification of the ARP queue management in the
- generic neighbour discover code of the networking. Olaf Kirch
+ generic neighbor discover code of the networking. Olaf Kirch
  found a bug wrt. memory barriers in kfree_skb() that exposed
  the atomic_t memory barrier requirements quite clearly.)
 

diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt
@@ -8,7 +8,7 @@ Wiki and git repositories are at:
 
 It's designed around the performance characteristics of SSDs - it only allocates
 in erase block sized buckets, and it uses a hybrid btree/log to track cached
-extants (which can be anywhere from a single sector to the bucket size). It's
+extents (which can be anywhere from a single sector to the bucket size). It's
 designed to avoid random writes at all costs; it fills up an erase block
 sequentially, then issues a discard before reusing it.
 

diff --git a/Documentation/binfmt_misc.txt b/Documentation/binfmt_misc.txt
@@ -1,14 +1,14 @@
- Kernel Support for miscellaneous (your favourite) Binary Formats v1.1
+ Kernel Support for miscellaneous (your favorite) Binary Formats v1.1
  =====================================================================
 
 This Kernel feature allows you to invoke almost (for restrictions see below)
 every program by simply typing its name in the shell.
 This includes for example compiled Java(TM), Python or Emacs programs.
 
 To achieve this you must tell binfmt_misc which interpreter has to be invoked
-with which binary. Binfmt_misc recognises the binary-type by matching some bytes
+with which binary. Binfmt_misc recognizes the binary-type by matching some bytes
 at the beginning of the file with a magic byte sequence (masking out specified
-bits) you have supplied. Binfmt_misc can also recognise a filename extension
+bits) you have supplied. Binfmt_misc can also recognize a filename extension
 aka '.com' or '.exe'.
 
 First you must mount binfmt_misc:
@@ -31,7 +31,7 @@ Here is what the fields mean:
  escape any NUL bytes; parsing halts at the first one. In a shell environment
  you might have to write \\x0a to prevent the shell from eating your \.
  If you chose filename extension matching, this is the extension to be
- recognised (without the '.', the \x0a specials are not allowed). Extension
+ recognized (without the '.', the \x0a specials are not allowed). Extension
  matching is case sensitive, and slashes '/' are not allowed!
  - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
  bits from matching by supplying a string like magic and as long as magic.
@@ -118,7 +118,7 @@ example.
 
 Your interpreter should NOT look in the PATH for the filename; the kernel
 passes it the full filename (or the file descriptor) to use. Using $PATH can
-cause unexpected behaviour and can be a security hazard.
+cause unexpected behavior and can be a security hazard.
 
 
 Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt
@@ -17,7 +17,7 @@ buffering. There are two sets of such features:
 
 To use these facilities, as discussed below, there needs to be just one
 producer and just one consumer. It is possible to handle multiple producers by
-serialising them, and to handle multiple consumers by serialising them.
+serializing them, and to handle multiple consumers by serializing them.
 
 
 Contents:

diff --git a/Documentation/clk.txt b/Documentation/clk.txt
@@ -1,7 +1,7 @@
  The Common Clk Framework
  Mike Turquette <mturquette@ti.com>
 
-This document endeavours to explain the common clk framework details,
+This document endeavors to explain the common clk framework details,
 and how to port a platform over to this framework. It is not yet a
 detailed explanation of the clock api in include/linux/clk.h, but
 perhaps someday it will include that information.

diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
@@ -97,7 +97,7 @@ from the map depending on the event is hot-add/hot-remove. There are currently
 no locking rules as of now. Typical usage is to init topology during boot,
 at which time hotplug is disabled.
 
-You really dont need to manipulate any of the system cpu maps. They should
+You really don't need to manipulate any of the system cpu maps. They should
 be read-only for most use. When setting up per-cpu resources almost always use
 cpu_possible_mask/for_each_possible_cpu() to iterate.
 

diff --git a/Documentation/cpu-load.txt b/Documentation/cpu-load.txt
@@ -22,7 +22,7 @@ closely, however due to the nature of how/when the kernel collects
 this data sometimes it can not be trusted at all.
 
 So how is this information collected? Whenever timer interrupt is
-signalled the kernel looks what kind of task was running at this
+signaled the kernel looks what kind of task was running at this
 moment and increments the counter that corresponds to this tasks
 kind/state. The problem with this is that the system could have
 switched between various states multiple times between two timer

diff --git a/Documentation/devices.txt b/Documentation/devices.txt
@@ -400,7 +400,7 @@ Your cooperation is appreciated.
  182 = /dev/perfctr Performance-monitoring counters
  183 = /dev/hwrng Generic random number generator
  184 = /dev/cpu/microcode CPU microcode update interface
- 186 = /dev/atomicps Atomic shapshot of process state data
+ 186 = /dev/atomicps Atomic snapshot of process state data
  187 = /dev/irnet IrNET device
  188 = /dev/smbusbios SMBus BIOS
  189 = /dev/ussp_ctl User space serial port control
@@ -2947,7 +2947,7 @@ Your cooperation is appreciated.
  2 = /dev/dvb/adapter0/sec0 (obsolete/unused)
  3 = /dev/dvb/adapter0/frontend0 first frontend device of first card
  4 = /dev/dvb/adapter0/demux0 first demux device of first card
- 5 = /dev/dvb/adapter0/dvr0 first digital video recoder device of first card
+ 5 = /dev/dvb/adapter0/dvr0 first digital video recorder device of first card
  6 = /dev/dvb/adapter0/ca0 first common access port of first card
  7 = /dev/dvb/adapter0/net0 first network device of first card
  8 = /dev/dvb/adapter0/osd0 first on-screen-display device of first card

diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
@@ -213,7 +213,7 @@ NOTES:
  In case it is allowed by the exporter:
  if the new buffer-user has stricter 'backing-storage constraints', and the
  exporter can handle these constraints, the exporter can just stall on the
- map_dma_buf until all outstanding access is completed (as signalled by
+ map_dma_buf until all outstanding access is completed (as signaled by
  unmap_dma_buf).
  Once all users have finished accessing and have unmapped this buffer, the
  exporter could potentially move the buffer to the stricter backing-storage,

diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
@@ -32,10 +32,10 @@ Dynamic debug has even more useful features:
  which can be read to display the complete list of known debug
  statements, to help guide you
 
-Controlling dynamic debug Behaviour
+Controlling dynamic debug Behavior
 ===================================
 
-The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a
+The behavior of pr_debug()/dev_dbg()s are controlled via writing to a
 control file in the 'debugfs' filesystem. Thus, you must first mount
 the debugfs filesystem, in order to make use of this feature.
 Subsequently, we refer to the control file as:
@@ -51,10 +51,10 @@ nullarbor:~ # echo 'file svcsock.c wtf 1 +p' >
  <debugfs>/dynamic_debug/control
 -bash: echo: write error: Invalid argument
 
-Viewing Dynamic Debug Behaviour
+Viewing Dynamic Debug Behavior
 ===========================
 
-You can view the currently configured behaviour of all the debug
+You can view the currently configured behavior of all the debug
 statements via:
 
 nullarbor:~ # cat <debugfs>/dynamic_debug/control

diff --git a/Documentation/edac.txt b/Documentation/edac.txt
@@ -658,7 +658,7 @@ exports one
  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:
+ To return to the default behavior 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
 

diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
@@ -123,7 +123,7 @@ At the bottom of your email, put the commonly-used patch delimiter before
 inserting your patch: three hyphens (---).
 
 Then from the "Message" menu item, select insert file and choose your patch.
-As an added bonus you can customise the message creation toolbar menu
+As an added bonus you can customize the message creation toolbar menu
 and put the "insert file" icon there.
 
 Make the composer window wide enough so that no lines wrap. As of

diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt
@@ -3,7 +3,7 @@ HSI - High-speed Synchronous Serial Interface
 1. Introduction
 ~~~~~~~~~~~~~~~
 
-High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol,
+High Speed Synchronous Interface (HSI) is a fullduplex, low latency protocol,
 that is optimized for die-level interconnect between an Application Processor
 and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
 implemented by multiple vendors since then.
@@ -49,7 +49,7 @@ use an arbitrary number of channels.
 ~~~~~~~~~~~~~~~~~~
 
 Each port automatically registers a generic client driver called hsi_char,
-which provides a charecter device for userspace representing the HSI port.
+which provides a character device for userspace representing the HSI port.
 It can be used to communicate via HSI from userspace. Userspace may
 configure the hsi_char device using the following ioctl commands:
 

diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt
@@ -117,7 +117,7 @@ Memory state around the buggy address:
  ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================
 
-The header of the report discribe what kind of bug happened and what kind of
+The header of the report describes what kind of bug happened and what kind of
 access caused it. It's followed by the description of the accessed slub object
 (see 'SLUB Debug output' section in Documentation/vm/slub.txt for details) and
 the description of the accessed memory page.