[PATCH] Minor documentation fixes

[PATCH] Minor documentation fixes

[Bojanala Hithashri]

Signed-off-by: Bojanala Hithashri <bojanalahithashri@gmail.com>
---
 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

Re: [PATCH] Minor documentation fixes

[Kunwu Chan]

On 2025/7/23 03:11, Bojanala Hithashri wrote:
> Signed-off-by: Bojanala Hithashri <bojanalahithashri@gmail.com>
> ---
>   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.

lgtm


Reviewed-by: Kunwu Chan <kunwu.chan@linux.dev>

-- 
Thanks,
        Kunwu Chan.