Signed-off-by: Bojanala Hithashri <bojanalahithashri@xxxxxxxxx>
---
Documentation/block/data-integrity.rst | 2 +-
Documentation/bpf/standardization/instruction-set.rst | 2 +-
Documentation/cdrom/cdrom-standard.rst | 2 +-
Documentation/trace/boottime-trace.rst | 2 +-
Documentation/trace/events.rst | 2 +-
Documentation/trace/fprobe.rst | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/block/data-integrity.rst b/Documentation/block/data-integrity.rst
index 99905e880a0e..b7b10c8abbcc 100644
--- a/Documentation/block/data-integrity.rst
+++ b/Documentation/block/data-integrity.rst
@@ -154,7 +154,7 @@ bio_free() will automatically free the bip.
----------------
Block devices can set up the integrity information in the integrity
-sub-struture of the queue_limits structure.
+sub-structure of the queue_limits structure.
Layered block devices will need to pick a profile that's appropriate
for all subdevices. queue_limits_stack_integrity() can help with that. DM
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index fbe975585236..746eb3c421eb 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -350,7 +350,7 @@ Underflow and overflow are allowed during arithmetic operations, meaning
the 64-bit or 32-bit value will wrap. If BPF program execution would
result in division by zero, the destination register is instead set to zero.
Otherwise, for ``ALU64``, if execution would result in ``LLONG_MIN``
-dividing -1, the desination register is instead set to ``LLONG_MIN``. For
+dividing -1, the destination register is instead set to ``LLONG_MIN``. For
``ALU``, if execution would result in ``INT_MIN`` dividing -1, the
desination register is instead set to ``INT_MIN``.
diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst
index 6c1303cff159..22dc6db04a14 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -89,7 +89,7 @@ CD-ROM devices behave **exactly** the same (insofar as the underlying
hardware will allow).
The goal of the Uniform CD-ROM Driver is **not** to alienate driver developers
-whohave not yet taken steps to support this effort. The goal of Uniform CD-ROM
+who have not yet taken steps to support this effort. The goal of Uniform CD-ROM
Driver is simply to give people writing application programs for CD-ROM drives
**one** Linux CD-ROM interface with consistent behavior for all
CD-ROM devices. In addition, this also provides a consistent interface
diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst
index d594597201fd..62646130e1a2 100644
--- a/Documentation/trace/boottime-trace.rst
+++ b/Documentation/trace/boottime-trace.rst
@@ -198,7 +198,7 @@ Most of the subsystems and architecture dependent drivers will be initialized
after that (arch_initcall or subsys_initcall). Thus, you can trace those with
boot-time tracing.
If you want to trace events before core_initcall, you can use the options
-starting with ``kernel``. Some of them will be enabled eariler than the initcall
+starting with ``kernel``. Some of them will be enabled earlier than the initcall
processing (for example,. ``kernel.ftrace=function`` and ``kernel.trace_event``
will start before the initcall.)
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 2d88a2acacc0..c35f640e1cdc 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -629,7 +629,7 @@ following:
- tracing synthetic events from in-kernel code
- the low-level "dynevent_cmd" API
-7.1 Dyamically creating synthetic event definitions
+7.1 Dynamically creating synthetic event definitions
---------------------------------------------------
There are a couple ways to create a new synthetic event from a kernel
diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst
index 71cd40472d36..d632073408d6 100644
--- a/Documentation/trace/fprobe.rst
+++ b/Documentation/trace/fprobe.rst
@@ -118,7 +118,7 @@ will be cancelled.
@fregs
This is the `ftrace_regs` data structure at the entry and exit. This
includes the function parameters, or the return values. So user can
- access thos values via appropriate `ftrace_regs_*` APIs.
+ access those values via appropriate `ftrace_regs_*` APIs.
@entry_data
This is a local storage to share the data between entry and exit handlers.
--
2.47.0
