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>

4 files changed, 138 insertions, 129 deletions

diff --git a/extra/stack_analyzer/README.md b/extra/stack_analyzer/README.md
index bead6d10b4..d1c77b57d2 100644
--- a/extra/stack_analyzer/README.md
+++ b/extra/stack_analyzer/README.md
@@ -1,27 +1,22 @@
-Stack Size Analysis Tool for EC Firmware
-========================================
+# Stack Size Analysis Tool for EC Firmware
 
 This tool does static analysis on EC firmwares to get the maximum stack usage of
 each function and task. The maximum stack usage of a function includes the stack
 used by itself and the functions it calls.
 
-Usage
------
+## Usage
 
 Make sure the firmware of your target board has been built.
 
-In `src/platform/ec`, run
-```
-make BOARD=${BOARD} SECTION=${SECTION} ANNOTATION=${ANNOTATION} analyzestack
-```
-The `${SECTION}` can be `RO` or `RW`. The `${ANNOTATION}` is a optional
-annotation file, see the example_annotation.yaml, by default,
-board/$BOARD/analyzestack.yaml is used.
+In `src/platform/ec`, run `make BOARD=${BOARD} SECTION=${SECTION}
+ANNOTATION=${ANNOTATION} analyzestack` The `${SECTION}` can be `RO` or `RW`. The
+`${ANNOTATION}` is a optional annotation file, see the example_annotation.yaml,
+by default, board/$BOARD/analyzestack.yaml is used.
 
-Output
-------
+## Output
 
 For each task, it will output the result like below,
+
 ```
 Task: PD_C1, Max size: 1156 (932 + 224), Allocated size: 640
 Call Trace:
@@ -34,9 +29,12 @@ Call Trace:
     pd_send_request_msg.lto_priv.263 (56) [common/usb_pd_protocol.c:653] 1009a0b4
         -> pd_send_request_msg.lto_priv.263[common/usb_pd_protocol.c:712] 1009a22e0
 ```
-The `pd_task` uses 160 bytes on the stack and calls `pd_send_request_msg.lto_priv.263`.
+
+The `pd_task` uses 160 bytes on the stack and calls
+`pd_send_request_msg.lto_priv.263`.
 
 The callsites to the next function will be shown like below,
+
 ```
 -> pd_task[common/usb_pd_protocol.c:1808] 1008ac8a
    - handle_request[common/usb_pd_protocol.c:1191]
@@ -44,37 +42,42 @@ The callsites to the next function will be shown like below,
 -> pd_task[common/usb_pd_protocol.c:2672] 1008c222
 -> [annotation]
 ```
-This means one callsite to the next function is at `usb_pd_protocol.c:798`,
-but it is inlined to the current function and you can follow the trace:
+
+This means one callsite to the next function is at `usb_pd_protocol.c:798`, but
+it is inlined to the current function and you can follow the trace:
 `usb_pd_protocol.c:1808 -> usb_pd_protocol.c:1191 -> usb_pd_protocol.c:798` to
 find the callsite. The second callsite is at `usb_pd_protocol.c:2672`. And the
 third one is added by annotation.
 
 The unresolved indirect callsites have the similar format to the above.
 
-Annotating Indirect Call
-------------------------
+## Annotating Indirect Call
 
 To annotate an indirect call like this,
+
 ```
 Unresolved indirect callsites:
     pd_transmit
         -> pd_transmit[common/usb_pd_protocol.c:407] 802c9c8
            - tcpm_transmit[driver/tcpm/tcpm.h:142]
 ```
-It is an indirect call in the `tcpm_transmit`, which is inlined to the `pd_transmit`.
+
+It is an indirect call in the `tcpm_transmit`, which is inlined to the
+`pd_transmit`.
 
 You can add a annotation like the below to eliminate it.
+
 ```
 add:
   tcpm_transmit[driver/tcpm/tcpm.h:142]:
   - anx74xx_tcpm_transmit
 ```
-The source `tcpm_transmit[driver/tcpm/tcpm.h:142]` must be a full signature (function_name[path:line number]).
-So the resolver can know which indirect call you want to annotate and eliminate (even if it is inlined).
 
-Annotating arrays (hooks, console commands, host commands)
-----------------------------------------------------------
+The source `tcpm_transmit[driver/tcpm/tcpm.h:142]` must be a full signature
+(function_name[path:line number]). So the resolver can know which indirect call
+you want to annotate and eliminate (even if it is inlined).
+
+## Annotating arrays (hooks, console commands, host commands)
 
 When a callsite calls a number of functions based on values from an constant
 array (in `.rodata` section), one can use the following syntax:
@@ -89,8 +92,8 @@ array (in `.rodata` section), one can use the following syntax:
 Where `name` is the symbol name for the start of the array (the end of the array
 is `<name>_end`), stride is the array element size, and offset is the offset of
 the function pointer in the structure. For example, above, `__deferred_funcs` is
-a simple array of function pointers, while `__hooks_tick` is an array of
-`struct hook_data` (size 8, pointer at offset 0):
+a simple array of function pointers, while `__hooks_tick` is an array of `struct
+hook_data` (size 8, pointer at offset 0):
 
 ```
 struct hook_data {
diff --git a/extra/tigertool/README.md b/extra/tigertool/README.md
index e808536e7b..407a58a751 100644
--- a/extra/tigertool/README.md
+++ b/extra/tigertool/README.md
@@ -1,18 +1,28 @@
 # tigertool
 
-tigertool.py is a commandline utility to control the tigertail USB-C mux.
-It supports changing the mux status to port A, B, or off.
-You can set a serial number to use multiple tigertails at once.
+tigertool.py is a commandline utility to control the tigertail USB-C mux. It
+supports changing the mux status to port A, B, or off. You can set a serial
+number to use multiple tigertails at once.
 
 ## Usage
-Typical usage to set the mux port<br>
-```./tigertail.py -m [A|B|off] -s [serialno]```<br>
+
+Typical usage to set the mux port
+
+```
+./tigertail.py -m [A|B|off] -s [serialno]
+```
 
 Reboot the tigertail<br>
-```./tigertail.py --reboot```<br>
 
-Set the serial number, when only one tigertail is plugged<br>
-```./tigertail.py --setserialno=[serialno]```<br>
+```
+./tigertail.py --reboot
+```
+
+Set the serial number, when only one tigertail is plugged
+
+```
+./tigertail.py --setserialno=[serialno]
+```
 
-Tigertail can support up to 20V 3A on the mux and passes through all
-USB-C lines except SBU.
+Tigertail can support up to 20V 3A on the mux and passes through all USB-C lines
+except SBU.
diff --git a/extra/usb_power/powerlog.README.md b/extra/usb_power/powerlog.README.md
index a5ce379670..105516330a 100644
--- a/extra/usb_power/powerlog.README.md
+++ b/extra/usb_power/powerlog.README.md
@@ -9,57 +9,58 @@ this session, a `.scenario` file.
 
 ## Converting from servo_ina configs
 
-- Method 1 (not limited to chroot)
+-   Method 1 (not limited to chroot)
 
-  Many configs can be found for the servo_ina_board in `hdctools/servo/data/`.
-  Sweetberry is plug compatible with servo_ina headers, and config files can be
-  converted with the following tool:
+    Many configs can be found for the servo_ina_board in `hdctools/servo/data/`.
+    Sweetberry is plug compatible with servo_ina headers, and config files can
+    be converted with the following tool:
 
-  ```
-  ./convert_servo_ina.py <board>_r0_loc.py
-  ```
+    ```
+    ./convert_servo_ina.py <board>_r0_loc.py
+    ```
 
-  This will generate `<board>_r0_loc.board` and `<board>_r0_loc.scenario`
-  locally, which can be used with `powerlog.py`.
+    This will generate `<board>_r0_loc.board` and `<board>_r0_loc.scenario`
+    locally, which can be used with `powerlog.py`.
 
-- Method 2 (recommended for Chrome OS developers, requires chroot)
+-   Method 2 (recommended for Chrome OS developers, requires chroot)
 
-  If you are using `powerlog.py` within the chroot, copy `<board>_r0_loc.py` to
-  `src/third_party/hdctools/servo/data`, then add this line to file:
+    If you are using `powerlog.py` within the chroot, copy `<board>_r0_loc.py`
+    to `src/third_party/hdctools/servo/data`, then add this line to file:
 
-  ```python
-  config_type = 'sweetberry'
-  ```
+    ```python
+    config_type = 'sweetberry'
+    ```
 
-  And run command in chroot:
+    And run command in chroot:
 
-  ```
-  (Anywhere in chroot, just ONCE) cros_workon --host start dev-util/hdctools
-  ```
+    ```
+    (Anywhere in chroot, just ONCE) cros_workon --host start dev-util/hdctools
+    ```
 
-  Then every time you make a change to `<board>_r0_loc.py`, run:
+    Then every time you make a change to `<board>_r0_loc.py`, run:
 
-  ```
-  (Anywhere in chroot) sudo emerge dev-util/hdctools
-  ```
+    ```
+    (Anywhere in chroot) sudo emerge dev-util/hdctools
+    ```
 
-  The command will install the corresponding `.board` and `.scenario` file in
-  the chroot. To use `powerlog.py` use the command:
+    The command will install the corresponding `.board` and `.scenario` file in
+    the chroot. To use `powerlog.py` use the command:
 
-  ```
-  (Anywhere in chroot) powerlog -b <board>_r0_loc.board -c <board>_r0_loc.scenario
-  ```
+    ```
+    (Anywhere in chroot) powerlog -b <board>_r0_loc.board -c <board>_r0_loc.scenario
+    ```
 
-  There is no need to specify the absolute path to the `.board` and `.scenario`
-  file, once they are installed into the chroot. If there is any changes to
-  `<board>_r0_loc.py`, you need to `sudo emerge dev-util/hdctools` again.
+    There is no need to specify the absolute path to the `.board` and
+    `.scenario` file, once they are installed into the chroot. If there is any
+    changes to `<board>_r0_loc.py`, you need to `sudo emerge dev-util/hdctools`
+    again.
 
 ## Board files
 
 Board files contain a list of rails, supporting 48 channels each on up to two
 Sweetberries. For each rail you must specify a name, sense resistor value, and
-channel number. You can optionally list expected voltage and net name.
-The format is as follows, in json:
+channel number. You can optionally list expected voltage and net name. The
+format is as follows, in json:
 
 example.board:
 
@@ -81,9 +82,8 @@ example.board:
 Scenario files contain the set of rails to monitor in this session. The file
 format is simply a list of rail names from the board file.
 
-Optionally, you can specify the type of measurement, from the set of
-`"POWER"`, `"BUSV"`, `"CURRENT"`, `"SHUNTV"`. If not specified, the default is
-power.
+Optionally, you can specify the type of measurement, from the set of `"POWER"`,
+`"BUSV"`, `"CURRENT"`, `"SHUNTV"`. If not specified, the default is power.
 
 example.scenario:
 
@@ -109,93 +109,90 @@ An example run of:
 ./powerlog.py -b board/marlin/marlin.board -c board/marlin/marlin_short.scenario -t 100000
 ```
 
-Will result in:
-```
-ts:32976us, VBAT uW, VDD_MEM uW, VDD_CORE uW, VDD_GFX uW, VDD_1V8_PANEL uW
-0.033004, 12207.03, 4882.81, 9155.27, 2441.41, 0.00
-0.066008, 12207.03, 3662.11, 9155.27, 2441.41, 0.00
-0.099012, 12207.03, 3662.11, 9155.27, 2441.41, 0.00
-...
-```
+Will result in: `ts:32976us, VBAT uW, VDD_MEM uW, VDD_CORE uW, VDD_GFX uW,
+VDD_1V8_PANEL uW 0.033004, 12207.03, 4882.81, 9155.27, 2441.41, 0.00 0.066008,
+12207.03, 3662.11, 9155.27, 2441.41, 0.00 0.099012, 12207.03, 3662.11, 9155.27,
+2441.41, 0.00 ...`
 
 The output format is as follows:
 
-- `ts:32976us`
+-   `ts:32976us`
 
-  Timestamps either zero based or synced to system clock, in seconds. The column
-  header indicates the selected sampling interval. Since the INA231 has specific
-  hardware defines sampling options, this will be the closest supported option
-  lower than the requested `-t` value on the command line.
+    Timestamps either zero based or synced to system clock, in seconds. The
+    column header indicates the selected sampling interval. Since the INA231 has
+    specific hardware defines sampling options, this will be the closest
+    supported option lower than the requested `-t` value on the command line.
 
-- `VBAT uW`
+-   `VBAT uW`
 
-  Microwatt reading from this rail, generated on the INA by integrating the
-  voltage/amperage on the sense resistor over the sampling time, and multiplying
-  by the sampled bus voltage.
+    Microwatt reading from this rail, generated on the INA by integrating the
+    voltage/amperage on the sense resistor over the sampling time, and
+    multiplying by the sampled bus voltage.
 
-- `... uW`
+-   `... uW`
 
-  Further microwatt entry columns for each rail specified in your scenario file.
+    Further microwatt entry columns for each rail specified in your scenario
+    file.
 
-- `... xX`
+-   `... xX`
 
-  Measurement in uW, mW, mV, uA, uV as per config.
+    Measurement in uW, mW, mV, uA, uV as per config.
 
 ## Calculate stats and store data and stats
 
 When appropriate flag is set, powerlog.py is capable of calculating statistics
 and storing statistics and raw data.
 
-- Example 1
+-   Example 1
 
-  ```
-  ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_stats [<directory>]
-  ```
+    ```
+    ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_stats [<directory>]
+    ```
 
-  If `<directory>` is specified, this will save stats as:
-  `<directory>/sweetberry<timestemp>/summary.txt`.
-  If `<directory>` does not exist, it will be created.
+    If `<directory>` is specified, this will save stats as:
+    `<directory>/sweetberry<timestamp>/summary.txt`. If `<directory>` does not
+    exist, it will be created.
 
-  If `<directory>` is not specified but the flag is set, this will save stats
-  under the directory which `powerlog.py` is in:
-  `<directory of powerlog.py>/sweetberry<timestemp>/summary.txt`.
+    If `<directory>` is not specified but the flag is set, this will save stats
+    under the directory which `powerlog.py` is in: `<directory of
+    powerlog.py>/sweetberry<timestamp>/summary.txt`.
 
-  If `--save_stats` flag is not set, stats will not be saved.
+    If `--save_stats` flag is not set, stats will not be saved.
 
-- Example 2
+-   Example 2
 
-  ```
-  ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_raw_data [<directory>]
-  ```
+    ```
+    ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_raw_data [<directory>]
+    ```
 
-  If `<directory>` is specified, this will save raw data in:
-  `<directory>/sweetberry<timestemp>/raw_data/`.
-  If `<directory>` does not exist, it will be created.
+    If `<directory>` is specified, this will save raw data in:
+    `<directory>/sweetberry<timestamp>/raw_data/`. If `<directory>` does not
+    exist, it will be created.
 
-  If `<directory>` is not specified but the flag is set, this will save raw data
-  under the directory which `powerlog.py` is in:
-  `<directory of powerlog.py>/sweetberry<timestemp>/raw_data/`.
+    If `<directory>` is not specified but the flag is set, this will save raw
+    data under the directory which `powerlog.py` is in: `<directory of
+    powerlog.py>/sweetberry<timestamp>/raw_data/`.
 
-  If `--save_raw_data` flag is not set, raw data will not be saved.
+    If `--save_raw_data` flag is not set, raw data will not be saved.
 
-- Example 3:
+-   Example 3:
 
-  ```
-  ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_stats_json [<directory>]
-  ```
+    ```
+    ./powerlog.py -b board/eve_dvt2_loc/eve_dvt2_loc.board -c board/eve_dvt2_loc/eve_dvt2_loc.scenario --save_stats_json [<directory>]
+    ```
 
-  If `<directory>` is specified, this will save MEANS in json as:
-  `<directory>/sweetberry<timestemp>/summary.json`.
-  If `<directory>` does not exist, it will be created.
+    If `<directory>` is specified, this will save MEANS in json as:
+    `<directory>/sweetberry<timestamp>/summary.json`. If `<directory>` does not
+    exist, it will be created.
 
-  If `<directory>` is not specified but the flag is set, this will save MEANS in
-  json under the directory which `powerlog.py` is in:
-  `<directory of powerlog.py>/sweetberry<timestemp>/summary.json`.
+    If `<directory>` is not specified but the flag is set, this will save MEANS
+    in json under the directory which `powerlog.py` is in: `<directory of
+    powerlog.py>/sweetberry<timestamp>/summary.json`.
 
-  If `--save_stats` flag is not set, stats will not be saved.
+    If `--save_stats` flag is not set, stats will not be saved.
 
-  `--save_stats_json` is designed for `power_telemetry_logger` for easy reading
-  and writing.
+    `--save_stats_json` is designed for `power_telemetry_logger` for easy
+    reading and writing.
 
 ## Making developer changes to `powerlog.py`
 
diff --git a/extra/usb_serial/README.md b/extra/usb_serial/README.md
index 6806620a62..7cc6030d0a 100644
--- a/extra/usb_serial/README.md
+++ b/extra/usb_serial/README.md
@@ -1,5 +1,4 @@
-Case Closed Debugging Serial Consoles over USB
-==============================================
+# Case Closed Debugging Serial Consoles over USB
 
 Please see the documentation in [case_closed_debugging doc][1]