coil: cleanup commentsstabilize-rust-13720.B-cr50_stab

BUG=b:175244613
TEST=make buildall -j

Change-Id: Icbd143b072fdd5df3b67d7e5a09ee6c01a77f6b9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2622889
Reviewed-by: Namyoon Woo <namyoon@chromium.org>

4 files changed, 10 insertions, 10 deletions

diff --git a/docs/ap-ec-comm.md b/docs/ap-ec-comm.md
index 0fc31b6822..27d5349ca4 100644
--- a/docs/ap-ec-comm.md
+++ b/docs/ap-ec-comm.md
@@ -112,15 +112,15 @@ the filler byte.
 ### SPI
 
 The SPI bus is similar to I<sup>2</sup>C, but with two major exceptions. First,
-there's a minimum speed on the SPI bus. If slave devices don't respond quickly
-enough, the master will assume they're broken and give up. Second, every
-transaction is bidirectional. When bits are being clocked from master to slave
-on the MOSI line, the master will simultaneously read bits in the other
-direction on the MISO line.
+there's a minimum speed on the SPI bus. If peripheral devices don't respond
+quickly enough, the controller will assume they're broken and give up. Second,
+every transaction is bidirectional. When bits are being clocked from controller
+to peripheral on the MOSI line, the controller will simultaneously read bits in
+the other direction on the MISO line.
 
 Hardware devices can usually handle this, and often some hardware-based flow
-control used to "stretch" the transaction by a bit or byte if the slave device
-needs a little extra time to respond to the master's demands.
+control used to "stretch" the transaction by a bit or byte if the peripheral
+device needs a little extra time to respond to the controller's demands.
 
 When exchanging messages with the EC on the SPI bus, the EC's host commands are
 communicated using our own software flow-control scheme, because most of the
diff --git a/docs/core_runtime.md b/docs/core_runtime.md
index 9d81b807be..680e5e4928 100644
--- a/docs/core_runtime.md
+++ b/docs/core_runtime.md
@@ -52,7 +52,7 @@ where you need to avoid it.
 The hardware interrupt requests are connected to the interruption handling
 *C* routines declared by the `DECLARE_IRQ` macros, through some chip/core
 specific mechanisms (e.g. depending whether we have a vectored interrupt
-controller, slave interrupt controllers...)
+controller, peripheral interrupt controllers...)
 
 The interrupts can be nested (ie interrupted by a higher priority interrupt).
 All the interrupt vectors are assigned a priority as defined in their
diff --git a/docs/ec_terms.md b/docs/ec_terms.md
index 3242302940..bd16635368 100644
--- a/docs/ec_terms.md
+++ b/docs/ec_terms.md
@@ -156,7 +156,7 @@
     Communication involves a SPI frame, consisting of the assertion of chip
     select, transmitting one or more bytes on the MOSI signal, receiving zero or
     more bytes on the MISO signal, and de-assertion of the chip select.  The
-    contents of a SPI frame varies based on the SPI slave type.
+    contents of a SPI frame varies based on the SPI peripheral type.
 
 *   **UART - Universal Asynchronous Receiver Transceiver**{#uart}
 
diff --git a/docs/usb_updater.md b/docs/usb_updater.md
index 476b50f316..cd4be9f881 100644
--- a/docs/usb_updater.md
+++ b/docs/usb_updater.md
@@ -44,7 +44,7 @@ will use `hammerd` (in `src/platform/hammerd`) to update the device.
 Update protocol
 ---------------
 
-The host (either a local AP or a workstation) is the master of the firmware
+The host (either a local AP or a workstation) is the controller of the firmware
 update protocol, it sends data to the Cr50 device, which processes it and
 responds.