Fix a few typos spot during a first read of the contribution process.
Signed-off-by: Maxim Cournoyer <email@example.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(-)
Toggle diff (78 lines)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0fa0143bf3..ba864bc40b 100644
@@ -165,7 +165,7 @@ document.
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
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
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
index 173075687e..49374f14ff 100644
@@ -20,8 +20,8 @@ LWN article `How to Get Your Change Into the Linux Kernel
-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
@@ -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