[bug#60135] [PATCH] doc: fix typos

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Fix a few typos spot during a first read of the contribution process.

Signed-off-by: Maxim Cournoyer <maxim.cournoyer@savoirfairelinux.com>
---

 doc/develop/process.rst              | 4 ++--
 doc/develop/sending_patches.rst      | 6 +++---
 doc/develop/system_configuration.rst | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0fa0143bf3..ba864bc40b 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -165,7 +165,7 @@ document.
   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
   and similar additional tags.
 
-* Reviewed-by: The patch has been reviewed and found acceptible according to
+* Reviewed-by: The patch has been reviewed and found acceptable according to
   the `Reveiwer's statement of oversight
   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_.
   A *Reviewed-by:* tag is a statement of opinion that the patch is an
@@ -251,7 +251,7 @@ like this:
    workflows and environments however.
 
 #. Although a custodian is supposed to perform their own tests it is a
-   well-known and accepted fact that they needs help from other developers who
+   well-known and accepted fact that they need help from other developers who
    - for example - have access to the required hardware or other relevant
    environments.  Custodians are expected to ask for assistance with testing
    when required.
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
index 173075687e..49374f14ff 100644
--- a/doc/develop/sending_patches.rst
+++ b/doc/develop/sending_patches.rst
@@ -20,8 +20,8 @@ LWN article `How to Get Your Change Into the Linux Kernel
 Using patman
 ------------
 
-You can use a tool called patman to prepare, check and sent patches. It creates
-change logs, cover letters and patch notes. It also simplified the process of
+You can use a tool called patman to prepare, check and send patches. It creates
+change logs, cover letters and patch notes. It also simplifies the process of
 sending multiple versions of a series.
 
 See more details at :doc:`patman`.
@@ -312,7 +312,7 @@ Notes
 2. All code must follow the :doc:`codingstyle` requirements.
 
 3. Before sending the patch, you *must* run some form of local testing.
-   Submitting a patch that does not build or function correct is a mistake. For
+   Submitting a patch that does not build or function correctly is a mistake. For
    non-trivial patches, either building a number of platforms locally or making
    use of :doc:`ci_testing` is strongly encouraged in order to avoid problems
    that can be found when attempting to merge the patch.
diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst
index 52e4e1df15..40be46b082 100644
--- a/doc/develop/system_configuration.rst
+++ b/doc/develop/system_configuration.rst
@@ -86,12 +86,12 @@ When to use each mechanism
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 While there are some cases where it should be fairly obvious where to use each
-mechanism, as for example a command would done via Kconfig, a new I2C driver
+mechanism, as for example a command would be done via Kconfig, a new I2C driver
 should use Kconfig and be configured via driver model and a header of values
 generated by an external tool should be ``CFG``, there will be cases where it's
 less clear and one needs to take care when implementing it. In general,
 configuration *options* should be done in Kconfig and configuration *settings*
-should done in driver model or ``CFG``. Let us discuss things to keep in mind
+should be done in driver model or ``CFG``. Let us discuss things to keep in mind
 when picking the appropriate mechanism.
 
 A thing to keep in mind is that we have a strong preference for using Kconfig as
@@ -122,7 +122,7 @@ to use Kconfig in this case, it would result in using calculated rather than
 constructed values, resulting in less clear code. Consider the example of a set
 of register values for a memory controller. Defining this as a series of logical
 ORs and shifts based on other defines is more clear than the Kconfig entry that
-set the calculated value alone.
+sets the calculated value alone.
 
 When it has been determined that the practical solution is to utilize the
 ``CFG`` mechanism, the next decision is where to place these settings. It is

base-commit: 9bd3d354a1a0712ac27c717df9ad60566b0406ee
-- 
2.38.1