diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e32b1d78d50e15fe210295ee1ffee86bc01900cc..d5b0fd89f333fa86735aa986308fee4ab6ff015b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2624,7 +2624,7 @@
kvm-intel.flexpriority=
[KVM,Intel] Control KVM's use of FlexPriority feature
- (TPR shadow). Default is 1 (enabled). Disalbe by KVM if
+ (TPR shadow). Default is 1 (enabled). Disable by KVM if
hardware lacks support for it.
kvm-intel.nested=
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 2d495fa85a0ee9ea6f3e87b242de98e75c3d5e07..37cbc5c0a2ab4bc3ddf0f4742197cbb4f71bb9c1 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -99,7 +99,7 @@ Root
The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it
has one directory named ``admin``. The directory contains the files for
-privileged user space programs' control of DAMON. User space tools or deamons
+privileged user space programs' control of DAMON. User space tools or daemons
having the root permission could use this directory.
kdamonds/
@@ -397,7 +397,7 @@ be used for online analysis or tuning of the schemes.
The statistics can be retrieved by reading the files under ``stats`` directory
(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and
``qt_exceeds``), respectively. The files are not updated in real time, so you
-should ask DAMON sysfs interface to updte the content of the files for the
+should ask DAMON sysfs interface to update the content of the files for the
stats by writing a special keyword, ``update_schemes_stats`` to the relevant
``kdamonds/<N>/state`` file.
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index 7d7c7c8a545ca6699de1ece9ec7ccef46a871c0a..2898b270329785b57f4525b986d62259210018d4 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -266,7 +266,7 @@ for which it has a public key. Otherwise, it will also load modules that are
unsigned. Any module for which the kernel has a key, but which proves to have
a signature mismatch will not be permitted to load.
-Any module that has an unparseable signature will be rejected.
+Any module that has an unparsable signature will be rejected.
=========================================
diff --git a/Documentation/arch/arm/arm.rst b/Documentation/arch/arm/arm.rst
index 99d660fdf73fde73c0b8dfaed574cb69df286f27..7b41b89dd9bd0b0093a13cd09286ab382dd29727 100644
--- a/Documentation/arch/arm/arm.rst
+++ b/Documentation/arch/arm/arm.rst
@@ -141,7 +141,7 @@ ST506 hard drives
`*configure` harddrive set to 2). I've got an internal 20MB and a great
big external 5.25" FH 64MB drive (who could ever want more :-) ).
- I've just got 240K/s off it (a dd with bs=128k); thats about half of what
+ I've just got 240K/s off it (a dd with bs=128k); that's about half of what
RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting
last week :-)
diff --git a/Documentation/arch/arm/ixp4xx.rst b/Documentation/arch/arm/ixp4xx.rst
index a57235616294a3af1cc6d17a3adcaa1af5d3217e..17aafc610908f99ee353f76fe92190fc4d46977e 100644
--- a/Documentation/arch/arm/ixp4xx.rst
+++ b/Documentation/arch/arm/ixp4xx.rst
@@ -78,9 +78,9 @@ IXP4xx provides two methods of accessing PCI memory space:
1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
To access PCI via this space, we simply ioremap() the BAR
into the kernel and we can use the standard read[bwl]/write[bwl]
- macros. This is the preffered method due to speed but it
+ macros. This is the preferred method due to speed but it
limits the system to just 64MB of PCI memory. This can be
- problamatic if using video cards and other memory-heavy devices.
+ problematic if using video cards and other memory-heavy devices.
2) If > 64MB of memory space is required, the IXP4xx can be
configured to use indirect registers to access PCI This allows
diff --git a/Documentation/arch/arm/sunxi/clocks.rst b/Documentation/arch/arm/sunxi/clocks.rst
index 23bd03f3e21f4ef28ec66731069de324a3a74239..dfe6d48872107c2ee0f5fb5aec96d82ca17afceb 100644
--- a/Documentation/arch/arm/sunxi/clocks.rst
+++ b/Documentation/arch/arm/sunxi/clocks.rst
@@ -5,7 +5,7 @@ Frequently asked questions about the sunxi clock system
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
-Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
+Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
diff --git a/Documentation/arch/arm/swp_emulation.rst b/Documentation/arch/arm/swp_emulation.rst
index 6a608a9c3715888ee65dde65adf26d767f94c81d..bf205e3de36ec439e569fe7dce651354c0af1132 100644
--- a/Documentation/arch/arm/swp_emulation.rst
+++ b/Documentation/arch/arm/swp_emulation.rst
@@ -1,7 +1,7 @@
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
---------------------------------------------------------------------
-ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds
+ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends
moving to the load-locked/store-conditional instructions LDREX and STREX.
ARMv7 multiprocessing extensions introduce the ability to disable these
diff --git a/Documentation/arch/arm/tcm.rst b/Documentation/arch/arm/tcm.rst
index 1dc6c39220f98a77b3c898142b40b548e0c98917..7ce17a248af91fc48043f9a16d75e2befd5eea13 100644
--- a/Documentation/arch/arm/tcm.rst
+++ b/Documentation/arch/arm/tcm.rst
@@ -71,7 +71,7 @@ in <asm/tcm.h>. Using this interface it is possible to:
- Have the remaining TCM RAM added to a special
allocation pool with gen_pool_create() and gen_pool_add()
- and provice tcm_alloc() and tcm_free() for this
+ and provide tcm_alloc() and tcm_free() for this
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
diff --git a/Documentation/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
index a40a1742110bce1a85dde1a5f0776b31739ef319..737aa8661a211aecae5f9b94903f3439039ad3b9 100644
--- a/Documentation/arch/arm/vlocks.rst
+++ b/Documentation/arch/arm/vlocks.rst
@@ -155,7 +155,7 @@ the basic algorithm:
optimisation.
If there are too many CPUs to read the currently_voting array in
- one transaction then multiple transations are still required. The
+ one transaction then multiple transactions are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
diff --git a/Documentation/arch/arm64/acpi_object_usage.rst b/Documentation/arch/arm64/acpi_object_usage.rst
index 1da22200fdf8fe6cc1a8e006e37c9d978525a545..06d8a87971ef0da2bd4dc0751e7e4e1884f8cdc0 100644
--- a/Documentation/arch/arm64/acpi_object_usage.rst
+++ b/Documentation/arch/arm64/acpi_object_usage.rst
@@ -45,7 +45,7 @@ APMT Signature Reserved (signature == "APMT")
**Arm Performance Monitoring Table**
- This table describes the properties of PMU support implmented by
+ This table describes the properties of PMU support implemented by
components in the system.
BERT Section 18.3 (signature == "BERT")
diff --git a/Documentation/arch/arm64/arm-acpi.rst b/Documentation/arch/arm64/arm-acpi.rst
index 94274a8d84cf0af3dc5f0bb2df68c7da4b1a4d9a..a46c34fa96044c93c6c5e19764a94558187c6904 100644
--- a/Documentation/arch/arm64/arm-acpi.rst
+++ b/Documentation/arch/arm64/arm-acpi.rst
@@ -99,7 +99,7 @@ to replace the kernel.
When a Linux driver or subsystem is first implemented using ACPI, it by
definition ends up requiring a specific version of the ACPI specification
--- it's baseline. ACPI firmware must continue to work, even though it may
+-- its baseline. ACPI firmware must continue to work, even though it may
not be optimal, with the earliest kernel version that first provides support
for that baseline version of ACPI. There may be a need for additional drivers,
but adding new functionality (e.g., CPU power management) should not break
diff --git a/Documentation/arch/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst
index 657ac4af7be6ab3bb8730885d2758affc184cbb0..1565b9546e38d750cb6f56aee7b28d028dcd8d2b 100644
--- a/Documentation/arch/openrisc/openrisc_port.rst
+++ b/Documentation/arch/openrisc/openrisc_port.rst
@@ -106,7 +106,7 @@ History
a much improved version with changes all around.
10-04-2004 Matjaz Breskvar (phoenix@bsemi.com)
- alot of bugfixes all over.
+ a lot of bugfixes all over.
ethernet support, functional http and telnet servers.
running many standard linux apps.
@@ -114,7 +114,7 @@ History
port to 2.6.x
30-11-2004 Matjaz Breskvar (phoenix@bsemi.com)
- lots of bugfixes and enhancments.
+ lots of bugfixes and enhancements.
added opencores framebuffer driver.
09-10-2010 Jonas Bonn (jonas@southpole.se)
diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst
index 33520ecdb37abfdad85208bac0d2f2cc31856be9..32d6099ba9943501305275208367a928540d48e1 100644
--- a/Documentation/arch/x86/boot.rst
+++ b/Documentation/arch/x86/boot.rst
@@ -1105,7 +1105,7 @@ The kernel command line should not be located below the real-mode
code, nor should it be located in high memory.
-Sample Boot Configuartion
+Sample Boot Configuration
=========================
As a sample configuration, assume the following layout of the real
diff --git a/Documentation/arch/x86/buslock.rst b/Documentation/arch/x86/buslock.rst
index 31ec0ef780868304f2dc44616fbeeb9436ac042e..4c5a4822eeb70b850f2f543c73e06f8a612f4c96 100644
--- a/Documentation/arch/x86/buslock.rst
+++ b/Documentation/arch/x86/buslock.rst
@@ -32,7 +32,7 @@ mechanisms to detect split locks and bus locks.
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
-Alignment Check (#AC) exception when a split lock operation is attemped.
+Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
diff --git a/Documentation/arch/x86/mds.rst b/Documentation/arch/x86/mds.rst
index 5d4330be200f980cf4ea7a8e17b9e89012dcc381..e73fdff62c0aa10a0d6de89e6a62f8b2185920a7 100644
--- a/Documentation/arch/x86/mds.rst
+++ b/Documentation/arch/x86/mds.rst
@@ -60,7 +60,7 @@ needed for exploiting MDS requires:
data
The existence of such a construct in the kernel cannot be excluded with
-100% certainty, but the complexity involved makes it extremly unlikely.
+100% certainty, but the complexity involved makes it extremely unlikely.
There is one exception, which is untrusted BPF. The functionality of
untrusted BPF is limited, but it needs to be thoroughly investigated
diff --git a/Documentation/arch/x86/sgx.rst b/Documentation/arch/x86/sgx.rst
index 2bcbffacbed559db0431beca50e409dbf641b379..d90796adc2ec88a534c6c5b6ba1af7749f15afc0 100644
--- a/Documentation/arch/x86/sgx.rst
+++ b/Documentation/arch/x86/sgx.rst
@@ -245,7 +245,7 @@ SGX will likely become unusable because the memory available to SGX is
limited. However, while this may be fatal to SGX, the rest of the kernel
is unlikely to be impacted and should continue to work.
-As a result, when this happpens, user should stop running any new
+As a result, when this happens, user should stop running any new
SGX workloads, (or just any new workloads), and migrate all valuable
workloads. Although a machine reboot can recover all EPC memory, the bug
should be reported to Linux developers.
diff --git a/Documentation/arch/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst
index 1ecbd0ba9a2e6fdf59e34143056efee758171f3a..75d1741694304a0286dc0d70e4a9bce923d0e32f 100644
--- a/Documentation/arch/xtensa/atomctl.rst
+++ b/Documentation/arch/xtensa/atomctl.rst
@@ -23,7 +23,7 @@ doing a Cached (WB) transaction and use the Memory RCW for un-cached
operations.
For systems without an coherent cache controller, non-MX, we always
-use the memory controllers RCW, thought non-MX controlers likely
+use the memory controllers RCW, though non-MX controllers likely
support the Internal Operation.
CUSTOMER-WARNING:
diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 07a97aa266685ca19068eddb032152be4867be31..6a760c0eb1924edd13096d244d3a53809855d2e7 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -209,7 +209,7 @@ will require extra work due to the application tag.
sector must be set, and the bio should have all data pages
added. It is up to the caller to ensure that the bio does not
change while I/O is in progress.
- Complete bio with error if prepare failed for some reson.
+ Complete bio with error if prepare failed for some reason.
5.3 Passing Existing Integrity Metadata
diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
index 1713b2890abb04e4bd05ce240171fd444c4078a0..ff74b3ec4a98c6da3e6da2609f32ca3051d80a62 100644
--- a/Documentation/block/ublk.rst
+++ b/Documentation/block/ublk.rst
@@ -238,7 +238,7 @@ The's IO is assigned by a unique tag, which is 1:1 mapping with IO
request of ``/dev/ublkb*``.
UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
-the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for
+the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for
exporting IO info to the server; such as IO offset, length, OP/flags and
buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id
and IO tag directly.
diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst
index 3139c7c02e795fbc1b7f4fa3952f50e58046ed29..a22b6ad105fbb5880c3295d7e72f262fb5cc7f70 100644
--- a/Documentation/bpf/cpumasks.rst
+++ b/Documentation/bpf/cpumasks.rst
@@ -364,7 +364,7 @@ can be used to query the contents of cpumasks.
----
Some example usages of these querying kfuncs were shown above. We will not
-replicate those exmaples here. Note, however, that all of the aforementioned
+replicate those examples here. Note, however, that all of the aforementioned
kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so
please take a look there if you're looking for more examples of how they can be
used.
diff --git a/Documentation/bpf/graph_ds_impl.rst b/Documentation/bpf/graph_ds_impl.rst
index 61274622b71d85c7f5002c134fa2b0309cf713e5..06288cc719b3d7bc5f68d97c54357c2cf1b2f53c 100644
--- a/Documentation/bpf/graph_ds_impl.rst
+++ b/Documentation/bpf/graph_ds_impl.rst
@@ -23,7 +23,7 @@ Introduction
The BPF map API has historically been the main way to expose data structures
of various types for use within BPF programs. Some data structures fit naturally
-with the map API (HASH, ARRAY), others less so. Consequentially, programs
+with the map API (HASH, ARRAY), others less so. Consequently, programs
interacting with the latter group of data structures can be hard to parse
for kernel programmers without previous BPF experience.
diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst
index b64809514b0f784a0d30a0ef81d723bc6b3c11b8..70380a2a01b452816ea214cb5c48a3fdaa607638 100644
--- a/Documentation/fault-injection/fault-injection.rst
+++ b/Documentation/fault-injection/fault-injection.rst
@@ -243,7 +243,7 @@ proc entries
Error Injectable Functions
--------------------------
-This part is for the kenrel developers considering to add a function to
+This part is for the kernel developers considering to add a function to
ALLOW_ERROR_INJECTION() macro.
Requirements for the Error Injectable Functions
diff --git a/Documentation/fb/deferred_io.rst b/Documentation/fb/deferred_io.rst
index 7300cff255a39a22d4d69c64abea633ed7a6feab..7fc1933b06d96b6d9740f778069073fd99ce674b 100644
--- a/Documentation/fb/deferred_io.rst
+++ b/Documentation/fb/deferred_io.rst
@@ -9,7 +9,7 @@ works:
- userspace app like Xfbdev mmaps framebuffer
- deferred IO and driver sets up fault and page_mkwrite handlers
-- userspace app tries to write to mmaped vaddress
+- userspace app tries to write to mmapped vaddress
- we get pagefault and reach fault handler
- fault handler finds and returns physical page
- we get page_mkwrite where we add this page to a list
diff --git a/Documentation/fb/sm712fb.rst b/Documentation/fb/sm712fb.rst
index 994dad3b0238337b4d86eb8c1874405a34227e72..8e000f80b5bc6d3c0b534abffbe506cc8f7f8c38 100644
--- a/Documentation/fb/sm712fb.rst
+++ b/Documentation/fb/sm712fb.rst
@@ -31,5 +31,5 @@ Missing Features
================
(alias TODO list)
- * 2D acceleratrion
+ * 2D acceleration
* dual-head support
diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
index 42466ff49c5809c04bb02ba92d0bf21704454685..88d5a52b13d88af7f7cbe5a9e0d9b3be761034bd 100644
--- a/Documentation/fb/sstfb.rst
+++ b/Documentation/fb/sstfb.rst
@@ -73,7 +73,7 @@ Module insertion
the device will be /dev/fb0. You can check this by doing a
cat /proc/fb. You can find a copy of con2fb in tools/ directory.
if you don't have another fb device, this step is superfluous,
- as the console subsystem automagicaly binds ttys to the fb.
+ as the console subsystem automagically binds ttys to the fb.
#. switch to the virtual console you just mapped. "tadaaa" ...
Module removal
diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt
index 9c5d39eebef2152077c4536a2996916b9c14ffee..97c65ed2ac23b84121b46402a4a3024b647323fa 100644
--- a/Documentation/features/core/thread-info-in-task/arch-support.txt
+++ b/Documentation/features/core/thread-info-in-task/arch-support.txt
@@ -1,7 +1,7 @@
#
# Feature name: thread-info-in-task
# Kconfig: THREAD_INFO_IN_TASK
-# description: arch makes use of the core kernel facility to embedd thread_info in task_struct
+# description: arch makes use of the core kernel facility to embed thread_info in task_struct
#
-----------------------
| arch |status|
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst
index 1b5f0cc3e4cafd03a769be7ad9ce00f5c6fa7bab..1e0e0bb6fdf912903d03b9ed52839d7b00226cf6 100644
--- a/Documentation/filesystems/9p.rst
+++ b/Documentation/filesystems/9p.rst
@@ -79,7 +79,7 @@ Options
cache=mode specifies a caching policy. By default, no caches are used.
The mode can be specified as a bitmask or by using one of the
- prexisting common 'shortcuts'.
+ preexisting common 'shortcuts'.
The bitmask is described below: (unspecified bits are reserved)
========== ====================================================
diff --git a/Documentation/filesystems/befs.rst b/Documentation/filesystems/befs.rst
index 79f9740d76ffcad9b0a0061f4635a44ef0e03cfa..a22f603b2938eaad951565ec9de2b3c7b335e178 100644
--- a/Documentation/filesystems/befs.rst
+++ b/Documentation/filesystems/befs.rst
@@ -106,8 +106,8 @@ iocharset=xxx Use xxx as the name of the NLS translation table.
debug The driver will output debugging information to the syslog.
============= ===========================================================
-How to Get Lastest Version
-==========================
+How to Get Latest Version
+=========================
The latest version is currently available at:
<http://befs-driver.sourceforge.net/>
diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst
index fc7abf712315aa23b6ca97cd87e55ccac112839a..e04a27bdbe19ce2b3dd474e069031cede57ba13f 100644
--- a/Documentation/filesystems/caching/cachefiles.rst
+++ b/Documentation/filesystems/caching/cachefiles.rst
@@ -416,7 +416,7 @@ process is the target of an operation by some other process (SIGKILL for
example).
The subjective security holds the active security properties of a process, and
-may be overridden. This is not seen externally, and is used whan a process
+may be overridden. This is not seen externally, and is used when a process
acts upon another object, for example SIGKILLing another process or opening a
file.
diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst
index 1d18e9def183ee3d2d3bca5697054b3b497120e3..665b27f1556e2ec7752dc867db30217f684088c4 100644
--- a/Documentation/filesystems/caching/netfs-api.rst
+++ b/Documentation/filesystems/caching/netfs-api.rst
@@ -59,7 +59,7 @@ A filesystem would typically have a volume cookie for each superblock.
The filesystem then acquires a cookie for each file within that volume using an
object key. Object keys are binary blobs and only need to be unique within
-their parent volume. The cache backend is reponsible for rendering the binary
+their parent volume. The cache backend is responsible for rendering the binary
blob into something it can use and may employ hash tables, trees or whatever to
improve its ability to find an object. This is transparent to the network
filesystem.
@@ -91,7 +91,7 @@ actually required and it can use the fscache I/O API directly.
Volume Registration
===================
-The first step for a network filsystem is to acquire a volume cookie for the
+The first step for a network filesystem is to acquire a volume cookie for the
volume it wants to access::
struct fscache_volume *
@@ -119,7 +119,7 @@ is provided. If the coherency data doesn't match, the entire cache volume will
be invalidated.
This function can return errors such as EBUSY if the volume key is already in
-use by an acquired volume or ENOMEM if an allocation failure occured. It may
+use by an acquired volume or ENOMEM if an allocation failure occurred. It may
also return a NULL volume cookie if fscache is not enabled. It is safe to
pass a NULL cookie to any function that takes a volume cookie. This will
cause that function to do nothing.
diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst
index 8c9342ed6d257b30d5c284379897c85b8dedf86f..ac22138de6a4f594ed5fb64e720d37a678f406e8 100644
--- a/Documentation/filesystems/configfs.rst
+++ b/Documentation/filesystems/configfs.rst
@@ -253,7 +253,7 @@ to be used.
If binary attribute is readable and the config_item provides a
ct_item_ops->read_bin_attribute() method, that method will be called
whenever userspace asks for a read(2) on the attribute. The converse
-will happen for write(2). The reads/writes are bufferred so only a
+will happen for write(2). The reads/writes are buffered so only a
single read/write will occur; the attributes' need not concern itself
with it.
diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst
index c04609d8ee243297c974a939c46062bdbb6a4de1..719e90f1988e7a37cecac4ca50aeade47e6b4612 100644
--- a/Documentation/filesystems/dax.rst
+++ b/Documentation/filesystems/dax.rst
@@ -291,7 +291,7 @@ The DAX code does not work correctly on architectures which have virtually
mapped caches such as ARM, MIPS and SPARC.
Calling :c:func:`get_user_pages()` on a range of user memory that has been
-mmaped from a `DAX` file will fail when there are no 'struct page' to describe
+mmapped from a `DAX` file will fail when there are no 'struct page' to describe
those pages. This problem has been addressed in some device drivers
by adding optional struct page support for pages under the control of
the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of
diff --git a/Documentation/filesystems/devpts.rst b/Documentation/filesystems/devpts.rst
index a03248ddfb4cd8d21250db1afcbb558374815b46..b6324ab1960d013533c5a467be24fcbfff29269e 100644
--- a/Documentation/filesystems/devpts.rst
+++ b/Documentation/filesystems/devpts.rst
@@ -5,8 +5,8 @@ The Devpts Filesystem
=====================
Each mount of the devpts filesystem is now distinct such that ptys
-and their indicies allocated in one mount are independent from ptys
-and their indicies in all other mounts.
+and their indices allocated in one mount are independent from ptys
+and their indices in all other mounts.
All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node
with permissions ``0000``.
diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst
index 0152888cac29b0bc0f9dc80fc3f63ae4f1bebe6e..a1eb4a11a1d0f97fe3a34fcbfe01856aaf1d3ef4 100644
--- a/Documentation/filesystems/ext4/super.rst
+++ b/Documentation/filesystems/ext4/super.rst
@@ -772,7 +772,7 @@ The ``s_default_mount_opts`` field is any combination of the following:
* - 0x0010
- Do not support 32-bit UIDs. (EXT4_DEFM_UID16)
* - 0x0020
- - All data and metadata are commited to the journal.
+ - All data and metadata are committed to the journal.
(EXT4_DEFM_JMODE_DATA)
* - 0x0040
- All data are flushed to the disk before metadata are committed to the
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 9359978a5af26019ed43ace34c7da3b0055f37ff..d32c6209685d64bae996ed110ea9cfe7543fa14c 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -359,7 +359,7 @@ errors=%s Specify f2fs behavior on critical errors. This supports modes:
====================== =============== =============== ========
mode continue remount-ro panic
====================== =============== =============== ========
- access ops normal noraml N/A
+ access ops normal normal N/A
syscall errors -EIO -EROFS N/A
mount option rw ro N/A
pending dir write keep keep N/A
@@ -480,7 +480,7 @@ Note: please refer to the manpage of dump.f2fs(8) to get full option list.
sload.f2fs
----------
-The sload.f2fs gives a way to insert files and directories in the exisiting disk
+The sload.f2fs gives a way to insert files and directories in the existing disk
image. This tool is useful when building f2fs images given compiled files.
Note: please refer to the manpage of sload.f2fs(8) to get full option list.
@@ -792,7 +792,7 @@ Allocating disk space
as a method of optimally implementing that function.
However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to
-fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having
+fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having
zero or random data, which is useful to the below scenario where:
1. create(fd)
diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst
index d14f230f0b1234ea035dbba93fd5229707ef95d7..bec25c8b3e4b5cbd318ab6b65ef45e45227607fb 100644
--- a/Documentation/filesystems/gfs2-glocks.rst
+++ b/Documentation/filesystems/gfs2-glocks.rst
@@ -78,7 +78,7 @@ The minimum hold time for each lock is the time after a remote lock
grant for which we ignore remote demote requests. This is in order to
prevent a situation where locks are being bounced around the cluster
from node to node with none of the nodes making any progress. This
-tends to show up most with shared mmaped files which are being written
+tends to show up most with shared mmapped files which are being written
to by multiple nodes. By delaying the demotion in response to a
remote callback, that gives the userspace program time to make
some progress before the pages are unmapped.
diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst
index ad6d216405768ea46aa28e069de233516187274a..9700fdff411dd47b61c12796d131dbe5629b3ce1 100644
--- a/Documentation/filesystems/idmappings.rst
+++ b/Documentation/filesystems/idmappings.rst
@@ -36,7 +36,7 @@ and write down the mappings it will generate::
From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an
idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are
order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
-the set of all possible ids useable on a given system.
+the set of all possible ids usable on a given system.
Looking at this mathematically briefly will help us highlight some properties
that make it easier to understand how we can translate between idmappings. For
@@ -47,7 +47,7 @@ example, we know that the inverse idmapping is an order isomorphism as well::
k10002 -> u24
Given that we are dealing with order isomorphisms plus the fact that we're
-dealing with subsets we can embedd idmappings into each other, i.e. we can
+dealing with subsets we can embed idmappings into each other, i.e. we can
sensibly translate between different idmappings. For example, assume we've been
given the three idmappings::
@@ -60,7 +60,7 @@ and id ``k11000`` which has been generated by the first idmapping by mapping
Because we're dealing with order isomorphic subsets it is meaningful to ask
what id ``k11000`` corresponds to in the second or third idmapping. The
-straightfoward algorithm to use is to apply the inverse of the first idmapping,
+straightforward algorithm to use is to apply the inverse of the first idmapping,
mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
either the second idmapping mapping or third idmapping mapping. The second
idmapping would map ``u1000`` down to ``21000``. The third idmapping would map
@@ -367,7 +367,7 @@ So with the second step the kernel guarantees that a valid userspace id can be
written to disk. If it can't the kernel will refuse the creation request to not
even remotely risk filesystem corruption.
-The astute reader will have realized that this is simply a varation of the
+The astute reader will have realized that this is simply a variation of the
crossmapping algorithm we mentioned above in a previous section. First, the
kernel maps the caller's userspace id down into a kernel id according to the
caller's idmapping and then maps that kernel id up according to the
@@ -458,7 +458,7 @@ the kernel id that was created in the caller's idmapping. This has mainly two
consequences.
First, that we can't allow a caller to ultimately write to disk with another
-userspace id. We could only do this if we were to mount the whole fileystem
+userspace id. We could only do this if we were to mount the whole filesystem
with the caller's or another idmapping. But that solution is limited to a few
filesystems and not very flexible. But this is a use-case that is pretty
important in containerized workloads.
@@ -589,7 +589,7 @@ on their work machine.
In both cases changing ownership recursively has grave implications. The most
obvious one is that ownership is changed globally and permanently. In the home
-directory case this change in ownership would even need to happen everytime the
+directory case this change in ownership would even need to happen every time the
user switches from their home to their work machine. For really large sets of
files this becomes increasingly costly.
@@ -662,7 +662,7 @@ use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers.
To illustrate why this helper currently exists, consider what happens when we
change ownership of an inode from an idmapped mount. After we generated
a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to
-this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership.
+this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership.
Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t``
or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and
``vfsgid_into_kgid()``.
diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst
index 73a4176144b3b80aff4db87bd4ab3bd8e96c35c4..48b95d04f72d5a25df0de37ac87a52d8f7471998 100644
--- a/Documentation/filesystems/netfs_library.rst
+++ b/Documentation/filesystems/netfs_library.rst
@@ -155,7 +155,7 @@ conflicting writes or track dirty data and needs to put the acquired folio if
an error occurs after calling the helper.
The helpers manage the read request, calling back into the network filesystem
-through the suppplied table of operations. Waits will be performed as
+through the supplied table of operations. Waits will be performed as
necessary before returning for helpers that are meant to be synchronous.
If an error occurs, the ->free_request() will be called to clean up the
diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst
index a94c7a9748d794d4c4c066206048d8d9c180ce5d..4804441155f518b44b7c8e83300e41d3ee6209d3 100644
--- a/Documentation/filesystems/nfs/client-identifier.rst
+++ b/Documentation/filesystems/nfs/client-identifier.rst
@@ -131,7 +131,7 @@ deployments, this construction is usually adequate. Often, however,
the node name by itself is not adequately unique, and can change
unexpectedly. Problematic situations include:
- - NFS-root (diskless) clients, where the local DCHP server (or
+ - NFS-root (diskless) clients, where the local DHCP server (or
equivalent) does not provide a unique host name.
- "Containers" within a single Linux host. If each container has
diff --git a/Documentation/filesystems/nfs/rpc-cache.rst b/Documentation/filesystems/nfs/rpc-cache.rst
index bb164eea969bd4315d1efc0c883254bb2e9511aa..339efd75016a2e5c2bffd75e3870351d8c317a90 100644
--- a/Documentation/filesystems/nfs/rpc-cache.rst
+++ b/Documentation/filesystems/nfs/rpc-cache.rst
@@ -78,7 +78,7 @@ Creating a Cache
include taking references to shared objects.
void update(struct cache_head \*orig, struct cache_head \*new)
- Set the 'content' fileds in 'new' from 'orig'.
+ Set the 'content' fields in 'new' from 'orig'.
int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h)
Optional. Used to provide a /proc file that lists the
diff --git a/Documentation/filesystems/nfs/rpc-server-gss.rst b/Documentation/filesystems/nfs/rpc-server-gss.rst
index ccaea9e7cea250fa496cef05f9dff860585c60e4..5c1a1c58fc27e3e2ced04f13bfd77f4b98887bb5 100644
--- a/Documentation/filesystems/nfs/rpc-server-gss.rst
+++ b/Documentation/filesystems/nfs/rpc-server-gss.rst
@@ -29,7 +29,7 @@ The Linux kernel, at the moment, supports only the KRB5 mechanism, and
depends on GSSAPI extensions that are KRB5 specific.
GSSAPI is a complex library, and implementing it completely in kernel is
-unwarranted. However GSSAPI operations are fundementally separable in 2
+unwarranted. However GSSAPI operations are fundamentally separable in 2
parts:
- initial context establishment
diff --git a/Documentation/filesystems/nilfs2.rst b/Documentation/filesystems/nilfs2.rst
index 6c49f04e9e0a95020f1b2e099d57105cfafd01ca..e3a5c8977f2cc2a3a265305a8ec44a00dc212105 100644
--- a/Documentation/filesystems/nilfs2.rst
+++ b/Documentation/filesystems/nilfs2.rst
@@ -231,7 +231,7 @@ file structures (nilfs_finfo), and per block structures (nilfs_binfo)::
The logs include regular files, directory files, symbolic link files
-and several meta data files. The mata data files are the files used
+and several meta data files. The meta data files are the files used
to maintain file system meta data. The current version of NILFS2 uses
the following meta data files::
diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst
index f0cf05cad2ba97827568c621051ff15783a82ac8..2b86a9b3a6de30477cfb79a2fa9101d5faf38523 100644
--- a/Documentation/filesystems/ntfs3.rst
+++ b/Documentation/filesystems/ntfs3.rst
@@ -112,7 +112,7 @@ this table marked with no it means default is without **no**.
Todo list
=========
- Full journaling support over JBD. Currently journal replaying is supported
- which is not necessarily as effectice as JBD would be.
+ which is not necessarily as effective as JBD would be.
References
==========
diff --git a/Documentation/filesystems/orangefs.rst b/Documentation/filesystems/orangefs.rst
index 463e37694250ada04c5bfeeaa798525f1a2e5325..931159e61796c7ac6465c48d641d458f7957e23a 100644
--- a/Documentation/filesystems/orangefs.rst
+++ b/Documentation/filesystems/orangefs.rst
@@ -274,7 +274,7 @@ then contains:
of kcalloced memory. This memory is used as an array of pointers
to each of the pages in the IO buffer through a call to get_user_pages.
* desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))``
- bytes of kcalloced memory. This memory is further intialized:
+ bytes of kcalloced memory. This memory is further initialized:
user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc
structure. user_desc->ptr points to the IO buffer.
diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst
index eb7d2c88ddecec72efde088dc589c69d6c032736..cc4761599ac973692b61b40cfa608c40f1883ba7 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -195,7 +195,7 @@ handle it in two different ways:
1. return EXDEV error: this error is returned by rename(2) when trying to
move a file or directory across filesystem boundaries. Hence
- applications are usually prepared to hande this error (mv(1) for example
+ applications are usually prepared to handle this error (mv(1) for example
recursively copies the directory tree). This is the default behavior.
2. If the "redirect_dir" feature is enabled, then the directory will be
@@ -235,7 +235,7 @@ Mount options:
Redirects are not created and not followed.
- "redirect_dir=off":
If "redirect_always_follow" is enabled in the kernel/module config,
- this "off" traslates to "follow", otherwise it translates to "nofollow".
+ this "off" translates to "follow", otherwise it translates to "nofollow".
When the NFS export feature is enabled, every copied up directory is
indexed by the file handle of the lower inode and a file handle of the
diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst
index d2d684ae77984f066b96fe028477fc5aec2e31ec..ffafd93001df40c56f1290d9109a78427c394163 100644
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@ -177,7 +177,7 @@ settles down a bit.
**mandatory**
s_export_op is now required for exporting a filesystem.
-isofs, ext2, ext3, resierfs, fat
+isofs, ext2, ext3, reiserfs, fat
can be used as examples of very different filesystems.
---
@@ -470,7 +470,7 @@ has been taken to VFS and filesystems need to provide a non-NULL
**mandatory**
If you implement your own ->llseek() you must handle SEEK_HOLE and
-SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to
+SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to
support it in some way. The generic handler assumes that the entire file is
data and there is a virtual hole at the end of the file. So if the provided
offset is less than i_size and SEEK_DATA is specified, return the same offset.
@@ -517,7 +517,7 @@ The witch is dead! Well, 2/3 of it, anyway. ->d_revalidate() and
->create() doesn't take ``struct nameidata *``; unlike the previous
two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that
-local filesystems can ignore tha argument - they are guaranteed that the
+local filesystems can ignore this argument - they are guaranteed that the
object doesn't exist. It's remote/distributed ones that might care...
---
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 7897a7dafcbc18caac24bbe9345162f611d111ce..d6109c78a228c66b389db0f6ab80b0675ef9074a 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -507,12 +507,12 @@ pressure if the memory is clean. Please note that the printed value might
be lower than the real value due to optimizations used in the current
implementation. If this is not desirable please file a bug report.
-"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
+"AnonHugePages" shows the amount of memory backed by transparent hugepage.
-"ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by
+"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by
huge pages.
-"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by
+"Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by
hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical
reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field.
@@ -561,7 +561,7 @@ encoded manner. The codes are the following:
mm mixed map area
hg huge page advise flag
nh no huge page advise flag
- mg mergable advise flag
+ mg mergeable advise flag
bt arm64 BTI guarded page
mt arm64 MTE allocation tags are enabled
um userfaultfd missing tracking
@@ -1081,7 +1081,7 @@ Writeback
AnonPages
Non-file backed pages mapped into userspace page tables
Mapped
- files which have been mmaped, such as libraries
+ files which have been mmapped, such as libraries
Shmem
Total memory used by shared memory (shmem) and tmpfs
KReclaimable
@@ -2229,7 +2229,7 @@ are not related to tasks.
Chapter 5: Filesystem behavior
==============================
-Originally, before the advent of pid namepsace, procfs was a global file
+Originally, before the advent of pid namespace, procfs was a global file
system. It means that there was only one procfs instance in the system.
When pid namespace was added, a separate procfs instance was mounted in
diff --git a/Documentation/filesystems/qnx6.rst b/Documentation/filesystems/qnx6.rst
index 523b798f04e75f3084cfc28b2d635e697b5aeb93..560f3d4704227bf1326cd118c49810c1e3486585 100644
--- a/Documentation/filesystems/qnx6.rst
+++ b/Documentation/filesystems/qnx6.rst
@@ -135,7 +135,7 @@ 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 independent of the
-underlaying filesystem.
+underlying filesystem.
Long filenames
--------------
diff --git a/Documentation/filesystems/seq_file.rst b/Documentation/filesystems/seq_file.rst
index a6726082a7c2571061a55b4577b320514e59c12d..1e1713d00010126b7dc9c47874e645038e6b20f4 100644
--- a/Documentation/filesystems/seq_file.rst
+++ b/Documentation/filesystems/seq_file.rst
@@ -130,7 +130,7 @@ called SEQ_START_TOKEN; it can be used if you wish to instruct your
show() function (described below) to print a header at the top of the
output. SEQ_START_TOKEN should only be used if the offset is zero,
however. SEQ_START_TOKEN has no special meaning to the core seq_file
-code. It is provided as a convenience for a start() funciton to
+code. It is provided as a convenience for a start() function to
communicate with the next() and show() functions.
The next function to implement is called, amazingly, next(); its job is to
@@ -217,7 +217,7 @@ between the calls to start() and stop(), so holding a lock during that time
is a reasonable thing to do. The seq_file code will also avoid taking any
other locks while the iterator is active.
-The iterater value returned by start() or next() is guaranteed to be
+The iterator value returned by start() or next() is guaranteed to be
passed to a subsequent next() or stop() call. This allows resources
such as locks that were taken to be reliably released. There is *no*
guarantee that the iterator will be passed to show(), though in practice
diff --git a/Documentation/filesystems/ubifs-authentication.rst b/Documentation/filesystems/ubifs-authentication.rst
index 5210aed2afbc34268dd309f2f5a39d7671296aa8..3d85ee88719a6c00fc5985555fed050522fe3905 100644
--- a/Documentation/filesystems/ubifs-authentication.rst
+++ b/Documentation/filesystems/ubifs-authentication.rst
@@ -130,7 +130,7 @@ marked as dirty are written to the flash to update the persisted index.
Journal
~~~~~~~
-To avoid wearing out the flash, the index is only persisted (*commited*) when
+To avoid wearing out the flash, the index is only persisted (*committed*) when
certain conditions are met (eg. ``fsync(2)``). The journal is used to record
any changes (in form of inode nodes, data nodes etc.) between commits
of the index. During mount, the journal is read from the flash and replayed
diff --git a/Documentation/filesystems/vfat.rst b/Documentation/filesystems/vfat.rst
index 760a4d83fdf9273fe3702d4ff1c181bd8cf1137a..b289c4449cd0c2026b1742a2e2039efca780de9d 100644
--- a/Documentation/filesystems/vfat.rst
+++ b/Documentation/filesystems/vfat.rst
@@ -50,7 +50,7 @@ VFAT MOUNT OPTIONS
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
- check is too unflexible. With this option you can
+ check is too inflexible. With this option you can
relax it.
**codepage=###**
diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
index a751f6d01eb24df33cb9137a5649910212ce2503..0c6b86d3e8f1d3629345dfa12c406b04d4b02067 100644
--- a/Documentation/filesystems/vfs.rst
+++ b/Documentation/filesystems/vfs.rst
@@ -761,7 +761,7 @@ is an error during writeback, they expect that error to be reported when
a file sync request is made. After an error has been reported on one
request, subsequent requests on the same file descriptor should return
0, unless further writeback errors have occurred since the previous file
-syncronization.
+synchronization.
Ideally, the kernel would report errors only on file descriptions on
which writes were done that subsequently failed to be written back. The
diff --git a/Documentation/filesystems/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs-online-fsck-design.rst
index 791ab264b77e1cddf0fa65f37cfa9a094cadc7e4..1625d1131093edb797fcd7c49f2cc724847c1467 100644
--- a/Documentation/filesystems/xfs-online-fsck-design.rst
+++ b/Documentation/filesystems/xfs-online-fsck-design.rst
@@ -293,7 +293,7 @@ The seven phases are as follows:
Before starting repairs, the summary counters are checked and any necessary
repairs are performed so that subsequent repairs will not fail the resource
reservation step due to wildly incorrect summary counters.
- Unsuccesful repairs are requeued as long as forward progress on repairs is
+ Unsuccessful repairs are requeued as long as forward progress on repairs is
made somewhere in the filesystem.
Free space in the filesystem is trimmed at the end of phase 4 if the
filesystem is clean.
@@ -542,7 +542,7 @@ ondisk structure.
Inspiration for quota and file link count repair strategies were drawn from
sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View
-Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views
+Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views
and Their Indexes"
<http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011.
@@ -605,7 +605,7 @@ functionality.
The cron job does not have this protection.
- **Fuzz Kiddiez**: There are many people now who seem to think that running
- automated fuzz testing of ondisk artifacts to find mischevious behavior and
+ automated fuzz testing of ondisk artifacts to find mischievous behavior and
spraying exploit code onto the public mailing list for instant zero-day
disclosure is somehow of some social benefit.
In the view of this author, the benefit is realized only when the fuzz
@@ -1351,7 +1351,7 @@ If the leaf information exceeds a single filesystem block, a dabtree (also
rooted at block 0) is created to map hashes of the attribute names to leaf
blocks in the attr fork.
-Checking an extended attribute structure is not so straightfoward due to the
+Checking an extended attribute structure is not so straightforward due to the
lack of separation between attr blocks and index blocks.
Scrub must read each block mapped by the attr fork and ignore the non-leaf
blocks:
@@ -1401,7 +1401,7 @@ If the free space has been separated and the second partition grows again
beyond one block, then a dabtree is used to map hashes of dirent names to
directory data blocks.
-Checking a directory is pretty straightfoward:
+Checking a directory is pretty straightforward:
1. Walk the dabtree in the second partition (if present) to ensure that there
are no irregularities in the blocks or dabtree mappings that do not point to
@@ -1524,7 +1524,7 @@ Only online fsck has this requirement of total consistency of AG metadata, and
should be relatively rare as compared to filesystem change operations.
Online fsck coordinates with transaction chains as follows:
-* For each AG, maintain a count of intent items targetting that AG.
+* For each AG, maintain a count of intent items targeting that AG.
The count should be bumped whenever a new item is added to the chain.
The count should be dropped when the filesystem has locked the AG header
buffers and finished the work.
@@ -2102,7 +2102,7 @@ quicksort and a heapsort subalgorithm in the spirit of
kernel.
To sort records in a reasonably short amount of time, ``xfarray`` takes
advantage of the binary subpartitioning offered by quicksort, but it also uses
-heapsort to hedge aginst performance collapse if the chosen quicksort pivots
+heapsort to hedge against performance collapse if the chosen quicksort pivots
are poor.
Both algorithms are (in general) O(n * lg(n)), but there is a wide performance
gulf between the two implementations.
@@ -2566,8 +2566,8 @@ old metadata blocks:
The transaction rolling in steps 2c and 3 represent a weakness in the repair
algorithm, because a log flush and a crash before the end of the reap step can
result in space leaking.
-Online repair functions minimize the chances of this occuring by using very
-large transactions, which each can accomodate many thousands of block freeing
+Online repair functions minimize the chances of this occurring by using very
+large transactions, which each can accommodate many thousands of block freeing
instructions.
Repair moves on to reaping the old blocks, which will be presented in a
subsequent :ref:`section<reaping>` after a few case studies of bulk loading.
@@ -5090,7 +5090,7 @@ This scan after validation of all filesystem metadata (except for the summary
counters) as phase 6.
The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map
to find areas that are allocated to file data fork extents.
-Gaps betweeen data fork extents that are smaller than 64k are treated as if
+Gaps between data fork extents that are smaller than 64k are treated as if
they were data fork extents to reduce the command setup overhead.
When the space map scan accumulates a region larger than 32MB, a media
verification request is sent to the disk as a directio read of the raw block
diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst
index 394b9f15dce059348673453000fa3c8f5ac5062f..c22124c2213d5dc48140c65e8e1211d3d175cf12 100644
--- a/Documentation/filesystems/zonefs.rst
+++ b/Documentation/filesystems/zonefs.rst
@@ -378,7 +378,7 @@ The attributes defined are as follows.
sequential zone files. Failure to do so can result in write errors.
* **max_active_seq_files**: This attribute reports the maximum number of
sequential zone files that are in an active state, that is, sequential zone
- files that are partially writen (not empty nor full) or that have a zone that
+ files that are partially written (not empty nor full) or that have a zone that
is explicitly open (which happens only if the *explicit-open* mount option is
used). This number is always equal to the maximum number of active zones that
the device supports. A value of 0 means that the mounted device has no limit
diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst
index 784850adfcb674bb5b5e5b09b2b86107d1b5dd50..868a0a40bb76f1494bcf8e53bfc2307b8d7eb2b6 100644
--- a/Documentation/firmware-guide/acpi/osi.rst
+++ b/Documentation/firmware-guide/acpi/osi.rst
@@ -55,7 +55,7 @@ quirk, a bug, or a bug-fix.
However this was discovered to be abused by other BIOS vendors to change
completely unrelated code on completely unrelated systems. This prompted
-an evaluation of all of it's uses. This uncovered that they aren't needed
+an evaluation of all of its uses. This uncovered that they aren't needed
for any of the original reasons. As such, the kernel will not respond to
any custom Linux-* strings by default.
diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst
index 0499aa92d08dd1b9585df81a459329fcdf70d44b..59a4f54a3ac7d4506b3a28331c90bef5a046157a 100644
--- a/Documentation/gpu/amdgpu/display/mpo-overview.rst
+++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst
@@ -178,7 +178,7 @@ Multiple Display MPO
AMDGPU supports display MPO when using multiple displays; however, this feature
behavior heavily relies on the compositor implementation. Keep in mind that
-usespace can define different policies. For example, some OSes can use MPO to
+userspace can define different policies. For example, some OSes can use MPO to
protect the plane that handles the video playback; notice that we don't have
many limitations for a single display. Nonetheless, this manipulation can have
many more restrictions for a multi-display scenario. The below example shows a
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
index b8ab05e42dbb5df3881ff47423edb38805c41bde..b748b8ae70b2a9e41972d740444a1ac8974f469d 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -378,7 +378,7 @@ SCDC Helper Functions Reference
HDMI Infoframes Helper Reference
================================
-Strictly speaking this is not a DRM helper library but generally useable
+Strictly speaking this is not a DRM helper library but generally usable
by any driver interfacing with HDMI outputs like v4l or alsa drivers.
But it nicely fits into the overall topic of mode setting helper
libraries and hence is also included here.
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index c92d425cb2dd2f873c31be009ed24c2b4c4211fd..a0c83fc481264e31fb28c305f62efa2e4c5696d4 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -66,11 +66,11 @@ Composition Properties`_ and related chapters.
For the output routing the first step is encoders (represented by
:c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those
are really just internal artifacts of the helper libraries used to implement KMS
-drivers. Besides that they make it unecessarily more complicated for userspace
+drivers. Besides that they make it unnecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can't remove them
-at this point. Futhermore the exposed restrictions are often wrongly set by
+at this point. Furthermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.
@@ -260,7 +260,7 @@ Taken all together there's two consequences for the atomic design:
drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct
drm_connector_state <drm_connector_state>` for connectors. These are the only
objects with userspace-visible and settable state. For internal state drivers
- can subclass these structures through embeddeding, or add entirely new state
+ can subclass these structures through embedding, or add entirely new state
structures for their globally shared hardware functions, see :c:type:`struct
drm_private_state<drm_private_state>`.
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
index fe35a291ff3e0938a2ed809a77bdc405e29a052d..044e6b2ed1bef98d1990168cb507768bc37f70fe 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -8,7 +8,7 @@ DRM drivers can choose to export partly standardised text output via the
`fops->show_fdinfo()` as part of the driver specific file operations registered
in the `struct drm_driver` object registered with the DRM core.
-One purpose of this output is to enable writing as generic as practicaly
+One purpose of this output is to enable writing as generic as practically
feasible `top(1)` like userspace monitoring tools.
Given the differences between various DRM drivers the specification of the
@@ -119,7 +119,7 @@ drm-engine-<keystr> tag and shall contain the maximum frequency for the given
engine. Taken together with drm-cycles-<keystr>, this can be used to calculate
percentage utilization of the engine, whereas drm-engine-<keystr> only reflects
time active without considering what frequency the engine is operating as a
-percentage of it's maximum frequency.
+percentage of its maximum frequency.
Memory
^^^^^^
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 60ea21734902323cf55429b2f02ad92fc81883cf..378e825754d5f84aad4049960e3396dc318a29c1 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -304,10 +304,10 @@ reads of following commands. Actions issued between different contexts
and the only way to synchronize across contexts (even from the same
file descriptor) is through the use of fences. At least as far back as
Gen4, also have that a context carries with it a GPU HW context;
-the HW context is essentially (most of atleast) the state of a GPU.
+the HW context is essentially (most of at least) the state of a GPU.
In addition to the ordering guarantees, the kernel will restore GPU
state via HW context when commands are issued to a context, this saves
-user space the need to restore (most of atleast) the GPU state at the
+user space the need to restore (most of at least) the GPU state at the
start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer
work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
to identify what context to use with the command.
diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd670f3acd2d016963c6d1c5426997d..0f9590834829ed8aa7538843d2fd2adc81b10129 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,7 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De
,Virtual GPU,“suggested Xâ€,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector
,,“suggested Yâ€,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB
-i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255."
+i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255."
,,“audioâ€,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“modeâ€,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD
,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d2b3ad08c8eb5973bb5fcc9dce7f3..633a016563ae4a5cbd981170edcbfaa1a057cf28 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -328,7 +328,7 @@ of course we’d better share as much as possible between different products. To
achieve this, split the komeda device into two layers: CORE and CHIP.
- CORE: for common features and capabilities handling.
-- CHIP: for register programing and HW specific feature (limitation) handling.
+- CHIP: for register programming and HW specific feature (limitation) handling.
CORE can access CHIP by three chip function structures:
@@ -481,7 +481,7 @@ Build komeda to be a Linux module driver
Now we have two level devices:
- komeda_dev: describes the real display hardware.
-- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS.
+- komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS.
All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev,
the module driver is only a simple wrapper to pass the Linux command
diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
index 240ef200f76c4e844bc5feb8d36c0463d04f6f33..9509cc4224f4ae7db911481f773cb85c5756d839 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -23,7 +23,7 @@ module
The module that generated the crashdump.
time
- The kernel time at crash formated as seconds.microseconds.
+ The kernel time at crash formatted as seconds.microseconds.
comm
Comm string for the binary that generated the fault.
diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst
index d630f15ab7958f95a879b4931c47a7279d071d6d..23ba7006929b9644f539007623c547063cc81f65 100644
--- a/Documentation/gpu/rfc/i915_scheduler.rst
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -37,7 +37,7 @@ i915 with the DRM scheduler is:
* Watchdog hooks into DRM scheduler
* Lots of complexity of the GuC backend can be pulled out once
integrated with DRM scheduler (e.g. state machine gets
- simplier, locking gets simplier, etc...)
+ simpler, locking gets simpler, etc...)
* Execlists backend will minimum required to hook in the DRM scheduler
* Legacy interface
* Features like timeslicing / preemption / virtual engines would
diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst
index 9a1dcdf2799efd54cf95fa30335f82598022703e..0b3b525ac62002c16a24f4cd3fa7d9b9dbdff4d7 100644
--- a/Documentation/gpu/rfc/i915_vm_bind.rst
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -90,7 +90,7 @@ submission, they need only one dma-resv fence list updated. Thus, the fast
path (where required mappings are already bound) submission latency is O(1)
w.r.t the number of VM private BOs.
-VM_BIND locking hirarchy
+VM_BIND locking hierarchy
-------------------------
The locking design here supports the older (execlist based) execbuf mode, the
newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 68bdafa0284f55f6c8933c8bf4ae6b0c5618dca5..993948eee1a7db984a78efdae4668a114db7f4cb 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -65,7 +65,7 @@ Clean up the clipped coordination confusion around planes
---------------------------------------------------------
We have a helper to get this right with drm_plane_helper_check_update(), but
-it's not consistently used. This should be fixed, preferrably in the atomic
+it's not consistently used. This should be fixed, preferably in the atomic
helpers (and drivers then moved over to clipped coordinates). Probably the
helper should also be moved from drm_plane_helper.c to the atomic helpers, to
avoid confusion - the other helpers in that file are all deprecated legacy
@@ -181,13 +181,13 @@ reversed.
To solve this we need one standard per-object locking mechanism, which is
dma_resv_lock(). This lock needs to be called as the outermost lock, with all
-other driver specific per-object locks removed. The problem is tha rolling out
+other driver specific per-object locks removed. The problem is that rolling out
the actual change to the locking contract is a flag day, due to struct dma_buf
buffer sharing.
Level: Expert
-Convert logging to drm_* functions with drm_device paramater
+Convert logging to drm_* functions with drm_device parameter
------------------------------------------------------------
For drivers which could have multiple instances, it is necessary to
@@ -244,7 +244,7 @@ Level: Advanced
Benchmark and optimize blitting and format-conversion function
--------------------------------------------------------------
-Drawing to dispay memory quickly is crucial for many applications'
+Drawing to display memory quickly is crucial for many applications'
performance.
On at least x86-64, sys_imageblit() is significantly slower than
diff --git a/Documentation/hwmon/pmbus-core.rst b/Documentation/hwmon/pmbus-core.rst
index cff93adf6e42e5d3cbbe2da1503b886bd058d819..1eaf2b0158376812eaff1786d01b0f330c85eab8 100644
--- a/Documentation/hwmon/pmbus-core.rst
+++ b/Documentation/hwmon/pmbus-core.rst
@@ -345,7 +345,7 @@ PMBUS_NO_CAPABILITY
Some PMBus chips don't respond with valid data when reading the CAPABILITY
register. For such chips, this flag should be set so that the PMBus core
-driver doesn't use CAPABILITY to determine it's behavior.
+driver doesn't use CAPABILITY to determine its behavior.
PMBUS_READ_STATUS_AFTER_FAILED_CHECK
diff --git a/Documentation/input/devices/iforce-protocol.rst b/Documentation/input/devices/iforce-protocol.rst
index 8634beac3fdb67b72d137012664f824eaeb2008c..52c1e0dd0ab73a78a0884b329356168154379261 100644
--- a/Documentation/input/devices/iforce-protocol.rst
+++ b/Documentation/input/devices/iforce-protocol.rst
@@ -49,7 +49,7 @@ OP DATA
== ====
The 2B, LEN and CS fields have disappeared, probably because USB handles
-frames and data corruption is handled or unsignificant.
+frames and data corruption is handled or insignificant.
First, I describe effects that are sent by the device to the computer
diff --git a/Documentation/input/multi-touch-protocol.rst b/Documentation/input/multi-touch-protocol.rst
index 1085cbee4ee720bf465b804b0ccdafc177b8ff43..47d3dcb5d44bdac391758ea9addf671f434c4531 100644
--- a/Documentation/input/multi-touch-protocol.rst
+++ b/Documentation/input/multi-touch-protocol.rst
@@ -383,7 +383,7 @@ Finger Tracking
---------------
The process of finger tracking, i.e., to assign a unique trackingID to each
-initiated contact on the surface, is a Euclidian Bipartite Matching
+initiated contact on the surface, is a Euclidean Bipartite Matching
problem. At each event synchronization, the set of actual contacts is
matched to the set of contacts from the previous synchronization. A full
implementation can be found in [#f3]_.
diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
index d56bb706172ff0bb0b2d46cb57e7619700b05b3e..8d950f3ffeddba1a4e330035c16e6db2149a279d 100644
--- a/Documentation/livepatch/reliable-stacktrace.rst
+++ b/Documentation/livepatch/reliable-stacktrace.rst
@@ -40,7 +40,7 @@ Principally, the reliable stacktrace function must ensure that either:
.. note::
In some cases it is legitimate to omit specific functions from the trace,
but all other functions must be reported. These cases are described in
- futher detail below.
+ further detail below.
Secondly, the reliable stacktrace function must be robust to cases where
the stack or other unwind state is corrupt or otherwise unreliable. The
diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst
index 82f36cab61bddc93606c39b059d196d7a781fbf0..56b90eea27312e0a438260eb10425e811f154c9a 100644
--- a/Documentation/locking/lockdep-design.rst
+++ b/Documentation/locking/lockdep-design.rst
@@ -29,7 +29,7 @@ the validator will shoot a splat if incorrect.
A lock-class's behavior is constructed by its instances collectively:
when the first instance of a lock-class is used after bootup the class
gets registered, then all (subsequent) instances will be mapped to the
-class and hence their usages and dependecies will contribute to those of
+class and hence their usages and dependencies will contribute to those of
the class. A lock-class does not go away when a lock instance does, but
it can be removed if the memory space of the lock class (static or
dynamic) is reclaimed, this happens for example when a module is
@@ -105,7 +105,7 @@ exact case is for the lock as of the reporting time.
+--------------+-------------+--------------+
The character '-' suggests irq is disabled because if otherwise the
-charactor '?' would have been shown instead. Similar deduction can be
+character '?' would have been shown instead. Similar deduction can be
applied for '+' too.
Unused locks (e.g., mutexes) cannot be part of the cause of an error.
diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst
index 7f56fc0d7c31688d012dfea7d072675817e31814..3e763f77a620a75e34a3b4c8e6b4237e95a6b1a4 100644
--- a/Documentation/locking/locktorture.rst
+++ b/Documentation/locking/locktorture.rst
@@ -113,7 +113,7 @@ stutter
without pausing.
shuffle_interval
- The number of seconds to keep the test threads affinitied
+ The number of seconds to keep the test threads affinitized
to a particular subset of the CPUs, defaults to 3 seconds.
Used in conjunction with test_no_idle_hz.
diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst
index 9933faad47714c2cc79a91e7f5016df169a6c374..80c914f6eae7ab07476491c4eba96c004508e28d 100644
--- a/Documentation/locking/locktypes.rst
+++ b/Documentation/locking/locktypes.rst
@@ -500,7 +500,7 @@ caveats also apply to bit spinlocks.
Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT
using conditional (#ifdef'ed) code changes at the usage site. In contrast,
usage-site changes are not needed for the spinlock_t substitution.
-Instead, conditionals in header files and the core locking implemementation
+Instead, conditionals in header files and the core locking implementation
enable the compiler to do the substitution transparently.
diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst
index 9aa512c3a12c6cda16cf37da3420f8cc941d5077..fec21e6f22841d86aef9feeeb684ab0f6993a16e 100644
--- a/Documentation/mm/hmm.rst
+++ b/Documentation/mm/hmm.rst
@@ -417,7 +417,7 @@ entries. Any attempt to access the swap entry results in a fault which is
resovled by replacing the entry with the original mapping. A driver gets
notified that the mapping has been changed by MMU notifiers, after which point
it will no longer have exclusive access to the page. Exclusive access is
-guranteed to last until the driver drops the page lock and page reference, at
+guaranteed to last until the driver drops the page lock and page reference, at
which point any CPU faults on the page may proceed as described.
Memory cgroup (memcg) and rss accounting
diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst
index ba48a441feed854cd16431cb50c816eb6d0c8971..483b72aa7c117dd80fb8dd2742a5353c3fb54feb 100644
--- a/Documentation/mm/hwpoison.rst
+++ b/Documentation/mm/hwpoison.rst
@@ -48,7 +48,7 @@ of applications. KVM support requires a recent qemu-kvm release.
For the KVM use there was need for a new signal type so that
KVM can inject the machine check into the guest with the proper
address. This in theory allows other applications to handle
-memory failures too. The expection is that near all applications
+memory failures too. The expectation is that most applications
won't do that, but some very specialized ones might.
Failure recovery modes
diff --git a/Documentation/mm/page_migration.rst b/Documentation/mm/page_migration.rst
index e35af7805be54a6f43f9f7d2047b4ec6dafcb0e8..f1ce67a26615285d2c5616d5978a26fc7bc1f69c 100644
--- a/Documentation/mm/page_migration.rst
+++ b/Documentation/mm/page_migration.rst
@@ -180,7 +180,7 @@ The following events (counters) can be used to monitor page migration.
4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split.
5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had
- to be split. After splitting, a migration retry was used for it's sub-pages.
+ to be split. After splitting, a migration retry was used for its sub-pages.
THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or
PGMIGRATE_FAIL events. For example, a THP migration failure will cause both
diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst
index d5ac8511eb67923cd28cd885873955e2d56fea8d..67f1338440a50ab942160f6489964c41bc7c3b9e 100644
--- a/Documentation/mm/unevictable-lru.rst
+++ b/Documentation/mm/unevictable-lru.rst
@@ -463,7 +463,7 @@ can request that a region of memory be mlocked by supplying the MAP_LOCKED flag
to the mmap() call. There is one important and subtle difference here, though.
mmap() + mlock() will fail if the range cannot be faulted in (e.g. because
mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail.
-The mmaped area will still have properties of the locked area - pages will not
+The mmapped area will still have properties of the locked area - pages will not
get swapped out - but major page faults to fault memory in might still happen.
Furthermore, any mmap() call or brk() call that expands the heap by a task
diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst
index 689a6907c70b5f8fe0df1ced0032daf0ae442ee5..21f159b8afbe8e30938680596a9c281c54cf6482 100644
--- a/Documentation/mm/vmemmap_dedup.rst
+++ b/Documentation/mm/vmemmap_dedup.rst
@@ -11,7 +11,7 @@ HugeTLB
This section is to explain how HugeTLB Vmemmap Optimization (HVO) works.
The ``struct page`` structures are used to describe a physical page frame. By
-default, there is a one-to-one mapping from a page frame to it's corresponding
+default, there is a one-to-one mapping from a page frame to its corresponding
``struct page``.
HugeTLB pages consist of multiple base page size pages and is supported by many
diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml
index 57d1c1c4918f2d25da8db5a7ce86e122fbee6c7a..2627a384ae01be02f371e1436a34915f84847930 100644
--- a/Documentation/netlink/genetlink-c.yaml
+++ b/Documentation/netlink/genetlink-c.yaml
@@ -41,7 +41,7 @@ properties:
description: Name of the define for the family name.
type: string
c-version-name:
- description: Name of the define for the verion of the family.
+ description: Name of the define for the version of the family.
type: string
max-by-define:
description: Makes the number of attributes and commands be specified by a define, not an enum value.
diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml
index 43b769c98fb277b8c4cf7e0c7fd6eb01bc94c828..30803dc21123afc0b1ac708b19d0f3a52e414e3c 100644
--- a/Documentation/netlink/genetlink-legacy.yaml
+++ b/Documentation/netlink/genetlink-legacy.yaml
@@ -41,7 +41,7 @@ properties:
description: Name of the define for the family name.
type: string
c-version-name:
- description: Name of the define for the verion of the family.
+ description: Name of the define for the version of the family.
type: string
max-by-define:
description: Makes the number of attributes and commands be specified by a define, not an enum value.
diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst
index 28925e19622dfa429e8651bdfb391ca001b4f783..f7a73421eb76a1e358650592f767a24e46ca01ac 100644
--- a/Documentation/networking/bonding.rst
+++ b/Documentation/networking/bonding.rst
@@ -1636,7 +1636,7 @@ your init script::
-----------------------------------------
This section applies to distros which use /etc/network/interfaces file
-to describe network interface configuration, most notably Debian and it's
+to describe network interface configuration, most notably Debian and its
derivatives.
The ifup and ifdown commands on Debian don't support bonding out of
diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst
index 3da590953ce85a10b777da4546e1b611ce906fa1..e0c7b95f505b2f2f132248aab2505d1ac923e36f 100644
--- a/Documentation/networking/devlink/devlink-port.rst
+++ b/Documentation/networking/devlink/devlink-port.rst
@@ -321,9 +321,9 @@ API allows to configure following rate object's parameters:
Allows for usage of Weighted Fair Queuing arbitration scheme among
siblings. This arbitration scheme can be used simultaneously with the
strict priority. As a node is configured with a higher rate it gets more
- BW relative to it's siblings. Values are relative like a percentage
+ BW relative to its siblings. Values are relative like a percentage
points, they basically tell how much BW should node take relative to
- it's siblings.
+ its siblings.
``parent``
Parent node name. Parent node rate limits are considered as additional limits
@@ -343,7 +343,7 @@ Arbitration flow from the high level:
#. If group of nodes have the same priority perform WFQ arbitration on
that subgroup. Use ``tx_weight`` as a parameter for this arbitration.
-#. Select the winner node, and continue arbitration flow among it's children,
+#. Select the winner node, and continue arbitration flow among its children,
until leaf node is reached, and the winner is established.
#. If all the nodes from the highest priority sub-group are satisfied, or
diff --git a/Documentation/networking/packet_mmap.rst b/Documentation/networking/packet_mmap.rst
index c5da1a5d93de827f65058ba4a6ddf761af399f49..30a3be3c48f398302d985db57acefaf2b902ac4b 100644
--- a/Documentation/networking/packet_mmap.rst
+++ b/Documentation/networking/packet_mmap.rst
@@ -755,7 +755,7 @@ AF_PACKET TPACKET_V3 example
============================
AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame
-sizes by doing it's own memory management. It is based on blocks where polling
+sizes by doing its own memory management. It is based on blocks where polling
works on a per block basis instead of per ring as in TPACKET_V2 and predecessor.
It is said that TPACKET_V3 brings the following benefits:
diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst
index ef341be2882b1a03ccd28f727a35f491a5534d44..13225965c9a4c03537da9254d3696e677013cdbc 100644
--- a/Documentation/power/energy-model.rst
+++ b/Documentation/power/energy-model.rst
@@ -87,9 +87,9 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework.
Registration of 'advanced' EM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The 'advanced' EM gets it's name due to the fact that the driver is allowed
+The 'advanced' EM gets its name due to the fact that the driver is allowed
to provide more precised power model. It's not limited to some implemented math
-formula in the framework (like it's in 'simple' EM case). It can better reflect
+formula in the framework (like it is in 'simple' EM case). It can better reflect
the real power measurements performed for each performance state. Thus, this
registration method should be preferred in case considering EM static power
(leakage) is important.
diff --git a/Documentation/powerpc/dscr.rst b/Documentation/powerpc/dscr.rst
index 2ab99006014cc7862fb0df6a0c9052a95899a7f6..f735ec5375d5576b806663368f893472d3e678e8 100644
--- a/Documentation/powerpc/dscr.rst
+++ b/Documentation/powerpc/dscr.rst
@@ -6,7 +6,7 @@ DSCR register in powerpc allows user to have some control of prefetch of data
stream in the processor. Please refer to the ISA documents or related manual
for more detailed information regarding how to use this DSCR to attain this
control of the prefetches . This document here provides an overview of kernel
-support for DSCR, related kernel objects, it's functionalities and exported
+support for DSCR, related kernel objects, its functionalities and exported
user interface.
(A) Data Structures:
diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt
index f032b4eaf2051401d875533e36d905ba0ceca2fd..a4f647e4fffa9f4f5b6eafc17fa115c4c6c7da24 100644
--- a/Documentation/powerpc/kasan.txt
+++ b/Documentation/powerpc/kasan.txt
@@ -40,7 +40,7 @@ checks can be delayed until after the MMU is set is up, and we can just not
instrument any code that runs with translations off after booting. This is the
current approach.
-To avoid this limitiation, the KASAN shadow would have to be placed inside the
+To avoid this limitation, the KASAN shadow would have to be placed inside the
linear mapping, using the same high-bits trick we use for the rest of the linear
mapping. This is tricky:
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
index fce8bc7936603208f960d8296ca71fe72c5c3ca5..80d2c0aadab511379bdbaa4d08b6142e687e11eb 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -22,7 +22,7 @@ privileged operations. Currently there are two PAPR compliant hypervisors:
On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called
a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must
issue hypercalls to the hypervisor whenever it needs to perform an action
-that is hypervisor priviledged [3]_ or for other services managed by the
+that is hypervisor privileged [3]_ or for other services managed by the
hypervisor.
Hence a Hypercall (hcall) is essentially a request by the pseries guest
diff --git a/Documentation/powerpc/qe_firmware.rst b/Documentation/powerpc/qe_firmware.rst
index 42f5103140c9223725f22a03747b36622a36f198..a358f152b7e7e208535248f282e59beff7af3400 100644
--- a/Documentation/powerpc/qe_firmware.rst
+++ b/Documentation/powerpc/qe_firmware.rst
@@ -232,11 +232,11 @@ For example, to match the 8323, revision 1.0::
'extended_modes' is a bitfield that defines special functionality which has an
impact on the device drivers. Each bit has its own impact and has special
instructions for the driver associated with it. This field is stored in
-the QE library and available to any driver that calles qe_get_firmware_info().
+the QE library and available to any driver that calls qe_get_firmware_info().
'vtraps' is an array of 8 words that contain virtual trap values for each
virtual traps. As with 'extended_modes', this field is stored in the QE
-library and available to any driver that calles qe_get_firmware_info().
+library and available to any driver that calls qe_get_firmware_info().
'microcode' (type: struct qe_microcode):
For each RISC processor there is one 'microcode' structure. The first
diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/powerpc/vas-api.rst
index bdb50fed903e03379b4cfd4494d23139a658ef05..a9625a2fa0c6340b357e6693e4c5115d061cc8c6 100644
--- a/Documentation/powerpc/vas-api.rst
+++ b/Documentation/powerpc/vas-api.rst
@@ -46,7 +46,7 @@ request queue into the application's virtual address space.
The application can then submit one or more requests to the engine by
using copy/paste instructions and pasting the CRBs to the virtual address
(aka paste_address) returned by mmap(). User space can close the
-established connection or send window by closing the file descriptior
+established connection or send window by closing the file descriptor
(close(fd)) or upon the process exit.
Note that applications can send several requests with the same window or
@@ -240,7 +240,7 @@ issued. This signal returns with the following siginfo struct::
siginfo.si_signo = SIGSEGV;
siginfo.si_errno = EFAULT;
siginfo.si_code = SEGV_MAPERR;
- siginfo.si_addr = CSB adress;
+ siginfo.si_addr = CSB address;
In the case of multi-thread applications, NX send windows can be shared
across all threads. For example, a child thread can open a send window,
diff --git a/Documentation/process/botching-up-ioctls.rst b/Documentation/process/botching-up-ioctls.rst
index 9739b88463a5f091573f37527d27b1d2a3563410..a05e8401de1c713c003eec25b3d781f0eec4c6fc 100644
--- a/Documentation/process/botching-up-ioctls.rst
+++ b/Documentation/process/botching-up-ioctls.rst
@@ -208,7 +208,7 @@ Not every problem needs a new ioctl:
it's much quicker to push a driver-private interface than engaging in
lengthy discussions for a more generic solution. And occasionally doing a
private interface to spearhead a new concept is what's required. But in the
- end, once the generic interface comes around you'll end up maintainer two
+ end, once the generic interface comes around you'll end up maintaining two
interfaces. Indefinitely.
* Consider other interfaces than ioctls. A sysfs attribute is much better for
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index 26ead9d31c0152f49db59e727be9ac9ff7e5ffd2..8660493b91d0174a3a40574fcf256f38e377a58e 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -29,7 +29,7 @@ All documents are cataloged with the following fields: the document's
The documents on each section of this document are ordered by its
published date, from the newest to the oldest. The maintainer(s) should
- periodically retire resources as they become obsolte or outdated; with
+ periodically retire resources as they become obsolete or outdated; with
the exception of foundational books.
Docs at the Linux Kernel tree
diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst
index 19165ebd82baf8f3dcdff2861738bf2a99c811aa..67111304ae5f693015af92ea711d562efdf7807e 100644
--- a/Documentation/riscv/hwprobe.rst
+++ b/Documentation/riscv/hwprobe.rst
@@ -88,11 +88,11 @@ The following keys are defined:
always extremely slow.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported
- in hardware, but are slower than the cooresponding aligned accesses
+ in hardware, but are slower than the corresponding aligned accesses
sequences.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported
- in hardware and are faster than the cooresponding aligned accesses
+ in hardware and are faster than the corresponding aligned accesses
sequences.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
diff --git a/Documentation/riscv/vector.rst b/Documentation/riscv/vector.rst
index 165b7ed0ac4f1cd45e751154826db1426d992ab5..75dd88a62e1d843a7984e55ec90f18ca3c49dc27 100644
--- a/Documentation/riscv/vector.rst
+++ b/Documentation/riscv/vector.rst
@@ -13,7 +13,7 @@ order to support the use of the RISC-V Vector Extension.
Two new prctl() calls are added to allow programs to manage the enablement
status for the use of Vector in userspace. The intended usage guideline for
these interfaces is to give init systems a way to modify the availability of V
-for processes running under its domain. Calling thess interfaces is not
+for processes running under its domain. Calling these interfaces is not
recommended in libraries routines because libraries should not override policies
configured from the parant process. Also, users must noted that these interfaces
are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst
index bb3f4c4e288563dc1ca850b8f7f86b7b7347a56e..929ee1c1c940072af235b233c9343e38e563be4e 100644
--- a/Documentation/s390/vfio-ap.rst
+++ b/Documentation/s390/vfio-ap.rst
@@ -422,7 +422,7 @@ Configure the guest's AP resources
Configuring the AP resources for a KVM guest will be performed when the
VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier
function is called when userspace connects to KVM. The guest's AP resources are
-configured via it's APCB by:
+configured via its APCB by:
* Setting the bits in the APM corresponding to the APIDs assigned to the
vfio_ap mediated device via its 'assign_adapter' interface.
diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst
index f166b182ff959b023885831b864b9ab3b646db06..41ed2ceafc92ee1b09148913e50c762c16542663 100644
--- a/Documentation/scheduler/sched-bwc.rst
+++ b/Documentation/scheduler/sched-bwc.rst
@@ -186,7 +186,7 @@ average usage, albeit over a longer time window than a single period. This
also limits the burst ability to no more than 1ms per cpu. This provides
better more predictable user experience for highly threaded applications with
small quota limits on high core count machines. It also eliminates the
-propensity to throttle these applications while simultanously using less than
+propensity to throttle these applications while simultaneously using less than
quota amounts of cpu. Another way to say this, is that by allowing the unused
portion of a slice to remain valid across periods we have decreased the
possibility of wastefully expiring quota on cpu-local silos that don't need a
diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst
index 8fbce5e767d98066fb4fd3b1e1cf78ba2e6f1bc6..fc853c8cc346df35b90ee90dbd0501b6ac80cfd8 100644
--- a/Documentation/scheduler/sched-energy.rst
+++ b/Documentation/scheduler/sched-energy.rst
@@ -82,7 +82,7 @@ through the arch_scale_cpu_capacity() callback.
The rest of platform knowledge used by EAS is directly read from the Energy
Model (EM) framework. The EM of a platform is composed of a power cost table
per 'performance domain' in the system (see Documentation/power/energy-model.rst
-for futher details about performance domains).
+for further details about performance domains).
The scheduler manages references to the EM objects in the topology code when the
scheduling domains are built, or re-built. For each root domain (rd), the
@@ -281,7 +281,7 @@ mechanism called 'over-utilization'.
From a general standpoint, the use-cases where EAS can help the most are those
involving a light/medium CPU utilization. Whenever long CPU-bound tasks are
being run, they will require all of the available CPU capacity, and there isn't
-much that can be done by the scheduler to save energy without severly harming
+much that can be done by the scheduler to save energy without severely harming
throughput. In order to avoid hurting performance with EAS, CPUs are flagged as
'over-utilized' as soon as they are used at more than 80% of their compute
capacity. As long as no CPUs are over-utilized in a root domain, load balancing
diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc
index d16e6874d22381fc120a524da4c78d2a2944fdbf..ccc48b8359bf3860aa5d572fdeddaa3587ccf671 100644
--- a/Documentation/scsi/ChangeLog.lpfc
+++ b/Documentation/scsi/ChangeLog.lpfc
@@ -427,7 +427,7 @@ Changes from 20041207 to 20041213
* Changed version number to 8.0.17
* Fix sparse warnings by adding __iomem markers to lpfc_compat.h.
* Fix some sparse warnings -- 0 used as NULL pointer.
- * Make sure there's a space between every if and it's (.
+ * Make sure there's a space between every if and its (.
* Fix some overly long lines and make sure hard tabs are used for
indentation.
* Remove all trailing whitespace.
diff --git a/Documentation/security/digsig.rst b/Documentation/security/digsig.rst
index f6a8902d3ef7734a1d93c64136cde40e728730d1..de035f282196b547f3a4c43b08ca8a14cceeebf4 100644
--- a/Documentation/security/digsig.rst
+++ b/Documentation/security/digsig.rst
@@ -82,7 +82,7 @@ The signing and key management utilities evm-utils provide functionality
to generate signatures, to load keys into the kernel keyring.
Keys can be in PEM or converted to the kernel format.
When the key is added to the kernel keyring, the keyid defines the name
-of the key: 5D2B05FC633EE3E8 in the example bellow.
+of the key: 5D2B05FC633EE3E8 in the example below.
Here is example output of the keyctl utility::
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 811b905b56bf7fc9455f351b90af2434f72db9a3..326b8a973828983d513ffa0e9586efc74f5966a1 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -869,7 +869,7 @@ The keyctl syscall functions are:
- ``char *hashname`` specifies the NUL terminated string identifying
the hash used from the kernel crypto API and applied for the KDF
- operation. The KDF implemenation complies with SP800-56A as well
+ operation. The KDF implementation complies with SP800-56A as well
as with SP800-108 (the counter KDF).
- ``char *otherinfo`` specifies the OtherInfo data as documented in
diff --git a/Documentation/security/secrets/coco.rst b/Documentation/security/secrets/coco.rst
index 087e2d1ae38b682e11b197653b1dc5b94f367b36..a1210db8ec07f8cfaa03acee06d51ad23aa73a83 100644
--- a/Documentation/security/secrets/coco.rst
+++ b/Documentation/security/secrets/coco.rst
@@ -34,7 +34,7 @@ be use it for its own purposes.
During the VM's launch, the virtual machine manager may inject a secret to that
area. In AMD SEV and SEV-ES this is performed using the
-``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected
+``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The structure of the injected
Guest Owner secret data should be a GUIDed table of secret values; the binary
format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under
"Structure of the EFI secret area".
diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
index ca8ac9e59ded4bd4bbaa7534874ceb7b08228236..a99716bf44b5538d02e00278eb569bc04228eb81 100644
--- a/Documentation/sphinx/cdomain.py
+++ b/Documentation/sphinx/cdomain.py
@@ -178,7 +178,7 @@ class CObject(Base_CObject):
if len(arglist[0].split(" ")) > 1:
return False
- # This is a function-like macro, it's arguments are typeless!
+ # This is a function-like macro, its arguments are typeless!
signode += addnodes.desc_name(fullname, fullname)
paramlist = addnodes.desc_parameterlist()
signode += paramlist
diff --git a/Documentation/spi/spi-lm70llp.rst b/Documentation/spi/spi-lm70llp.rst
index 0144e12d95bb1990677933c542326a610dcc62ce..2f20e5b405e66afba0ff50b233abf659884fe2a4 100644
--- a/Documentation/spi/spi-lm70llp.rst
+++ b/Documentation/spi/spi-lm70llp.rst
@@ -69,7 +69,7 @@ Interpreting this circuit, when the LM70 SI/O line is High (or tristate
and not grounded by the host via D7), the transistor conducts and switches
the collector to zero, which is reflected on pin 13 of the DB25 parport
connector. When SI/O is Low (driven by the LM70 or the host) on the other
-hand, the transistor is cut off and the voltage tied to it's collector is
+hand, the transistor is cut off and the voltage tied to its collector is
reflected on pin 13 as a High level.
So: the getmiso inline routine in this driver takes this fact into account,
diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst
index 1b7cf4e3eafe7d194267cb1805a1fde4f41aaff9..ab6cb60c90839de6d3ce614d6a0a3236b3e39730 100644
--- a/Documentation/tools/rtla/rtla-timerlat-top.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-top.rst
@@ -117,7 +117,7 @@ syscall in a btrfs file system.
The raw trace is saved in the **timerlat_trace.txt** file for further analysis.
Note that **rtla timerlat** was dispatched without changing *timerlat* tracer
-threads' priority. That is generally not needed because these threads hava
+threads' priority. That is generally not needed because these threads have
priority *FIFO:95* by default, which is a common priority used by real-time
kernel developers to analyze scheduling delays.
diff --git a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst
index 70e34b8c81c1c82486ce7dce0e88699d6eaa90bc..89ac4e6fc96fd5aaf4e82d55968fa346fee56d31 100644
--- a/Documentation/trace/coresight/coresight-etm4x-reference.rst
+++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst
@@ -675,7 +675,7 @@ Bit assignments shown below:-
reconstructed using only conditional branches.
There is currently no support in Perf for supplying modified binaries to the decoder, so this
- feature is only inteded to be used for debugging purposes or with a 3rd party tool.
+ feature is only intended to be used for debugging purposes or with a 3rd party tool.
Choosing this option will result in a significant increase in the amount of trace generated -
possible danger of overflows, or fewer instructions covered. Note, that this option also
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index f5fcb8e1218f6979f50445ceed9f5de179e86f99..15f78e772384b675fa6a6df093cc64fa0c020939 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -915,7 +915,7 @@ functions can be used.
To create a kprobe event, an empty or partially empty kprobe event
should first be created using kprobe_event_gen_cmd_start(). The name
-of the event and the probe location should be specfied along with one
+of the event and the probe location should be specified along with one
or args each representing a probe field should be supplied to this
function. Before calling kprobe_event_gen_cmd_start(), the user
should create and initialize a dynevent_cmd object using
@@ -995,7 +995,7 @@ The basic idea is simple and amounts to providing a general-purpose
layer that can be used to generate trace event commands. The
generated command strings can then be passed to the command-parsing
and event creation code that already exists in the trace event
-subystem for creating the corresponding trace events.
+subsystem for creating the corresponding trace events.
In a nutshell, the way it works is that the higher-level interface
code creates a struct dynevent_cmd object, then uses a couple
@@ -1068,7 +1068,7 @@ to add an operator between the pair (here none) and a separator to be
appended onto the end of the arg pair (here ';').
There's also a dynevent_str_add() function that can be used to simply
-add a string as-is, with no spaces, delimeters, or arg check.
+add a string as-is, with no spaces, delimiters, or arg check.
Any number of dynevent_*_add() calls can be made to build up the string
(until its length surpasses cmd->maxlen). When all the arguments have
diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst
index 40dd2fbce861e76b95d1a188ad56fb1684e43986..7a895514b53794415901c6452169d379bdded30d 100644
--- a/Documentation/trace/fprobe.rst
+++ b/Documentation/trace/fprobe.rst
@@ -113,7 +113,7 @@ If the entry callback function returns !0, the corresponding exit callback will
the instruction pointer of @regs may be different from the @entry_ip
in the entry_handler. If you need traced instruction pointer, you need
to use @entry_ip. On the other hand, in the exit_handler, the instruction
- pointer of @regs is set to the currect return address.
+ pointer of @regs is set to the current return address.
@entry_data
This is a local storage to share the data between entry and exit handlers.
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index f606c5bd1c0d00b55907175b6b00d0bf82a14058..23572f6697c0abee8c69d63d2212ca5f0572832f 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -2725,7 +2725,7 @@ It is default disabled.
The return value of each traced function can be displayed after
an equal sign "=". When encountering system call failures, it
-can be verfy helpful to quickly locate the function that first
+can be very helpful to quickly locate the function that first
returns an error code.
- hide: echo nofuncgraph-retval > trace_options
diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst
index de94b499b0bcdf5f35c7f53967db535677409489..11b749c2a8bd9bccae8d7193b9887d742b4a05ea 100644
--- a/Documentation/trace/hwlat_detector.rst
+++ b/Documentation/trace/hwlat_detector.rst
@@ -14,7 +14,7 @@ originally written for use by the "RT" patch since the Real Time
kernel is highly latency sensitive.
SMIs are not serviced by the Linux kernel, which means that it does not
-even know that they are occuring. SMIs are instead set up by BIOS code
+even know that they are occurring. SMIs are instead set up by BIOS code
and are serviced by BIOS code, usually for "critical" events such as
management of thermal sensors and fans. Sometimes though, SMIs are used for
other tasks and those tasks can spend an inordinate amount of time in the
diff --git a/Documentation/trace/rv/da_monitor_synthesis.rst b/Documentation/trace/rv/da_monitor_synthesis.rst
index 0dbdcd1e62b907918b0124a8a2215a85eb866d9c..0a92729c8a9bab1d2b89f4877d6fdd1064d6862f 100644
--- a/Documentation/trace/rv/da_monitor_synthesis.rst
+++ b/Documentation/trace/rv/da_monitor_synthesis.rst
@@ -1,7 +1,7 @@
Deterministic Automata Monitor Synthesis
========================================
-The starting point for the application of runtime verification (RV) technics
+The starting point for the application of runtime verification (RV) techniques
is the *specification* or *modeling* of the desired (or undesired) behavior
of the system under scrutiny.
diff --git a/Documentation/trace/rv/monitor_wwnr.rst b/Documentation/trace/rv/monitor_wwnr.rst
index 80f1777b85aacbbed31b8ccbe11c768c2b40b41c..9f739030f8269405f76bcc78a66fdbf9c5e68bd8 100644
--- a/Documentation/trace/rv/monitor_wwnr.rst
+++ b/Documentation/trace/rv/monitor_wwnr.rst
@@ -26,7 +26,7 @@ definition::
| running | -+
+-------------+
-This model is borken, the reason is that a task can be running
+This model is broken, the reason is that a task can be running
in the processor without being set as RUNNABLE. Think about a
task about to sleep::
diff --git a/Documentation/trace/rv/runtime-verification.rst b/Documentation/trace/rv/runtime-verification.rst
index c46b6149470ef1854c66a5c47ad8b9ff90b31a16..dae78dfa7cdc37f05083716063cf05d7eacc4723 100644
--- a/Documentation/trace/rv/runtime-verification.rst
+++ b/Documentation/trace/rv/runtime-verification.rst
@@ -31,7 +31,7 @@ In Linux terms, the runtime verification monitors are encapsulated inside the
*RV monitor* abstraction. A *RV monitor* includes a reference model of the
system, a set of instances of the monitor (per-cpu monitor, per-task monitor,
and so on), and the helper functions that glue the monitor to the system via
-trace, as depicted bellow::
+trace, as depicted below::
Linux +---- RV Monitor ----------------------------------+ Formal
Realm | | Realm
diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst
index 122d15572fd535eccc75952a2b7d573eb8b8e671..01f6a780fb044e1ccbd989c2cb24c05912810230 100644
--- a/Documentation/trace/uprobetracer.rst
+++ b/Documentation/trace/uprobetracer.rst
@@ -55,7 +55,7 @@ Synopsis of uprobe_tracer
(\*1) only for return probe.
(\*2) this is useful for fetching a field of data structures.
- (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe
+ (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe
events can access only user-space memory.
Types
diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst
index e7b07313550a3f60e3fe26cad1f2028cd4dc6eb1..f9530d0ac5d312aa75420a4160e8e901c573b66d 100644
--- a/Documentation/trace/user_events.rst
+++ b/Documentation/trace/user_events.rst
@@ -93,7 +93,7 @@ or perf record -e user_events:[name] when attaching/recording.
**NOTE:** The event subsystem name by default is "user_events". Callers should
not assume it will always be "user_events". Operators reserve the right in the
-future to change the subsystem name per-process to accomodate event isolation.
+future to change the subsystem name per-process to accommodate event isolation.
Command Format
^^^^^^^^^^^^^^
diff --git a/Documentation/usb/gadget_uvc.rst b/Documentation/usb/gadget_uvc.rst
index 62bd81ba3dd1fe6f7426eb58baac2e62360fdc0d..80a1f031b59328d972d85c7ff55834a0c78611df 100644
--- a/Documentation/usb/gadget_uvc.rst
+++ b/Documentation/usb/gadget_uvc.rst
@@ -168,7 +168,7 @@ Header linking
The UVC specification requires that Format and Frame descriptors be preceded by
Headers detailing things such as the number and cumulative size of the different
-Format descriptors that follow. This and similar operations are acheived in
+Format descriptors that follow. This and similar operations are achieved in
configfs by linking between the configfs item representing the header and the
config items representing those other descriptors, in this manner:
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 81e60f4002c8f12f05f9ecb4e681d62d22e3f91a..786127b1e206a3ebba888935646f9f6714e2ad10 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -3293,7 +3293,7 @@ AV1 Frame Restoration Type.
.. c:type:: v4l2_av1_loop_restoration
-AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params
+AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params
semantics" of :ref:`av1`.
.. cssclass:: longtable
diff --git a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
index 541836074f949278b11cf900f8aa7a0b18fa4d3e..0686413b16b27d2178204e819bcb877b2ff0b7b1 100644
--- a/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
+++ b/Documentation/userspace-api/media/v4l/metafmt-d4xx.rst
@@ -237,7 +237,7 @@ Fish Eye sensor: ::
camera projectors. As we have another field for "Laser Power" we introduced
"LED Power" for extra emitter.
-The "Laser mode" __u32 fiels has been split into: ::
+The "Laser mode" __u32 fields has been split into: ::
1 __u8 Emitter mode
2 __u8 RFU byte
3 __u16 LED Power
diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst
index 0955e9f203d3b9d4cf2a8984bde53bc573bfa4c8..af94e71761ec5b0a68880e6902bbdf2b79aac058 100644
--- a/Documentation/userspace-api/netlink/intro.rst
+++ b/Documentation/userspace-api/netlink/intro.rst
@@ -615,7 +615,7 @@ and ``SET``. Each object can handle all or some of those requests
is defined by the 2 lowest bits of the message type, so commands for
new objects would always be allocated with a stride of 4.
-Each object would also have it's own fixed metadata shared by all request
+Each object would also have its own fixed metadata shared by all request
types (e.g. struct ifinfomsg for netdev requests, struct ifaddrmsg for address
requests, struct tcmsg for qdisc requests).
diff --git a/Documentation/virt/hyperv/clocks.rst b/Documentation/virt/hyperv/clocks.rst
index 2da2879fad52312f57d1d01f4807292db4ca754d..a56f4837d44336a2c953e72205bcc1ab5052f61c 100644
--- a/Documentation/virt/hyperv/clocks.rst
+++ b/Documentation/virt/hyperv/clocks.rst
@@ -60,7 +60,7 @@ vDSO, and gettimeofday() and related system calls can execute
entirely in user space. The vDSO is implemented by mapping the
shared page with scale and offset values into user space. User
space code performs the same algorithm of reading the TSC and
-appying the scale and offset to get the constant 10 MHz clock.
+applying the scale and offset to get the constant 10 MHz clock.
Linux clockevents are based on Hyper-V synthetic timer 0. While
Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index c0ddd3035462bd8ad99bb4147381b79399cff807..73db30cb60fbd9daa391e7a8540545f330b5f757 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -578,7 +578,7 @@ This is an asynchronous vcpu ioctl and can be invoked from any thread.
RISC-V:
^^^^^^^
-Queues an external interrupt to be injected into the virutal CPU. This ioctl
+Queues an external interrupt to be injected into the virtual CPU. This ioctl
is overloaded with 2 different irq values:
a) KVM_INTERRUPT_SET
@@ -2722,7 +2722,7 @@ The isa config register can be read anytime but can only be written before
a Guest VCPU runs. It will have ISA feature bits matching underlying host
set by default.
-RISC-V core registers represent the general excution state of a Guest VCPU
+RISC-V core registers represent the general execution state of a Guest VCPU
and it has the following id bit patterns::
0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host)
@@ -5232,7 +5232,7 @@ KVM_PV_DISABLE
Deregister the VM from the Ultravisor and reclaim the memory that had
been donated to the Ultravisor, making it usable by the kernel again.
All registered VCPUs are converted back to non-protected ones. If a
- previous protected VM had been prepared for asynchonous teardown with
+ previous protected VM had been prepared for asynchronous teardown with
KVM_PV_ASYNC_CLEANUP_PREPARE and not subsequently torn down with
KVM_PV_ASYNC_CLEANUP_PERFORM, it will be torn down in this call
together with the current protected VM.
@@ -5692,7 +5692,7 @@ flags values for ``kvm_sregs2``:
``KVM_SREGS2_FLAGS_PDPTRS_VALID``
- Indicates thats the struct contain valid PDPTR values.
+ Indicates that the struct contains valid PDPTR values.
4.132 KVM_SET_SREGS2
@@ -6263,7 +6263,7 @@ to the byte array.
It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or
``KVM_EXIT_MMIO`` (all except s390) to implement functionality that
-requires a guest to interact with host userpace.
+requires a guest to interact with host userspace.
.. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO.
@@ -6336,7 +6336,7 @@ s390 specific.
} s390_ucontrol;
s390 specific. A page fault has occurred for a user controlled virtual
-machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be
+machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be
resolved by the kernel.
The program code and the translation exception code that were placed
in the cpu's lowcore are presented here as defined by the z Architecture
@@ -7510,7 +7510,7 @@ APIC/MSRs/etc).
attribute is not supported by KVM.
KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or
-more priveleged enclave attributes. args[0] must hold a file handle to a valid
+more privileged enclave attributes. args[0] must hold a file handle to a valid
SGX attribute file corresponding to an attribute that is supported/restricted
by KVM (currently only PROVISIONKEY).
@@ -7928,7 +7928,7 @@ writing to the respective MSRs.
This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its
value is used to denote the target vcpu for a SynIC interrupt. For
-compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this
+compatibility, KVM initializes this msr to KVM's internal vcpu index. When this
capability is absent, userspace can still query this msr's value.
8.13 KVM_CAP_S390_AIS_MIGRATION
@@ -8118,10 +8118,10 @@ regardless of what has actually been exposed through the CPUID leaf.
:Parameters: args[0] - size of the dirty log ring
KVM is capable of tracking dirty memory using ring buffers that are
-mmaped into userspace; there is one dirty ring per vcpu.
+mmapped into userspace; there is one dirty ring per vcpu.
The dirty ring is available to userspace as an array of
-``struct kvm_dirty_gfn``. Each dirty entry it's defined as::
+``struct kvm_dirty_gfn``. Each dirty entry is defined as::
struct kvm_dirty_gfn {
__u32 flags;
@@ -8160,7 +8160,7 @@ state machine for the entry is as follows::
| |
+------------------------------------------+
-To harvest the dirty pages, userspace accesses the mmaped ring buffer
+To harvest the dirty pages, userspace accesses the mmapped ring buffer
to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage
the RESET bit must be cleared), then it means this GFN is a dirty GFN.
The userspace should harvest this GFN and mark the flags from state
@@ -8286,7 +8286,7 @@ the KVM_XEN_ATTR_TYPE_RUNSTATE_UPDATE_FLAG attribute in the KVM_XEN_SET_ATTR
and KVM_XEN_GET_ATTR ioctls. This controls whether KVM will set the
XEN_RUNSTATE_UPDATE flag in guest memory mapped vcpu_runstate_info during
updates of the runstate information. Note that versions of KVM which support
-the RUNSTATE feature above, but not thie RUNSTATE_UPDATE_FLAG feature, will
+the RUNSTATE feature above, but not the RUNSTATE_UPDATE_FLAG feature, will
always set the XEN_RUNSTATE_UPDATE flag when updating the guest structure,
which is perhaps counterintuitive. When this flag is advertised, KVM will
behave more correctly, not using the XEN_RUNSTATE_UPDATE flag until/unless
@@ -8335,7 +8335,7 @@ Architectures: x86
When enabled, KVM will disable emulated Hyper-V features provided to the
guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all
-currently implmented Hyper-V features are provided unconditionally when
+currently implemented Hyper-V features are provided unconditionally when
Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001)
leaf.
diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst
index 9d726e60ec472a6eb3fb0c9453932954e604e6fb..a4d39fa1b0834b090318250db3b670b0b3174259 100644
--- a/Documentation/virt/kvm/devices/vm.rst
+++ b/Documentation/virt/kvm/devices/vm.rst
@@ -92,7 +92,7 @@ Allows user space to retrieve or request to change cpu related information for a
KVM does not enforce or limit the cpu model data in any form. Take the information
retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration
setups. Instruction interceptions triggered by additionally set facility bits that
-are not handled by KVM need to by imlemented in the VM driver code.
+are not handled by KVM need to by implemented in the VM driver code.
:Parameters: address of buffer to store/set the processor related cpu
data of type struct kvm_s390_vm_cpu_processor*.
diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst
index 8b5e7b40bdf858397bf77b515e2ae57cc6612b4b..a07e16d34006e42ef4d2812472fc0277fac46d09 100644
--- a/Documentation/virt/kvm/devices/xive.rst
+++ b/Documentation/virt/kvm/devices/xive.rst
@@ -50,7 +50,7 @@ the legacy interrupt mode, referred as XICS (POWER7/8).
When a device is passed-through into the guest, the source
interrupts are from a different HW controller (PHB4) and the ESB
- pages exposed to the guest should accommadate this change.
+ pages exposed to the guest should accommodate this change.
The passthru_irq helpers, kvmppc_xive_set_mapped() and
kvmppc_xive_clr_mapped() are called when the device HW irqs are
diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/halt-polling.rst
index 4f1a1b23d99cb0e9c9f4866760d34f86f397eef8..c82a04b709b40fa26eabab38519ea96b4745dac5 100644
--- a/Documentation/virt/kvm/halt-polling.rst
+++ b/Documentation/virt/kvm/halt-polling.rst
@@ -14,7 +14,7 @@ before giving up the cpu to the scheduler in order to let something else run.
Polling provides a latency advantage in cases where the guest can be run again
very quickly by at least saving us a trip through the scheduler, normally on
the order of a few micro-seconds, although performance benefits are workload
-dependant. In the event that no wakeup source arrives during the polling
+dependent. In the event that no wakeup source arrives during the polling
interval or some other task on the runqueue is runnable the scheduler is
invoked. Thus halt polling is especially useful on workloads with very short
wakeup periods where the time spent halt polling is minimised and the time
diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst
index 26f62034b6f3edc53de08eaa271c376f329211d4..d47595b33fcf19fe366c88c61361527aa3dd6fe3 100644
--- a/Documentation/virt/kvm/x86/mmu.rst
+++ b/Documentation/virt/kvm/x86/mmu.rst
@@ -245,7 +245,7 @@ Shadow pages contain the following information:
unsynchronized children).
unsync_child_bitmap:
A bitmap indicating which sptes in spt point (directly or indirectly) at
- pages that may be unsynchronized. Used to quickly locate all unsychronized
+ pages that may be unsynchronized. Used to quickly locate all unsynchronized
pages reachable from a given page.
clear_spte_count:
Only present on 32-bit hosts, where a 64-bit spte cannot be written
diff --git a/Documentation/virt/kvm/x86/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst
index 71136fe1723bb5949e07f5c20d1027d5f8882c9e..87326413d5c7dbd3659483a31216693b4429f06d 100644
--- a/Documentation/virt/kvm/x86/running-nested-guests.rst
+++ b/Documentation/virt/kvm/x86/running-nested-guests.rst
@@ -169,7 +169,7 @@ Enabling "nested" (s390x)
$ modprobe kvm nested=1
.. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive
- with the ``nested`` paramter — i.e. to be able to enable
+ with the ``nested`` parameter — i.e. to be able to enable
``nested``, the ``hpage`` parameter *must* be disabled.
2. The guest hypervisor (L1) must be provided with the ``sie`` CPU
diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
index af2a9742969213646d2c090dc3ec922652665a5a..d1cfe415e4c47545a2da4e24ef002d77427ab4b4 100644
--- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
+++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
@@ -1224,7 +1224,7 @@ between a driver and the host at the UML command line is OK
security-wise. Allowing it as a loadable module parameter
isn't.
-If such functionality is desireable for a particular application
+If such functionality is desirable for a particular application
(e.g. loading BPF "firmware" for raw socket network transports),
it should be off by default and should be explicitly turned on
as a command line parameter at startup.
diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst
index 758dadba84f670b71160299394f522a655415237..6aec04dd0905bd0c00ca5e55ab8593f007f55358 100644
--- a/Documentation/w1/slaves/w1_therm.rst
+++ b/Documentation/w1/slaves/w1_therm.rst
@@ -58,7 +58,7 @@ A strong pullup will be applied during the conversion if required.
``conv_time`` is used to get current conversion time (read), and
adjust it (write). A temperature conversion time depends on the device type and
-it's current resolution. Default conversion time is set by the driver according
+its current resolution. Default conversion time is set by the driver according
to the device datasheet. A conversion time for many original device clones
deviate from datasheet specs. There are three options: 1) manually set the
correct conversion time by writing a value in milliseconds to ``conv_time``; 2)
diff --git a/Documentation/w1/w1-generic.rst b/Documentation/w1/w1-generic.rst
index 99255b6d0e5395616bfd8c91b26f27e6004f8adb..96a042585fcea5ff211f5fbc24b5d2287345e4bd 100644
--- a/Documentation/w1/w1-generic.rst
+++ b/Documentation/w1/w1-generic.rst
@@ -101,7 +101,7 @@ w1_master_search (rw) the number of searches left to do,
w1_master_slave_count (ro) the number of slaves found
w1_master_slaves (ro) the names of the slaves, one per line
w1_master_timeout (ro) the delay in seconds between searches
-w1_master_timeout_us (ro) the delay in microseconds beetwen searches
+w1_master_timeout_us (ro) the delay in microseconds between searches
========================= =====================================================
If you have a w1 bus that never changes (you don't add or remove devices),
diff --git a/Documentation/w1/w1-netlink.rst b/Documentation/w1/w1-netlink.rst
index aaa13243a5e43ddbacc9a7c42afa67e4bcb985d4..be4f7b82dcb435ed45e027b601042de67fd531f6 100644
--- a/Documentation/w1/w1-netlink.rst
+++ b/Documentation/w1/w1-netlink.rst
@@ -66,7 +66,7 @@ Each connector message can include one or more w1_netlink_msg with
zero or more attached w1_netlink_cmd messages.
For event messages there are no w1_netlink_cmd embedded structures,
-only connector header and w1_netlink_msg strucutre with "len" field
+only connector header and w1_netlink_msg structure with "len" field
being zero and filled type (one of event types) and id:
either 8 bytes of slave unique id in host order,
or master's id, which is assigned to bus master device
diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst
index baf44e986b07c63bcf80c4ff3bca509779ee7233..243231fe4c0a3f0f11aba902fcd96232d6f6c421 100644
--- a/Documentation/watchdog/watchdog-kernel-api.rst
+++ b/Documentation/watchdog/watchdog-kernel-api.rst
@@ -77,7 +77,7 @@ It contains following fields:
* groups: List of sysfs attribute groups to create when creating the watchdog
device.
* info: a pointer to a watchdog_info structure. This structure gives some
- additional information about the watchdog timer itself. (Like it's unique name)
+ additional information about the watchdog timer itself. (Like its unique name)
* ops: a pointer to the list of watchdog operations that the watchdog supports.
* gov: a pointer to the assigned watchdog device pretimeout governor or NULL.
* timeout: the watchdog timer's timeout value (in seconds).
diff --git a/Documentation/wmi/devices/dell-wmi-ddv.rst b/Documentation/wmi/devices/dell-wmi-ddv.rst
index d8aa64e9c827cb30b76976c22467706165a976c2..30313977bd2522eb811782aca6639788354baa4a 100644
--- a/Documentation/wmi/devices/dell-wmi-ddv.rst
+++ b/Documentation/wmi/devices/dell-wmi-ddv.rst
@@ -185,7 +185,7 @@ Performs an analysis of the battery and returns a status code:
WMI method BatteryeRawAnalytics()
---------------------------------
-Returns a buffer usually containg 12 blocks of analytics data.
+Returns a buffer usually containing 12 blocks of analytics data.
Those blocks contain:
- block number starting with 0 (u8)
- 31 bytes of unknown data
@@ -217,7 +217,7 @@ Returns the WMI interface version as an u32.
WMI method FanSensorInformation()
---------------------------------
-Returns a buffer containg fan sensor entries, terminated
+Returns a buffer containing fan sensor entries, terminated
with a single ``0xff``.
Those entries contain: