docs: Run mdformat on all .md files

BRANCH=none
BUG=b:178648877
TEST=view in gitiles

Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Change-Id: I0ac5581ba7bc512234d40dbf34222422afa9c725
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2650551
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>

1 files changed, 46 insertions, 54 deletions

diff --git a/board/servo_micro/ccd.md b/board/servo_micro/ccd.md
index acb82adb94..d05fa726fd 100644
--- a/board/servo_micro/ccd.md
+++ b/board/servo_micro/ccd.md
@@ -6,30 +6,31 @@
 
 # Case-Closed Debug in Chromebooks and Servo Micro
 
-The Servo debug/test-automation connector has been required on all
-chromebooks. It has proved essential to performing the required testing to meet
-the six week OS release cycle, for bringing up new systems and qualifying new
-components. In newer form-factors it is becoming hard to fit the Servo connector
-(and related flex) and in some designs the thermal solution stops working when
-the connector is used. The secure Case-Closed Debugging solution provides the
-same capabilities and can take advantage of the Debug Mode detection available
-on the USB-C connector. This application note gives an overview of Case-Closed
-Debug (CCD) but does not address the related security issues.
-
+The Servo debug/test-automation connector has been required on all chromebooks.
+It has proved essential to performing the required testing to meet the six week
+OS release cycle, for bringing up new systems and qualifying new components. In
+newer form-factors it is becoming hard to fit the Servo connector (and related
+flex) and in some designs the thermal solution stops working when the connector
+is used. The secure Case-Closed Debugging solution provides the same
+capabilities and can take advantage of the Debug Mode detection available on the
+USB-C connector. This application note gives an overview of Case-Closed Debug
+(CCD) but does not address the related security issues.
 
 ## Introduction to Case-Closed Debug
 
-Case-Closed Debug provides the same set of features as are available on the Servo connector:
+Case-Closed Debug provides the same set of features as are available on the
+Servo connector:
 
 *   Access to console UART connections to AP, EC and on some systems a third MCU
 *   Ability to reprogram firmware/BIOS SPI flash used by the AP
 *   Ability to reprogram SPI flash used by the EC or use a firmware update mode
     to reprogram the internal flash on the EC (using UART or I2C)
 *   GPIOs for holding the EC (and thus entire system) or AP in reset
-*   Act as master on a debug I2C that is primarily used for power
-    measurements. This bus normally contains INA voltage/current monitors and
-    temperature monitors that will not be populated on final MP systems.
-*   JTAG/SWD could be provided but has not been implemented on any existing system.
+*   Act as master on a debug I2C that is primarily used for power measurements.
+    This bus normally contains INA voltage/current monitors and temperature
+    monitors that will not be populated on final MP systems.
+*   JTAG/SWD could be provided but has not been implemented on any existing
+    system.
 
 When the Servo connector is used these interfaces are presented on well defined
 pins of the board-to-board connector and a flex is used to attach to the
@@ -43,7 +44,6 @@ be used for the debug USB while the main link on the connector continues to be
 available. (The SBU pins are also used by some Alternate Modes, so the connector
 cannot be used for video out at the same time as debugging.)
 
-
 ## Servo Micro: Using CCD with existing boards
 
 The Servo Micro implements the CCD functions in a way that can connect to
@@ -60,8 +60,8 @@ original Servo connector, but on some designs) can be connected to either the
 JTAG pins or the SPI pins. It is capable of providing the SPI flash supply
 voltages.
 
-The schematics for Servo Micro are available [as a
-pdf](servo_micro_sch_20180404.pdf).
+The schematics for Servo Micro are available
+[as a pdf](servo_micro_sch_20180404.pdf).
 
 Servo Micro has a USB micro-B connector and acts as a USB device.
 
@@ -75,8 +75,8 @@ UART connection on CN2.
 
 Schematic sheet 3 shows the I2C GPIO expander and the buffers for JTAG/SWD. The
 buffers adapt to the voltage needed on the DUT that is provided on
-`PPDUT_JTAG_VREF`. In the SWD case the TDI becomes the bidirectional SWDIO but the
-STM32 continues to use a discrete input and output pin. The DUT signal is
+`PPDUT_JTAG_VREF`. In the SWD case the TDI becomes the bidirectional SWDIO but
+the STM32 continues to use a discrete input and output pin. The DUT signal is
 received through U55 and a selection made with U1 to determine if to forward TDO
 from the DUT or the TDI/SWDIO. Because of the shared pins on the STM32 the JTAG
 interface can alternatively be used to connect UART3 to the DUT for a few
@@ -103,26 +103,23 @@ load switches are carefully selected to have reverse blocking (protecting
 against a DUT providing a voltage or both being enabled).
 
 The code for the STM32 in Servo Micro is open source as the
-[`servo_micro`](../../board/servo_micro)
-board in the [Chromium EC
-codebase](https://chromium.googlesource.com/chromiumos/platform/ec/). Essentially
-it is a USB device that provides the standard control endpoint and 7 function
-endpoints defined in
-[`board.h`](board.h).
+[`servo_micro`](../../board/servo_micro) board in the
+[Chromium EC codebase](https://chromium.googlesource.com/chromiumos/platform/ec/).
+Essentially it is a USB device that provides the standard control endpoint and 7
+function endpoints defined in [`board.h`](board.h).
 
 <!-- does not work in emacs/markdown preview but should in gitlies -->
 
-``` c
-    #define USB_EP_USART4_STREAM	1
-    #define USB_EP_UPDATE			2
-    #define USB_EP_SPI			3
-    #define USB_EP_CONSOLE		4
-    #define USB_EP_I2C			5
-    #define USB_EP_USART3_STREAM	6
-    #define USB_EP_USART2_STREAM	7
+```c
+#define USB_EP_USART4_STREAM    1
+#define USB_EP_UPDATE           2
+#define USB_EP_SPI              3
+#define USB_EP_CONSOLE          4
+#define USB_EP_I2C              5
+#define USB_EP_USART3_STREAM    6
+#define USB_EP_USART2_STREAM    7
 ```
 
-
 The USART endpoints use the simple `GOOGLE_SERIAL` vendor class to connect the
 STM32 UARTs. The CONSOLE endpoint also uses `GOOGLE_STREAM` to connect to the
 console of the code running on the STM32. `GOOGLE_STREAM` provides simple byte
@@ -131,32 +128,27 @@ standard Linux `drivers/usb/serial/usb-serial-simple.c`
 
 The SPI endpoint is described in
 [`chip/stm32/usb_spi.h`](../../chip/stm32/usb_spi.h) and provides a simple
-connection to the SPI port. The host support is provided as a [driver in
-flashrom](https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/raiden_debug_spi.c).
+connection to the SPI port. The host support is provided as a
+[driver in flashrom](https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/raiden_debug_spi.c).
 
 The I2C endpoint is described in [`include/usb_i2c.h`](../../include/usb_i2c.h)
 and provides a simple connection to the I2C bus. The host support is provided in
-the [hdctools servo
-support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32i2c.py).
+the
+[hdctools servo support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32i2c.py).
 
 The GPIO endpoint is cryptically described in
-[`chip/stm32/usb_gpio.h`](../../chip/stm32/usb_gpio.h) and provides simple access
-to set/clear and read the GPIO pins. The host support is provided in the
-[hdctools servo
-support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32gpio.py).
+[`chip/stm32/usb_gpio.h`](../../chip/stm32/usb_gpio.h) and provides simple
+access to set/clear and read the GPIO pins. The host support is provided in the
+[hdctools servo support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32gpio.py).
 
 The UPDATE endpoint is not part of CCD. It provides a method for updating the
-STM32 without needing the special boot modes. This uses the [Chromium EC update
-over
-USB](../../docs/usb_updater.md)
-method. The STM32 runs the code in
-[`common/usb_update.c`](../../common/usb_update.c).
-The host side code is in
-[`extra/usb_updater/usb_updater2.c`](../../extra/usb_updater/usb_updater2.c)
-and the
-[`extra/usb_updater`](../../extra/usb_updater/)
-directory contains additional scripts.
-
+STM32 without needing the special boot modes. This uses the
+[Chromium EC update over USB](../../docs/usb_updater.md) method. The STM32 runs
+the code in [`common/usb_update.c`](../../common/usb_update.c). The host side
+code is in
+[`extra/usb_updater/usb_updater2.c`](../../extra/usb_updater/usb_updater2.c) and
+the [`extra/usb_updater`](../../extra/usb_updater/) directory contains
+additional scripts.
 
 ## Using CCD on new designs