diff --git a/REST-cheatsheet.md b/REST-cheatsheet.md
index 85f1fc6..8815f55 100644
--- a/REST-cheatsheet.md
+++ b/REST-cheatsheet.md
@@ -67,7 +67,7 @@
 Note: To keep the syntax below common between the phosphor-rest and bmcweb
       implementations as described above, this assumes that if bmcweb
       is used it is using the `<username>:<password>@<host>` login method
-      as desribed above:
+      as described above:
    ```
       export bmc=<username>:<password>@xx.xx.xx.xx
    ```
diff --git a/designs/ci-authorization.md b/designs/ci-authorization.md
index f21c396..4aea891 100644
--- a/designs/ci-authorization.md
+++ b/designs/ci-authorization.md
@@ -35,7 +35,7 @@
 project maintainer to trigger the automated CI processes.
 
 
-Additonal reading:
+Additional reading:
 https://en.wikipedia.org/wiki/Continuous_integration
 https://jenkins.io/
 https://help.github.com/articles/about-organizations/
diff --git a/kernel-development.md b/kernel-development.md
index b646cf2..45bfa58 100644
--- a/kernel-development.md
+++ b/kernel-development.md
@@ -31,7 +31,7 @@
 
 There are cases where waiting for upstream acceptance will delay the bring-up of a new system. This should be avoided through careful planning and early development of the features upstream, but where this has not happened we can chose to carry the patches in the OpenBMC tree while the upstream development is ongoing.
 
-Another exception to the upstream first rule is where patches are modifying files that are not upstream. This currently includes the aspeed board file `arch/arm/mach-aspeed/aspeed.c`, and the device tree source files `dts`. The board file should go away when we get drivers written for all of the functionaltiy; for now it contains some hacks relating to LPC and early init.
+Another exception to the upstream first rule is where patches are modifying files that are not upstream. This currently includes the aspeed board file `arch/arm/mach-aspeed/aspeed.c`, and the device tree source files `dts`. The board file should go away when we get drivers written for all of the functionality; for now it contains some hacks relating to LPC and early init.
 
 If you find yourself adding to `arch/arm/mach-aspeed/aspeed.c`, first send an email to the OpenBMC list to get the opinion of the kernel developers. Patches to `aspeed.c` will be treated with some prejudice as the file will be removed once we have drivers for all of the Aspeed peripherals.