From: Ranganath V N <vnranganath.20@gmail.com>
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
brauner@kernel.org, djwong@kernel.org, corbet@lwn.net,
pbonzini@redhat.com, laurent.pinchart@ideasonboard.com,
vnranganath.20@gmail.com, devicetree@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
kvm@vger.kernel.org
Subject: [PATCH] Documentation: Fix spelling mistakes
Date: Wed, 3 Sep 2025 01:08:22 +0530 [thread overview]
Message-ID: <20250902193822.6349-1-vnranganath.20@gmail.com> (raw)
Corrected a few spelling mistakes to improve the readability.
Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
---
Documentation/devicetree/bindings/submitting-patches.rst | 2 +-
Documentation/filesystems/iomap/operations.rst | 2 +-
Documentation/virt/kvm/review-checklist.rst | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst
index 46d0b036c97e..191085b0d5e8 100644
--- a/Documentation/devicetree/bindings/submitting-patches.rst
+++ b/Documentation/devicetree/bindings/submitting-patches.rst
@@ -66,7 +66,7 @@ I. For patch submitters
any DTS patches, regardless whether using existing or new bindings, should
be placed at the end of patchset to indicate no dependency of drivers on
the DTS. DTS will be anyway applied through separate tree or branch, so
- different order would indicate the serie is non-bisectable.
+ different order would indicate the series is non-bisectable.
If a driver subsystem maintainer prefers to apply entire set, instead of
their relevant portion of patchset, please split the DTS patches into
diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst
index 067ed8e14ef3..387fd9cc72ca 100644
--- a/Documentation/filesystems/iomap/operations.rst
+++ b/Documentation/filesystems/iomap/operations.rst
@@ -321,7 +321,7 @@ The fields are as follows:
- ``writeback_submit``: Submit the previous built writeback context.
Block based file systems should use the iomap_ioend_writeback_submit
helper, other file system can implement their own.
- File systems can optionall to hook into writeback bio submission.
+ File systems can optionally hook into writeback bio submission.
This might include pre-write space accounting updates, or installing
a custom ``->bi_end_io`` function for internal purposes, such as
deferring the ioend completion to a workqueue to run metadata update
diff --git a/Documentation/virt/kvm/review-checklist.rst b/Documentation/virt/kvm/review-checklist.rst
index debac54e14e7..053f00c50d66 100644
--- a/Documentation/virt/kvm/review-checklist.rst
+++ b/Documentation/virt/kvm/review-checklist.rst
@@ -98,7 +98,7 @@ New APIs
It is important to demonstrate your use case. This can be as simple as
explaining that the feature is already in use on bare metal, or it can be
a proof-of-concept implementation in userspace. The latter need not be
- open source, though that is of course preferrable for easier testing.
+ open source, though that is of course preferable for easier testing.
Selftests should test corner cases of the APIs, and should also cover
basic host and guest operation if no open source VMM uses the feature.
--
2.43.0
next reply other threads:[~2025-09-02 19:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 19:38 Ranganath V N [this message]
2025-09-02 19:47 ` [PATCH] Documentation: Fix spelling mistakes Randy Dunlap
2025-09-02 19:59 ` Krzysztof Kozlowski
2025-09-02 20:05 ` Randy Dunlap
2025-09-03 4:00 ` Ranganath V N
2025-09-03 4:46 ` Matthew Wilcox
2025-09-03 16:46 ` Rob Herring (Arm)
2025-09-03 21:36 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250902193822.6349-1-vnranganath.20@gmail.com \
--to=vnranganath.20@gmail.com \
--cc=brauner@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=djwong@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).