@@ -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.
@@ -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.
@@ -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
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(-) base-commit: 9bd3d354a1a0712ac27c717df9ad60566b0406ee