doc: fix typos

[platform/kernel/u-boot.git] / doc / develop / system_configuration.rst

diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst
index 52e4e1d..40be46b 100644 (file)
--- 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