Re: [PATCH] Minor documentation fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025/7/23 03:11, Bojanala Hithashri wrote:
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.

lgtm


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

--
Thanks,
       Kunwu Chan.





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux