docs: Run mdformat on write protection doc

Command used:
(outside) $ mdformat -in_place --compatibility docs/write_protection.md

BRANCH=none
BUG=none
TEST=view in gitiles

Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Change-Id: I3889b3279165b5897f5489549d4530681b6ac5b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2552602
Reviewed-by: Abe Levkoy <alevkoy@chromium.org>

1 files changed, 30 insertions, 25 deletions

diff --git a/docs/write_protection.md b/docs/write_protection.md
index bd891aa39b..2ef32a869e 100644
--- a/docs/write_protection.md
+++ b/docs/write_protection.md
@@ -3,8 +3,8 @@
 [TOC]
 
 This is a somewhat tricky topic since write protection implementations can
-differ between chips and the hardware write protection has changed over time,
-so please edit or open a bug if something is not clear.
+differ between chips and the hardware write protection has changed over time, so
+please edit or open a bug if something is not clear.
 
 ## Terminology
 
@@ -14,12 +14,12 @@ MCUs running the EC code have read-only (RO) and read-write (RW) firmware.
 Coming out of reset, the MCU boots into its RO firmware.
 
 In the case of the EC, the RO firmware boots the host and asks it verify a hash
-of the RW firmware (software sync). If the RW firmware is invalid, it is
-updated from a copy in the host's RW firmware.
+of the RW firmware (software sync). If the RW firmware is invalid, it is updated
+from a copy in the host's RW firmware.
 
 In the case of the FPMCU, the RO firmware uses the public key embedded in it to
-validate the signature of the RW firmware. If the RW firmware is invalid it
-does not jump to the RW firmware.
+validate the signature of the RW firmware. If the RW firmware is invalid it does
+not jump to the RW firmware.
 
 Once the RW firmware is validated, the MCU jumps to it (without rebooting). The
 RO firmware is locked in the factory and is never changed. The RW firmware can
@@ -30,28 +30,28 @@ Note that both the RO and RW firmware regions are normally protected once write
 protect has been turned on.
 
 In the case of the EC, the RW region is unprotected at MCU boot until it has
-been verified by the host. The RW region is protected before the Linux kernel
-is loaded.
+been verified by the host. The RW region is protected before the Linux kernel is
+loaded.
 
 In the case of the FPMCU, the RW region is protected before jumping the RO
 firmware jumps to it.
 
 ## Hardware Write Protect {#hw_wp}
 
-On modern Chrome OS devices, the Cr50 (aka GSC / TPM) provides a "hardware
-write protect" GPIO that is connected to the AP SPI flash, EC SPI flash,
-EEPROM, and FPMCU via a [GPIO][write_protect_gpio].  This "hardware write
-protect" can only be disabled with [Servo] or [SuzyQ] (["CCD open"]) and
-corresponds to [`OverrideWP`] in ccd. Disabling this write protect disables it
-for everything connected to this signal.
+On modern Chrome OS devices, the Cr50 (aka GSC / TPM) provides a "hardware write
+protect" GPIO that is connected to the AP SPI flash, EC SPI flash, EEPROM, and
+FPMCU via a [GPIO][write_protect_gpio]. This "hardware write protect" can only
+be disabled with [Servo] or [SuzyQ] (["CCD open"]) and corresponds to
+[`OverrideWP`] in ccd. Disabling this write protect disables it for everything
+connected to this signal.
 
 In the case of the FPMCU, the hardware write protect GPIO is tied to the STM32
 `BOOT0` pin, which is what tells the MCU to enter the STM32 bootloader mode.
 
-You may see various references to a [write protect screw in
-documentation][wp_screw]. Older Chrome OS devices had a write protect screw
-that had to be physically removed. More details on this history can be found
-here: http://go/cros-wp-status.
+You may see various references to a
+[write protect screw in documentation][wp_screw]. Older Chrome OS devices had a
+write protect screw that had to be physically removed. More details on this
+history can be found here: http://go/cros-wp-status.
 
 Another way of disabling hardware write protection is to remove the battery;
 this method is mainly used during bringup.
@@ -61,13 +61,15 @@ https://www.google.com/chromeos/partner/fe/docs/cpfe/firmwaretestmanual.html#har
 
 ## Changing Hardware Write Protection
 
-Modifying the state of hardware write protection (via Cr50 GPIO) can be done
-if the ["CCD open"] process has been completed.
+Modifying the state of hardware write protection (via Cr50 GPIO) can be done if
+the ["CCD open"] process has been completed.
 
+<!-- mdformat off(b/139308852) -->
 *** note
 `servod` *must* be running for `dut-control` to work. See the [Servo] page for
 details.
 ***
+<!-- mdformat on -->
 
 ### Enable Hardware Write Protection
 
@@ -115,14 +117,17 @@ https://www.google.com/chromeos/partner/fe/docs/cpfe/firmwaretestmanual.html#sof
 
 ## Changing Software Write Protection
 
+<!-- mdformat off(b/139308852) -->
 *** note
 *NOTE*: You cannot disable software write protect if hardware write protect is
 enabled.
 ***
+<!-- mdformat on -->
 
-Software write protection can be toggled with `ectool --name=cros_fp flashprotect
-enable/disable`, which sends the `EC_CMD_FLASH_PROTECT` command toggling
-`EC_FLASH_PROTECT_RO_AT_BOOT` (changing `--name` to target different ECs).
+Software write protection can be toggled with `ectool --name=cros_fp
+flashprotect enable/disable`, which sends the `EC_CMD_FLASH_PROTECT` command
+toggling `EC_FLASH_PROTECT_RO_AT_BOOT` (changing `--name` to target different
+ECs).
 
 ### Changing Software Write Protection with `ectool`
 
@@ -258,8 +263,8 @@ SUCCESS
 
 ## `system_is_locked()`
 
-The [`system_is_locked()`] function in the EC code returns false if the HW
-write protect GPIO is disabled or the read-only firmware is not protected.
+The [`system_is_locked()`] function in the EC code returns false if the HW write
+protect GPIO is disabled or the read-only firmware is not protected.
 
 One way this is used in the FPMCU source is to compile test or debug
 functionality into the firmware. Guarding the test functionality with