diff --git a/designs/gpio-based-cable-presence.md b/designs/gpio-based-cable-presence.md
index 8c4987c..91cbdf5 100644
--- a/designs/gpio-based-cable-presence.md
+++ b/designs/gpio-based-cable-presence.md
@@ -95,7 +95,7 @@
 ```
 
 On the other hand, if the object name from the config file is not indexed. For
-exmaple, `/xyz/openbmc_project/inventory/item/cable`. The group handler will not
+example, `/xyz/openbmc_project/inventory/item/cable`. The group handler will not
 try to group it with anything and use 1 SDR ID for its presence state.
 See the following for an example output.
 ```
diff --git a/designs/ibm/system-power-mode.md b/designs/ibm/system-power-mode.md
index 1e28f80..49647eb 100644
--- a/designs/ibm/system-power-mode.md
+++ b/designs/ibm/system-power-mode.md
@@ -83,7 +83,7 @@
 
 Default values will also be defined for Power Mode and Idle Power Saver
 parameters for the system.  If the customer has not yet set any of these
-paramters, these default values will be used.  If/when the customer does
+parameters, these default values will be used.  If/when the customer does
 set any of these, that new customer parameter will become current and the
 default value will no longer be used.
 
@@ -101,7 +101,7 @@
 New interfaces that were described in the requirements section will be
 implemented.  Parameters should be able to be set via user interface or
 via Redfish.
-API impact - Add Redfish support fo new parameters as well as new user
+API impact - Add Redfish support for new parameters as well as new user
 interface to allow customer to set power mode and idle power saver settings
 Security impact - update of these parameters should be able to be restricted
 to specific users/groups (may not want any user updating these parameters)
@@ -111,7 +111,7 @@
 The new code is only sending 2 additional commands which should complete
 within a few seconds.
 Developer impact - code to be written by OCC team with guidance from
-OpenBMC power managmenet team
+OpenBMC power management team
 Upgradability impact - None
 
 ## Testing
diff --git a/designs/multihost-phosphor-buttons.md b/designs/multihost-phosphor-buttons.md
index b578402..ff694b3 100644
--- a/designs/multihost-phosphor-buttons.md
+++ b/designs/multihost-phosphor-buttons.md
@@ -21,12 +21,12 @@
 and event handling.
 
 Currently handler events are only based on monitoring gpio events
-as input (power and reset).There may be cases where whe need to create
+as input (power and reset).There may be cases where we need to create
 button interface which monitors non gpio events
 and triggers button actions for example events based on dbus property changes.
 
 ## Requirements
-This feature is needed to support additonal phosphor button interfaces
+This feature is needed to support additional phosphor button interfaces
 corresponding to platform specific hardware buttons/MUX/Switches which are
 available in the front panel apart from existing power and reset button
 interfaces.
@@ -194,9 +194,9 @@
 A separate interface for debug card host selector button is created.
 
 This button interface monitors the corresponding gpio lines for debug card
-host selecton button press and release event via sd-event based loop.
+host selection button press and release event via sd-event based loop.
 
-### OCP Debug card host selector buton dbus interface details :
+### OCP Debug card host selector button dbus interface details :
   1. Released(signal) - This is signal is triggered in the ocp debug card event
   handler when the ocp debug card button is pressed and released.
 
@@ -206,7 +206,7 @@
 value exceeds MaxPosition Value.
 
 This way when power and reset button press events are handled,
-the Host selector Position property is refered and based on the
+the Host selector Position property is referred and based on the
 Position respective power events are called.
 
 ## serial console MUX  interface
@@ -233,4 +233,4 @@
 
 ## Testing
 The proposed design can be tested in a platform in which the multiple hosts
-are connected.
\ No newline at end of file
+are connected.
diff --git a/designs/phosphor-hwmon-io-uring.md b/designs/phosphor-hwmon-io-uring.md
index 3652294..76dbe3a 100644
--- a/designs/phosphor-hwmon-io-uring.md
+++ b/designs/phosphor-hwmon-io-uring.md
@@ -123,7 +123,7 @@
 information includes open file descriptor from the `open()` system call,
 number of retries remaining for reading this sensor when errors occur, etc.
 
-Each call to access the read value of a particaular sesnor in the read cache
+Each call to access the read value of a particular sesnor in the read cache
 will not only return the cached value but will also submit a SQE (submission
 queue event) to io_uring for that sensor; this SQE acts as a read request
 that will be sent to the kernel. The implementation maintains a set of sensors
diff --git a/designs/power-recovery.md b/designs/power-recovery.md
index 463286e..bf055c2 100644
--- a/designs/power-recovery.md
+++ b/designs/power-recovery.md
@@ -163,7 +163,7 @@
 If the power recovery software sees the `PinholeReset` reason within the
 `RebootCause` then it will not implement any of its policy. Future BMC
 reboots which are not pin hole reset caused, will cause `RebootCause` to go
-back to a default and therefore power recovery policy will be reenabled on that
+back to a default and therefore power recovery policy will be re-enabled on that
 BMC boot.
 
 The phosphor-state-manager chassis software will not log a blackout error
diff --git a/designs/virtual-media.md b/designs/virtual-media.md
index cd42ba3..a9df89f 100644
--- a/designs/virtual-media.md
+++ b/designs/virtual-media.md
@@ -407,7 +407,7 @@
 
 Depends on object path, object will expose different interface for mounting image.
 
-Mounting can be a time consuming task, so event driven mechanis has to be
+Mounting can be a time consuming task, so event driven mechanism has to be
 introduced. Mount and Unmount calls will trigger asynchronous action and will
 end immediately, giving appropriate signal containing status on task
 completion.