prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types.  Re-run the
formatter on the whole repository.

Change-Id: I2e1710e269896e36a8bd864cfc81ff3b1c033222
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/README.md b/README.md
index dec1d02..da95f3d 100644
--- a/README.md
+++ b/README.md
@@ -1,28 +1,37 @@
 ### Compile ipmid with default options:
+
 ```ascii
 meson builddir
 ninja -C builddir
 ```
+
 ### Compile ipmid with yocto defaults:
+
 ```ascii
 meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled
 ninja -C builddir
 ```
+
 If any of the dependencies are not found on the host system during
-configuration, meson automatically gets them via its wrap dependencies
-mentioned in `ipmid/subprojects`.
+configuration, meson automatically gets them via its wrap dependencies mentioned
+in `ipmid/subprojects`.
 
 ### Enable/Disable meson wrap feature
+
 ```ascii
 meson builddir -Dwrap_mode=nofallback
 ninja -C builddir
 ```
+
 ### Enable debug traces
+
 ```ascii
 meson builddir -Dbuildtype=debug
 ninja -C builddir
 ```
+
 ### Generate test coverage report:
+
 ```ascii
 meson builddir -Db_coverage=true -Dtests=enabled
 ninja -C builddir test
diff --git a/docs/configuration.md b/docs/configuration.md
index 4e833d9..b1656f7 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -16,9 +16,8 @@
     {"id": 0, "revision": 0, "addn_dev_support": 0,
         "manuf_id": 0, "prod_id": 0, "aux": 0}
 
-
 Each value in this JSON object should be an integer. The file is placed in
 /usr/share/ipmi-providers/ by Yocto, and will be parsed upon the first call to
-get_device_id. The data is then cached for future use. If you change the data
-at runtime, simply restart the service to see the new data fetched by a call to
+get_device_id. The data is then cached for future use. If you change the data at
+runtime, simply restart the service to see the new data fetched by a call to
 get_device_id.
diff --git a/docs/contributing.md b/docs/contributing.md
index 8ccb3ec..8be4ecf 100644
--- a/docs/contributing.md
+++ b/docs/contributing.md
@@ -1,7 +1,7 @@
 # Contributing Guidelines
 
 This document attempts to outline some basic rules to follow when contributing
-to OpenBMC's IPMI stack. It does *not* outline coding style; we follow the
+to OpenBMC's IPMI stack. It does _not_ outline coding style; we follow the
 [OpenBMC C++ style guide](https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions)
 for that.
 
@@ -9,10 +9,11 @@
 
 A good commit does exactly one thing. We prefer many small, atomic commits to
 one large commit which makes many functional changes.
- - Too large: "convert foo to new API; also fix CVE 1234 in bar"
- - Too small: "move abc.h to top of include list" and "move xyz.h to bottom of
-   include list"
- - Just right: "convert foo to new API" and "convert foo from tab to space"
+
+- Too large: "convert foo to new API; also fix CVE 1234 in bar"
+- Too small: "move abc.h to top of include list" and "move xyz.h to bottom of
+  include list"
+- Just right: "convert foo to new API" and "convert foo from tab to space"
 
 Often, creating small commits this way results in a number of commits which are
 dependent on prior commits; Gerrit handles this situation well, so feel free to
@@ -50,19 +51,19 @@
 
 Your commit message should explain:
 
- - Concisely, *what* change are you making? e.g. "docs: convert from US to UK
-   spelling" This first line of your commit message is the subject line.
- - Comprehensively, *why* are you making that change? In some cases, like a
-   small refactor, the why is fairly obvious. But in cases like the inclusion of
-   a new feature, you should explain why the feature is needed.
- - Concisely, *how* did you test? This comes in the form of a "Tested:" footer
-   in your commit message and is required for all code changes in the IPMI
-   stack. It typically consists of copy-pasted ipmitool requests and responses.
-   When possible, use the high-level ipmitool commands (e.g. "ipmitool sensor
-   read 0x1"). In cases where that's not possible, or when testing edge or error
-   cases, it is acceptable to use "ipmitool raw" - but an explanation of your
-   output is appreciated. If the change can be validated entirely by running
-   unit tests, say so in the "Tested:" tag.
+- Concisely, _what_ change are you making? e.g. "docs: convert from US to UK
+  spelling" This first line of your commit message is the subject line.
+- Comprehensively, _why_ are you making that change? In some cases, like a small
+  refactor, the why is fairly obvious. But in cases like the inclusion of a new
+  feature, you should explain why the feature is needed.
+- Concisely, _how_ did you test? This comes in the form of a "Tested:" footer in
+  your commit message and is required for all code changes in the IPMI stack. It
+  typically consists of copy-pasted ipmitool requests and responses. When
+  possible, use the high-level ipmitool commands (e.g. "ipmitool sensor read
+  0x1"). In cases where that's not possible, or when testing edge or error
+  cases, it is acceptable to use "ipmitool raw" - but an explanation of your
+  output is appreciated. If the change can be validated entirely by running unit
+  tests, say so in the "Tested:" tag.
 
 Try to include the component you are changing at the front of your subject line;
 this typically comes in the form of the class, module, handler, or directory you
@@ -75,16 +76,16 @@
 All commit messages must include a Signed-off-by line, which indicates that you
 the contributor have agreed to the Developer Certificate of Origin. This line
 must include the name you commonly use, often a given name and a family name or
-surname. (ok: A. U. Thor, Sam Samuelsson, robert a. heinlein; not ok:
-xXthorXx, Sam, RAH)
+surname. (ok: A. U. Thor, Sam Samuelsson, robert a. heinlein; not ok: xXthorXx,
+Sam, RAH)
 
 ## Sending Patches
 
-Like most projects in OpenBMC, we use Gerrit to review patches. Please check
-the MAINTAINERS file to determine who needs to approve your review in order for
-your change to be merged. Submitters will need to manually add their reviewers
-in Gerrit; reviewers are not currently added automatically. Maintainers may not
-see the commit if they have not been added to the review!
+Like most projects in OpenBMC, we use Gerrit to review patches. Please check the
+MAINTAINERS file to determine who needs to approve your review in order for your
+change to be merged. Submitters will need to manually add their reviewers in
+Gerrit; reviewers are not currently added automatically. Maintainers may not see
+the commit if they have not been added to the review!
 
 ## Pace of Review
 
@@ -96,10 +97,9 @@
 have very deep review queues already of patches which have been waiting longer
 than yours.
 
-If you feel your patch has been missed entirely, of course it's
-alright to email the maintainers (addresses available in MAINTAINERS file) - but
-a reasonable timeframe to do so is on the order of a week, not on the order of
-hours.
+If you feel your patch has been missed entirely, of course it's alright to email
+the maintainers (addresses available in MAINTAINERS file) - but a reasonable
+timeframe to do so is on the order of a week, not on the order of hours.
 
 Additionally, the IPMI stack has a set of policies for when and how changes can
 be approved; please check the MAINTAINERS file for the full list ("Change
diff --git a/docs/ipmi-network-format.md b/docs/ipmi-network-format.md
index 74dc606..bb1189b 100644
--- a/docs/ipmi-network-format.md
+++ b/docs/ipmi-network-format.md
@@ -1,74 +1,55 @@
 On platforms running AMI BMC firmware (Habanero and Firestone at the moment),
 the 'Get/Set' System Boot Options' command has been extended to allow overrides
-to the network configuration to be specified.
-In Petitboot this will cause any existing network configuration to be overridden
-by the specified configuration. The format of each IPMI request is similar to
-that of the usual boot options request, with a slightly different payload.
+to the network configuration to be specified. In Petitboot this will cause any
+existing network configuration to be overridden by the specified configuration.
+The format of each IPMI request is similar to that of the usual boot options
+request, with a slightly different payload.
 
 The start of the request is similar to a usual boot option override, but
 specifies the fields of interest differently, ie;
 
-Specify 'chassis bootdev', field 96, data1
-0x00 0x08 0x61 0x80
+Specify 'chassis bootdev', field 96, data1 0x00 0x08 0x61 0x80
 
-The rest of request format is defined by Petitboot as:
-    - 4 byte cookie value (always 0x21 0x70 0x62 0x21)
-    - 2 byte version value (always 0x00 0x01)
-    - 1 byte hardware address size (eg. 0x06 for MAC address)
-    - 1 byte IP address size (eg. 0x04 for IPv4)
-    - Hardware (MAC) address
-    - 1 byte flags for 'ignore' and 'method', where method = 0 is DHCP
-      and method = 1 is Static.
-And for static configs:
-    - IP Address
-    - 1 byte subnet value
-    - Gateway address
+The rest of request format is defined by Petitboot as: - 4 byte cookie value
+(always 0x21 0x70 0x62 0x21) - 2 byte version value (always 0x00 0x01) - 1 byte
+hardware address size (eg. 0x06 for MAC address) - 1 byte IP address size (eg.
+0x04 for IPv4) - Hardware (MAC) address - 1 byte flags for 'ignore' and
+'method', where method = 0 is DHCP and method = 1 is Static. And for static
+configs: - IP Address - 1 byte subnet value - Gateway address
 
 Describing each field in more detail:
 
-Specify 'chassis bootdev', field 96, data1
-0x00 0x08 0x61 0x80
+Specify 'chassis bootdev', field 96, data1 0x00 0x08 0x61 0x80
 
-Set a special cookie that Petitboot will recognise:
-0x21 0x70 0x62 0x21
+Set a special cookie that Petitboot will recognise: 0x21 0x70 0x62 0x21
 
-Specify the version (only 1 at the moment)
-0x00 0x01
+Specify the version (only 1 at the moment) 0x00 0x01
 
 Specify the size of the MAC address and IP address. This is used to
 differentiate between IPv4 and IPv6 addresses, or potential future support for
-Infiniband/etc.
-0x06 0x04   (6-byte MAC address, IPv4 IP address)
+Infiniband/etc. 0x06 0x04 (6-byte MAC address, IPv4 IP address)
 
-Set the hardware address of the interface you want to override, eg:
-0xf4 0x52 0x14 0xf3 0x01 0xdf
+Set the hardware address of the interface you want to override, eg: 0xf4 0x52
+0x14 0xf3 0x01 0xdf
 
 Specify 'ignore' or 'static/dynamic' flags. The second byte specifies to use
-either DHCP or static IP configuration (0 for DHCP).
-0x00 0x01
+either DHCP or static IP configuration (0 for DHCP). 0x00 0x01
 
 The below fields are required if setting a static configuration:
 
-Set the IP address you want to use, eg:
-0x0a 0x3d 0xa1 0x42
+Set the IP address you want to use, eg: 0x0a 0x3d 0xa1 0x42
 
-Set the subnet mask (short notation), eg '16':
-0x10
+Set the subnet mask (short notation), eg '16': 0x10
 
-Set the gateway address, eg:
+Set the gateway address, eg: 0x0a 0x3d 0x2 0x1
+
+All together this should look like: 0x00 0x08 0x61 0x80 0x21 0x70 0x62 0x21 0x00
+0x01 0x06 0x04 0xf4 0x52 0x14 0xf3 0x01 0xdf 0x00 0x01 0x0a 0x3d 0xa1 0x42 0x10
 0x0a 0x3d 0x2 0x1
 
-All together this should look like:
-0x00 0x08 0x61 0x80 0x21 0x70 0x62 0x21
-0x00 0x01 0x06 0x04 0xf4 0x52 0x14 0xf3
-0x01 0xdf 0x00 0x01 0x0a 0x3d 0xa1 0x42
-0x10 0x0a 0x3d 0x2 0x1
+To clear a network override, it is sufficient to clear out the request, or set a
+zero-cookie which Petitboot will reject. Eg: 0x00 0x08 0x61 0x80 0x00 0x00 0x00
+0x00
 
-To clear a network override, it is sufficient to clear out the request, or set
-a zero-cookie which Petitboot will reject. Eg:
-0x00 0x08 0x61 0x80 0x00 0x00 0x00 0x00
-
-You can 'Get' the override back with
-0x00 0x09 0x61 0x80 0x00
-which should return whatever is currently set.
-
+You can 'Get' the override back with 0x00 0x09 0x61 0x80 0x00 which should
+return whatever is currently set.
diff --git a/docs/ipmitool-commands-cheatsheet.md b/docs/ipmitool-commands-cheatsheet.md
index 050b927..b35317f 100644
--- a/docs/ipmitool-commands-cheatsheet.md
+++ b/docs/ipmitool-commands-cheatsheet.md
@@ -2,35 +2,35 @@
 
 This document is intended to provide a set of IPMI commands for quick reference.
 
-Note: If the ipmitool is on the BMC then set the interface as "-I dbus" and
-if the ipmitool is outside the BMC (i.e on the network) then set the interface as
+Note: If the ipmitool is on the BMC then set the interface as "-I dbus" and if
+the ipmitool is outside the BMC (i.e on the network) then set the interface as
 "-I lanplus".
 
 ## Network Configuration
 
 ### Set the interface mode
 
-```ipmitool lan set <channel> ipsrc static```
+`ipmitool lan set <channel> ipsrc static`
 
 ### Set the IP Address
 
-```ipmitool lan set <channel> ipaddr <x.x.x.x>```
+`ipmitool lan set <channel> ipaddr <x.x.x.x>`
 
 ### Set the network mask
 
-```ipmitool lan set <channel> netmask <x.x.x.x>```
+`ipmitool lan set <channel> netmask <x.x.x.x>`
 
 ### Set the default gateway
 
-```ipmitool lan set <channel> defgw ipaddr <x.x.x.x>```
+`ipmitool lan set <channel> defgw ipaddr <x.x.x.x>`
 
 ### Set the VLAN
 
-```ipmitool lan set <channel> vlan id <id>```
+`ipmitool lan set <channel> vlan id <id>`
 
 ### Delete the VLAN
 
-```ipmitool lan set <channel> vlan id off```
+`ipmitool lan set <channel> vlan id off`
 
-NOTE: The user can group multiple set operations since the IPMI daemon
-waits for 10 seconds after each set operation before applying the configuration.
+NOTE: The user can group multiple set operations since the IPMI daemon waits for
+10 seconds after each set operation before applying the configuration.
diff --git a/docs/oem-extension-numbering.md b/docs/oem-extension-numbering.md
index d87e0aa..cdbb112 100644
--- a/docs/oem-extension-numbering.md
+++ b/docs/oem-extension-numbering.md
@@ -1,60 +1,58 @@
 # Sketch of OpenBMC OEM message formats
 
-This document describes OEM Requests to be supported using the OpenBMC
-OEM Number.
+This document describes OEM Requests to be supported using the OpenBMC OEM
+Number.
 
 ### What's in the box?
 
-* Briefly recap OEM Extension layout as described in IPMI Specification.
-* Enumerate Command codes allocated for use with the OpenBMC OEM Number.
-* For each such code, describe the associated messages, including
+- Briefly recap OEM Extension layout as described in IPMI Specification.
+- Enumerate Command codes allocated for use with the OpenBMC OEM Number.
+- For each such code, describe the associated messages, including
   representation, function, meaning, limits, and so on.
 
 ### OEM Extensions, Block Transfer Transport Example.
 
-This table and the next briefly recap OEM Extension messages as
-described in the
-[IPMI Specification](
-http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html).
-To keep it both simple and concrete, only BT Tansport is described.
-Please consult that specification for the full story.
+This table and the next briefly recap OEM Extension messages as described in the
+[IPMI Specification](http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html).
+To keep it both simple and concrete, only BT Tansport is described. Please
+consult that specification for the full story.
 
 #### OEM Request
 
 Per section 11.1 of IPMI Spec
 
-| Bytes   | Bits | Spec ID | Value | Description
-| :---:   | ---: | :------ | :---: | :----------
-| 0       |      | Length* |   -   | Number of bytes to follow in this request
-| 1       |  2:7 | NetFn   | 0x2E  | OEM Request
-| 1       |  0:1 | LUN     |   -   | Allow any LUN
-| 2       |      | Seq*    |   -   | Per section 11.3 of IPMI Spec
-| 3       |      | Cmd     |   -   | Table 3 - OpenBMC Cmd Codes
-| 4 ~ 6   |      | OEN     | 49871 | OEM Enterprise Number
-| 2 ~ n+6 |      | Data    |   -   | n data bytes, encoding depends on Cmd
+|  Bytes  | Bits | Spec ID  | Value | Description                               |
+| :-----: | ---: | :------- | :---: | :---------------------------------------- |
+|    0    |      | Length\* |   -   | Number of bytes to follow in this request |
+|    1    |  2:7 | NetFn    | 0x2E  | OEM Request                               |
+|    1    |  0:1 | LUN      |   -   | Allow any LUN                             |
+|    2    |      | Seq\*    |   -   | Per section 11.3 of IPMI Spec             |
+|    3    |      | Cmd      |   -   | Table 3 - OpenBMC Cmd Codes               |
+|  4 ~ 6  |      | OEN      | 49871 | OEM Enterprise Number                     |
+| 2 ~ n+6 |      | Data     |   -   | n data bytes, encoding depends on Cmd     |
 
 Notes:
 
-* Length and Seq are specific to BT transport - other transports may not
-  have them.
+- Length and Seq are specific to BT transport - other transports may not have
+  them.
 
-* Serialize numbers larger than 1 byte LSB first - e.g.,
-  represent OEM Enterprise Number 49871 as `{0xcf, 0xc2, 0x00}`
+- Serialize numbers larger than 1 byte LSB first - e.g., represent OEM
+  Enterprise Number 49871 as `{0xcf, 0xc2, 0x00}`
 
 #### OEM Response
 
 Per section 11.2 of IPMI Spec
 
-| Bytes   | Bits | Spec ID | Value | Description
-| :---:   | ---: | :------ | :---: | :----------
-| 0       |      | Length* |   -   | Number of bytes to follow in this response
-| 1       | 2:7  | NetFn   | 0x2F  | OEM Response
-| 1       | 0:1  | LUN     |   -   | LUN of request to which this is a response
-| 2       |      | Seq*    |   -   | Seq of request to which this is a response
-| 3       |      | Cmd     |   -   | Cmd code of request to which this is a response
-| 4       |      | CC      |   -   | Completion code, Section 5.2 of IPMI Spec v2.0
-| 5 ~ 7   |      | OEN     | 49871 | OEM Enterprise Number
-| 8 ~ n+7 |      | Data    |   -   | n data bytes, encoding depends on Cmd
+|  Bytes  | Bits | Spec ID  | Value | Description                                     |
+| :-----: | ---: | :------- | :---: | :---------------------------------------------- |
+|    0    |      | Length\* |   -   | Number of bytes to follow in this response      |
+|    1    |  2:7 | NetFn    | 0x2F  | OEM Response                                    |
+|    1    |  0:1 | LUN      |   -   | LUN of request to which this is a response      |
+|    2    |      | Seq\*    |   -   | Seq of request to which this is a response      |
+|    3    |      | Cmd      |   -   | Cmd code of request to which this is a response |
+|    4    |      | CC       |   -   | Completion code, Section 5.2 of IPMI Spec v2.0  |
+|  5 ~ 7  |      | OEN      | 49871 | OEM Enterprise Number                           |
+| 8 ~ n+7 |      | Data     |   -   | n data bytes, encoding depends on Cmd           |
 
 ### OpenBMC OEM Cmd Codes
 
@@ -67,106 +65,106 @@
 
 These are the Command codes allocated for use with the OpenBMC OEM Number.
 
-| Cmd     | Identifier    | Description
-| :---:   | :---          | :---
-| 0       | -             | Reserved
-| 1       | gpioCmd       | GPIO Access
-| 2       | i2cCmd        | I2C Device Access
-| 3       | flashCmd      | Flash Device Access
-| 4       | fanManualCmd  | Manual Fan Controls
-| 5 ~ 255 |       -       | Unallocated
+|   Cmd   | Identifier   | Description         |
+| :-----: | :----------- | :------------------ |
+|    0    | -            | Reserved            |
+|    1    | gpioCmd      | GPIO Access         |
+|    2    | i2cCmd       | I2C Device Access   |
+|    3    | flashCmd     | Flash Device Access |
+|    4    | fanManualCmd | Manual Fan Controls |
+| 5 ~ 255 | -            | Unallocated         |
 
 ### I2C Device Access (Command 2)
 
-The next subsections describe command and response messages supporting
-the I2C Device Access extension OpenBMC OEM extension (command code 2).
+The next subsections describe command and response messages supporting the I2C
+Device Access extension OpenBMC OEM extension (command code 2).
 
 #### I2C Request Message - Overall
 
-| Bytes   | Bits | Identifier    | Description
-| :---:   | :--- | :---          | :---
-| 0       |      | bus           | Logical I2C bus.
-| 1       |      | xferFlags     | Flags for all steps.
-|         | 7    | I2cFlagUsePec | 1 => use PEC - see note.
-|         | 6:0  |               | Reserved(0)
-| 2 ~ n-1 |      |               | Step sequence - see next.
+|  Bytes  | Bits | Identifier    | Description               |
+| :-----: | :--- | :------------ | :------------------------ |
+|    0    |      | bus           | Logical I2C bus.          |
+|    1    |      | xferFlags     | Flags for all steps.      |
+|         | 7    | I2cFlagUsePec | 1 => use PEC - see note.  |
+|         | 6:0  |               | Reserved(0)               |
+| 2 ~ n-1 |      |               | Step sequence - see next. |
 
 Notes
 
-* Total length of step sequence must exactly fill request.
+- Total length of step sequence must exactly fill request.
 
-* Intent is to handle [Linux Kernel SMBus Protocol](https://www.kernel.org/doc/Documentation/i2c/smbus-protocol),
-with com generalized to m byte sequence - e.g., at24c64 uses 2 address bytes,
-and n bytes of received data,
-rather than specific operations for various sizes.
+- Intent is to handle
+  [Linux Kernel SMBus Protocol](https://www.kernel.org/doc/Documentation/i2c/smbus-protocol),
+  with com generalized to m byte sequence - e.g., at24c64 uses 2 address bytes,
+  and n bytes of received data, rather than specific operations for various
+  sizes.
 
-* Goal is to support SMBus v2 32-byte data block length limit;
-but easily supports new 4 and 8 byte transfers added for
-[SMBus v3](http://smbus.org/specs/SMBus_3_0_20141220.pdf).
+- Goal is to support SMBus v2 32-byte data block length limit; but easily
+  supports new 4 and 8 byte transfers added for
+  [SMBus v3](http://smbus.org/specs/SMBus_3_0_20141220.pdf).
 
-* PEC refers to SMBus Packet Error Check.
+- PEC refers to SMBus Packet Error Check.
 
-* SMBus address resolution, alerts, and non-standard protocols not supported.
-So for example, there is no way to insert a stop command within a transfer.
+- SMBus address resolution, alerts, and non-standard protocols not supported. So
+  for example, there is no way to insert a stop command within a transfer.
 
-* Depending on options, i2cdetect uses either quick write or 1 byte read;
-default is 1-byte read for eeprom/spd memory ranges, else quick write.
+- Depending on options, i2cdetect uses either quick write or 1 byte read;
+  default is 1-byte read for eeprom/spd memory ranges, else quick write.
 
 #### I2C Request Message - Step Properties
 
-| Bytes | Bits  | Identifier     | Description
-| :---: | :---: | :---           | :---
-| 0     |       | devAndDir
-|       |  7:1  | dev            | 7-bit I2C device address.
-|       |  0    | isRead         | 1 = read, 0 = write.
-| 1     |       | stepFlags
-|       |  7    | i2cFlagRecvLen | 1 if block read, else regular; see table.
-|       |  6    | i2cFlagNoStart | 1 to suppress I2C start.
-|       |  5:0  |                | Reserved(0)
-| 2     |       | p              | Count parameter; see table
-| 3:m+2 |       | wrPayload      | Nonempty iff p supplies nonzero m; see table.
+| Bytes | Bits | Identifier     | Description                                   |
+| :---: | :--: | :------------- | :-------------------------------------------- |
+|   0   |      | devAndDir      |
+|       | 7:1  | dev            | 7-bit I2C device address.                     |
+|       |  0   | isRead         | 1 = read, 0 = write.                          |
+|   1   |      | stepFlags      |
+|       |  7   | i2cFlagRecvLen | 1 if block read, else regular; see table.     |
+|       |  6   | i2cFlagNoStart | 1 to suppress I2C start.                      |
+|       | 5:0  |                | Reserved(0)                                   |
+|   2   |      | p              | Count parameter; see table                    |
+| 3:m+2 |      | wrPayload      | Nonempty iff p supplies nonzero m; see table. |
 
 ##### Allowed step property combinations
 
-| is_read | RecvLen | p     | Size | Description
-| :---:   | :---:   | :---: | :--- | :---
-| 0       | 0       | 0     | 3    | Quick write 0; same as write m=0 bytes.
-| 0       | 0       | m     | m+3  | Consume and write next m bytes.
-| 0       | 1       | -     | 3    | Reserved.
-| 1       | 0       | 0     | 3    | Quick write 1; same as read n=0 bytes.
-| 1       | 0       | n     | 3    | Read n bytes.
-| 1       | 1       | -     | 3    | Read count from device.
+| is_read | RecvLen |  p  | Size | Description                             |
+| :-----: | :-----: | :-: | :--- | :-------------------------------------- |
+|    0    |    0    |  0  | 3    | Quick write 0; same as write m=0 bytes. |
+|    0    |    0    |  m  | m+3  | Consume and write next m bytes.         |
+|    0    |    1    |  -  | 3    | Reserved.                               |
+|    1    |    0    |  0  | 3    | Quick write 1; same as read n=0 bytes.  |
+|    1    |    0    |  n  | 3    | Read n bytes.                           |
+|    1    |    1    |  -  | 3    | Read count from device.                 |
 
 Notes
 
-* All other combinations are reserved.
+- All other combinations are reserved.
 
-* RecvLen corresponds to Linux
-[I2C_M_RECV_LEN message flags bit](http://elixir.free-electrons.com/linux/v4.10.17/source/include/uapi/linux/i2c.h#L78)
+- RecvLen corresponds to Linux
+  [I2C_M_RECV_LEN message flags bit](http://elixir.free-electrons.com/linux/v4.10.17/source/include/uapi/linux/i2c.h#L78)
 
-* Transfers include byte count in SMBUS block modes, and
-  PEC byte when selected. Allows for use with SMBUS compatibility layer.
+- Transfers include byte count in SMBUS block modes, and PEC byte when selected.
+  Allows for use with SMBUS compatibility layer.
 
-* In case of write steps, wrPayload may include:
-    * register address byte or bytes;
-    * count byte if implementing SMBUS block or call operation;
-    * up to 32 bytes of logical payload; and
-    * PEC byte.
+- In case of write steps, wrPayload may include:
+  - register address byte or bytes;
+  - count byte if implementing SMBUS block or call operation;
+  - up to 32 bytes of logical payload; and
+  - PEC byte.
 
 #### I2C Response Message
 
-| Bytes | Identifier | Size   | Description
-| :---: | :---       | :---:  | :---
-| 0:n-1 | rd_data    | 0 ~ 34 | byte sequence read
+| Bytes | Identifier |  Size  | Description        |
+| :---: | :--------- | :----: | :----------------- |
+| 0:n-1 | rd_data    | 0 ~ 34 | byte sequence read |
 
 Notes
 
-* Maximum logical payload is 32.
+- Maximum logical payload is 32.
 
-* In the unlikely event a transfer specifies multiple read steps,
-  all bytes read are simply concatenated in the order read.
+- In the unlikely event a transfer specifies multiple read steps, all bytes read
+  are simply concatenated in the order read.
 
-* However, maximum reply limit is sized for the largest single read.
+- However, maximum reply limit is sized for the largest single read.
 
-* RecvLen case w/ PEC can return up to 34 bytes:
-    count + payload + PEC
+- RecvLen case w/ PEC can return up to 34 bytes: count + payload + PEC
diff --git a/docs/testing.md b/docs/testing.md
index f5ed04b..2fa3602 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -4,21 +4,21 @@
 
 For the purposes of this tutorial, we'll be setting up an environment in Docker.
 Docker is handy because it's fairly portable, and won't interfere with the rest
-of your machine setup. It also offers a strong guarantee that you're testing
-the same way that others working on the project are. Finally, we can get away
-with using the same Docker image that's run by the OpenBMC continuous
-integration bot, so we have even more confidence that we're running relevant
-tests the way they'd be run upstream.
+of your machine setup. It also offers a strong guarantee that you're testing the
+same way that others working on the project are. Finally, we can get away with
+using the same Docker image that's run by the OpenBMC continuous integration
+bot, so we have even more confidence that we're running relevant tests the way
+they'd be run upstream.
 
 ### Install Docker
 
 Installation of Docker CE (Community Edition) varies by platform, and may differ
 in your organization. But the
-[Docker Docs](https://docs.docker.com/v17.12/install) are a good place to
-start looking.
+[Docker Docs](https://docs.docker.com/v17.12/install) are a good place to start
+looking.
 
-Check that the installation was successful by running `sudo docker run
-hello-world`.
+Check that the installation was successful by running
+`sudo docker run hello-world`.
 
 ### Download OpenBMC Continuous Integration Image
 
@@ -34,10 +34,10 @@
 ### Add `phosphor-host-ipmid`
 
 We also need to put a copy of the project you want to test against here. But
-you've probably got a copy checked out already, so we're going to make a
-*git worktree*. You can read more about those by running `git help worktree`,
-but the basic idea is that it's like having a second copy of your repo - but the
-second copy is in sync with your main copy, knows about your local branches, and
+you've probably got a copy checked out already, so we're going to make a _git
+worktree_. You can read more about those by running `git help worktree`, but the
+basic idea is that it's like having a second copy of your repo - but the second
+copy is in sync with your main copy, knows about your local branches, and
 protects you from checking out the same branch in two places.
 
 Your new worktree doesn't know about any untracked files you have in your main
@@ -85,11 +85,11 @@
 git commit -m "mount phosphor-host-ipmid"
 ```
 
-NOTE: There are other ways to do this besides a worktree; other approaches
-trade the cruft of mounting extra paths to the Docker container for different
-cruft:
+NOTE: There are other ways to do this besides a worktree; other approaches trade
+the cruft of mounting extra paths to the Docker container for different cruft:
 
 You can create a local upstream:
+
 ```shell
 cd openbmc-ci-tests
 mkdir phosphor-host-ipmid
@@ -99,8 +99,10 @@
 git remote add /path/to/openbmc-ci-tests/phosphor-host-ipmid ci
 git push ci
 ```
-This method would require you to push your topic branch to `ci` and then `git
-checkout` the appropriate branch every time you switched topics:
+
+This method would require you to push your topic branch to `ci` and then
+`git checkout` the appropriate branch every time you switched topics:
+
 ```shell
 cd /my/dir/for/phosphor-host-ipmid
 git commit -m "my changes to be tested"
@@ -318,8 +320,8 @@
 The `get_record_id()` tests are identical, except that they are testing the
 Record ID field. They will not be duplicated here.
 
-Finally, we'll need to add the new tests to `test/Makefile.am`. You can mimic other
-existing test setups:
+Finally, we'll need to add the new tests to `test/Makefile.am`. You can mimic
+other existing test setups:
 
 ```make
 # Build/add sensorhandler_unittest to test suite
diff --git a/scripts/entity-example.md b/scripts/entity-example.md
index 98dbade..c2c6f4b 100644
--- a/scripts/entity-example.md
+++ b/scripts/entity-example.md
@@ -1,4 +1,5 @@
-If your platform requires the entity container map, you can provide a json file of the format:
+If your platform requires the entity container map, you can provide a json file
+of the format:
 
 ```
 [
diff --git a/scripts/fru-read-example.yaml b/scripts/fru-read-example.yaml
index 41e1598..a186794 100644
--- a/scripts/fru-read-example.yaml
+++ b/scripts/fru-read-example.yaml
@@ -11,129 +11,129 @@
 #       d-bus Properties
 #         IPMI Fru mapping
 0:
-  /system:
-    entityID: 23
-    entityInstance: 1
-    interfaces:
-      xyz.openbmc_project.Inventory.Item:
-        PrettyName:
-          IPMIFruProperty: Product Name
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Asset:
-        Manufacturer:
-          IPMIFruProperty: Manufacturer
-          IPMIFruSection: Product
-        PartNumber:
-          IPMIFruProperty: Part Number
-          IPMIFruSection: Product
-        SerialNumber:
-          IPMIFruProperty: Serial Number
-          IPMIFruSection: Product
-        BuildDate:
-          IPMIFruProperty: Mfg Date
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Revision:
-        Version:
-          IPMIFruProperty: Version
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Item.System:
+    /system:
+        entityID: 23
+        entityInstance: 1
+        interfaces:
+            xyz.openbmc_project.Inventory.Item:
+                PrettyName:
+                    IPMIFruProperty: Product Name
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Asset:
+                Manufacturer:
+                    IPMIFruProperty: Manufacturer
+                    IPMIFruSection: Product
+                PartNumber:
+                    IPMIFruProperty: Part Number
+                    IPMIFruSection: Product
+                SerialNumber:
+                    IPMIFruProperty: Serial Number
+                    IPMIFruSection: Product
+                BuildDate:
+                    IPMIFruProperty: Mfg Date
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Revision:
+                Version:
+                    IPMIFruProperty: Version
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Item.System:
 1:
-  /system/chassis/motherboard/dimm0:
-    entityID: 32
-    entityInstance: 1
-    interfaces:
-      xyz.openbmc_project.Inventory.Item:
-        PrettyName:
-          IPMIFruProperty: Product Name
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Asset:
-        Manufacturer:
-          IPMIFruProperty: Manufacturer
-          IPMIFruSection: Product
-        BuildDate:
-          IPMIFruProperty: Mfg Date
-          IPMIFruSection: Product
-        SerialNumber:
-          IPMIFruProperty: Serial Number
-          IPMIFruSection: Product
-        PartNumber:
-          IPMIFruProperty: Part Number
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Revision:
-        Version:
-          IPMIFruProperty: Version
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Item.Dimm:
+    /system/chassis/motherboard/dimm0:
+        entityID: 32
+        entityInstance: 1
+        interfaces:
+            xyz.openbmc_project.Inventory.Item:
+                PrettyName:
+                    IPMIFruProperty: Product Name
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Asset:
+                Manufacturer:
+                    IPMIFruProperty: Manufacturer
+                    IPMIFruSection: Product
+                BuildDate:
+                    IPMIFruProperty: Mfg Date
+                    IPMIFruSection: Product
+                SerialNumber:
+                    IPMIFruProperty: Serial Number
+                    IPMIFruSection: Product
+                PartNumber:
+                    IPMIFruProperty: Part Number
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Revision:
+                Version:
+                    IPMIFruProperty: Version
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Item.Dimm:
 2:
-  /system/chassis/motherboard/dimm1:
-    entityID: 32
-    entityInstance: 2
-    interfaces:
-      xyz.openbmc_project.Inventory.Item:
-        PrettyName:
-          IPMIFruProperty: Product Name
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Asset:
-        Manufacturer:
-          IPMIFruProperty: Manufacturer
-          IPMIFruSection: Product
-        BuildDate:
-          IPMIFruProperty: Mfg Date
-          IPMIFruSection: Product
-        SerialNumber:
-          IPMIFruProperty: Serial Number
-          IPMIFruSection: Product
-        PartNumber:
-          IPMIFruProperty: Part Number
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Decorator.Revision:
-        Version:
-          IPMIFruProperty: Version
-          IPMIFruSection: Product
-      xyz.openbmc_project.Inventory.Item.Dimm:
+    /system/chassis/motherboard/dimm1:
+        entityID: 32
+        entityInstance: 2
+        interfaces:
+            xyz.openbmc_project.Inventory.Item:
+                PrettyName:
+                    IPMIFruProperty: Product Name
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Asset:
+                Manufacturer:
+                    IPMIFruProperty: Manufacturer
+                    IPMIFruSection: Product
+                BuildDate:
+                    IPMIFruProperty: Mfg Date
+                    IPMIFruSection: Product
+                SerialNumber:
+                    IPMIFruProperty: Serial Number
+                    IPMIFruSection: Product
+                PartNumber:
+                    IPMIFruProperty: Part Number
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Decorator.Revision:
+                Version:
+                    IPMIFruProperty: Version
+                    IPMIFruSection: Product
+            xyz.openbmc_project.Inventory.Item.Dimm:
 3:
-  /system/chassis/motherboard/cpu0:
-    entityID: 3
-    entityInstance: 1
-    interfaces:
-      xyz.openbmc_project.Inventory.Item:
-        PrettyName:
-          IPMIFruProperty: Product Name
-          IPMIFruSection: Board
-      xyz.openbmc_project.Inventory.Decorator.Asset:
-        BuildDate:
-          IPMIFruProperty: Mfg Date
-          IPMIFruSection: Board
-        SerialNumber:
-          IPMIFruProperty: Serial Number
-          IPMIFruSection: Board
-        PartNumber:
-          IPMIFruProperty: Part Number
-          IPMIFruSection: Board
-        Manufacturer:
-          IPMIFruProperty: Manufacturer
-          IPMIFruSection: Board
-      xyz.openbmc_project.Inventory.Item.Cpu:
+    /system/chassis/motherboard/cpu0:
+        entityID: 3
+        entityInstance: 1
+        interfaces:
+            xyz.openbmc_project.Inventory.Item:
+                PrettyName:
+                    IPMIFruProperty: Product Name
+                    IPMIFruSection: Board
+            xyz.openbmc_project.Inventory.Decorator.Asset:
+                BuildDate:
+                    IPMIFruProperty: Mfg Date
+                    IPMIFruSection: Board
+                SerialNumber:
+                    IPMIFruProperty: Serial Number
+                    IPMIFruSection: Board
+                PartNumber:
+                    IPMIFruProperty: Part Number
+                    IPMIFruSection: Board
+                Manufacturer:
+                    IPMIFruProperty: Manufacturer
+                    IPMIFruSection: Board
+            xyz.openbmc_project.Inventory.Item.Cpu:
 4:
-  /system/chassis/motherboard/cpu1:
-    entityID: 3
-    entityInstance: 2
-    interfaces:
-      xyz.openbmc_project.Inventory.Item:
-        PrettyName:
-          IPMIFruProperty: Product Name
-          IPMIFruSection: Board
-      xyz.openbmc_project.Inventory.Decorator.Asset:
-        BuildDate:
-          IPMIFruProperty: Mfg Date
-          IPMIFruSection: Board
-        SerialNumber:
-          IPMIFruProperty: Serial Number
-          IPMIFruSection: Board
-        PartNumber:
-          IPMIFruProperty: Part Number
-          IPMIFruSection: Board
-        Manufacturer:
-          IPMIFruProperty: Manufacturer
-          IPMIFruSection: Board
-      xyz.openbmc_project.Inventory.Item.Cpu:
+    /system/chassis/motherboard/cpu1:
+        entityID: 3
+        entityInstance: 2
+        interfaces:
+            xyz.openbmc_project.Inventory.Item:
+                PrettyName:
+                    IPMIFruProperty: Product Name
+                    IPMIFruSection: Board
+            xyz.openbmc_project.Inventory.Decorator.Asset:
+                BuildDate:
+                    IPMIFruProperty: Mfg Date
+                    IPMIFruSection: Board
+                SerialNumber:
+                    IPMIFruProperty: Serial Number
+                    IPMIFruSection: Board
+                PartNumber:
+                    IPMIFruProperty: Part Number
+                    IPMIFruSection: Board
+                Manufacturer:
+                    IPMIFruProperty: Manufacturer
+                    IPMIFruSection: Board
+            xyz.openbmc_project.Inventory.Item.Cpu:
diff --git a/scripts/inventory-sensor-example.yaml b/scripts/inventory-sensor-example.yaml
index 7ff78fb..5dde38f 100644
--- a/scripts/inventory-sensor-example.yaml
+++ b/scripts/inventory-sensor-example.yaml
@@ -1,340 +1,340 @@
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm0:
-  sensorID: 0xa6
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xa6
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm1:
-  sensorID: 0xa8
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xa8
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm10:
-  sensorID: 0xba
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xba
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm11:
-  sensorID: 0xbc
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xbc
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm12:
-  sensorID: 0xbe
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xbe
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm13:
-  sensorID: 0xc0
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xc0
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm14:
-  sensorID: 0xc2
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xc2
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm15:
-  sensorID: 0xc4
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xc4
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm2:
-  sensorID: 0xaa
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xaa
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm3:
-  sensorID: 0xac
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xac
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm4:
-  sensorID: 0xae
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xae
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm5:
-  sensorID: 0xb0
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xb0
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm6:
-  sensorID: 0xb2
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xb2
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm7:
-  sensorID: 0xb4
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xb4
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm8:
-  sensorID: 0xb6
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xb6
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/dimm9:
-  sensorID: 0xb8
-  sensorType: 0x0C
-  eventReadingType: 0x6F
-  offset: 0x04
+    sensorID: 0xb8
+    sensorType: 0x0C
+    eventReadingType: 0x6F
+    offset: 0x04
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0:
-  sensorID: 0x5a
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x5a
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core0:
-  sensorID: 0x12
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x12
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core1:
-  sensorID: 0x15
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x15
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core2:
-  sensorID: 0x18
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x18
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core3:
-  sensorID: 0x1b
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x1b
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core4:
-  sensorID: 0x1e
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x1e
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core5:
-  sensorID: 0x21
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x21
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core6:
-  sensorID: 0x24
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x24
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core7:
-  sensorID: 0x27
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x27
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core8:
-  sensorID: 0x2a
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x2a
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core9:
-  sensorID: 0x2d
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x2d
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core10:
-  sensorID: 0x30
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x30
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core11:
-  sensorID: 0x33
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x33
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core12:
-  sensorID: 0x36
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x36
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core13:
-  sensorID: 0x39
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x39
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core14:
-  sensorID: 0x3c
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x3c
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core15:
-  sensorID: 0x3f
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x3f
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core16:
-  sensorID: 0x42
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x42
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core17:
-  sensorID: 0x45
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x45
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core18:
-  sensorID: 0x48
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x48
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core19:
-  sensorID: 0x4b
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x4b
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core20:
-  sensorID: 0x4e
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x4e
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core21:
-  sensorID: 0x51
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x51
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core22:
-  sensorID: 0x54
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x54
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu0/core23:
-  sensorID: 0x57
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x57
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1:
-  sensorID: 0xa4
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0xa4
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core0:
-  sensorID: 0x5c
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x5c
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core1:
-  sensorID: 0x5f
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x5f
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core2:
-  sensorID: 0x62
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x62
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core3:
-  sensorID: 0x65
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x65
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core4:
-  sensorID: 0x68
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x68
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core5:
-  sensorID: 0x6b
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x6b
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core6:
-  sensorID: 0x6e
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x6e
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core7:
-  sensorID: 0x71
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x71
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core8:
-  sensorID: 0x74
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x74
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core9:
-  sensorID: 0x77
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x77
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core10:
-  sensorID: 0x7a
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x7a
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core11:
-  sensorID: 0x7d
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x7d
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core12:
-  sensorID: 0x80
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x80
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core13:
-  sensorID: 0x83
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x83
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core14:
-  sensorID: 0x86
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x86
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core15:
-  sensorID: 0x89
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x89
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core16:
-  sensorID: 0x8c
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x8c
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core17:
-  sensorID: 0x8f
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x8f
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core18:
-  sensorID: 0x92
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x92
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core19:
-  sensorID: 0x95
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x95
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core20:
-  sensorID: 0x98
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x98
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core21:
-  sensorID: 0x9b
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x9b
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core22:
-  sensorID: 0x9e
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0x9e
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard/cpu1/core23:
-  sensorID: 0xa1
-  sensorType: 0x07
-  eventReadingType: 0x6F
-  offset: 0x08
+    sensorID: 0xa1
+    sensorType: 0x07
+    eventReadingType: 0x6F
+    offset: 0x08
 /xyz/openbmc_project/inventory/system/chassis/motherboard:
-  sensorID: 0x0c
-  sensorType: 0xC7
-  eventReadingType: 0x03
-  offset: 0x00
+    sensorID: 0x0c
+    sensorType: 0xC7
+    eventReadingType: 0x03
+    offset: 0x00
 /xyz/openbmc_project/inventory/system:
-  sensorID: 0x01
-  sensorType: 0x12
-  eventReadingType: 0x6F
-  offset: 0x02
+    sensorID: 0x01
+    sensorType: 0x12
+    eventReadingType: 0x6F
+    offset: 0x02
diff --git a/scripts/sensor-example.yaml b/scripts/sensor-example.yaml
index 869702e..89430e4 100644
--- a/scripts/sensor-example.yaml
+++ b/scripts/sensor-example.yaml
@@ -1,194 +1,194 @@
 # Sensor id is the key
 0x60:
-  sensorType: 0x07
-  sensorReadingType: 0x6F
-  # A "set" operation on this sensor should update this d-bus path.
-  # If the path is not specified, an MRW parser will try to determine the path
-  # based on the sensor id, on MRW based systems.  This typically happens for
-  # inventory items.
-  path: /org/open_power/control/occ0
-  # The interface that exposes method(s) to update the path above.
-  serviceInterface: org.freedesktop.DBus.Properties
-  # Where the sensor value is represented - assertion bits/reading/event data
-  readingType: assertion
-  # indicate if a sensor is READ/WRITE/RW.
-  # This particular sensor read and write operation is allowed
-  mutability: Mutability::Write|Mutability::Read
-  # Sensor name would be occ0
-  sensorNamePattern: nameLeaf
-  eventType: 0x6F
-  # All the d-bus interfaces : properties that must be updated for this path
-  interfaces:
-    # One or more interface dict entries
-    org.open_power.OCC.Status:
-      OccActive:
-        Offsets:
-          # Sensor type specific offset
-          0x06:
-            # OccActive is a boolean
-            type: "bool"
-            # If offset 0x06 is asserted, set OccActive as false.
-            assert: "false"
-            deassert: "true"
+    sensorType: 0x07
+    sensorReadingType: 0x6F
+    # A "set" operation on this sensor should update this d-bus path.
+    # If the path is not specified, an MRW parser will try to determine the path
+    # based on the sensor id, on MRW based systems.  This typically happens for
+    # inventory items.
+    path: /org/open_power/control/occ0
+    # The interface that exposes method(s) to update the path above.
+    serviceInterface: org.freedesktop.DBus.Properties
+    # Where the sensor value is represented - assertion bits/reading/event data
+    readingType: assertion
+    # indicate if a sensor is READ/WRITE/RW.
+    # This particular sensor read and write operation is allowed
+    mutability: Mutability::Write|Mutability::Read
+    # Sensor name would be occ0
+    sensorNamePattern: nameLeaf
+    eventType: 0x6F
+    # All the d-bus interfaces : properties that must be updated for this path
+    interfaces:
+        # One or more interface dict entries
+        org.open_power.OCC.Status:
+            OccActive:
+                Offsets:
+                    # Sensor type specific offset
+                    0x06:
+                        # OccActive is a boolean
+                        type: "bool"
+                        # If offset 0x06 is asserted, set OccActive as false.
+                        assert: "false"
+                        deassert: "true"
 
 0x61:
-  sensorType: 0x04
-  sensorReadingType: 0x6F
-  # Inventory paths intentionally leave out the inventory root,
-  # /xyz/openbmc_project/inventory, because phosphor-inventory-manager
-  # adds that.
-  path: /system/chassis/motherboard/dimm1
-  serviceInterface: xyz.openbmc_project.Inventory.Manager
-  readingType: assertion
-  mutability: Mutability::Write|Mutability::Read
-  sensorNamePattern: nameLeaf
-  interfaces:
-    xyz.openbmc_project.State.Decorator.OperationalStatus:
-      Functional:
-        #Offsets contain the offsets in the sensor data.
-        Offsets:
-          0x06:
-            assert: true
-            deassert: false
-            type: bool
-        #Prereqs are pre-requisites for this property value to be true.
-        Prereqs:
-          0x04:
-            assert: false
-            deassert: true
-            type: bool
-    xyz.openbmc_project.Inventory.Item:
-      Present:
-        Offsets:
-          0x04:
-            assert: false
-            deassert: true
-            type: bool
+    sensorType: 0x04
+    sensorReadingType: 0x6F
+    # Inventory paths intentionally leave out the inventory root,
+    # /xyz/openbmc_project/inventory, because phosphor-inventory-manager
+    # adds that.
+    path: /system/chassis/motherboard/dimm1
+    serviceInterface: xyz.openbmc_project.Inventory.Manager
+    readingType: assertion
+    mutability: Mutability::Write|Mutability::Read
+    sensorNamePattern: nameLeaf
+    interfaces:
+        xyz.openbmc_project.State.Decorator.OperationalStatus:
+            Functional:
+                #Offsets contain the offsets in the sensor data.
+                Offsets:
+                    0x06:
+                        assert: true
+                        deassert: false
+                        type: bool
+                #Prereqs are pre-requisites for this property value to be true.
+                Prereqs:
+                    0x04:
+                        assert: false
+                        deassert: true
+                        type: bool
+        xyz.openbmc_project.Inventory.Item:
+            Present:
+                Offsets:
+                    0x04:
+                        assert: false
+                        deassert: true
+                        type: bool
 
 0x63:
-  interfaces:
-    xyz.openbmc_project.Control.Boot.RebootAttempts:
-      AttemptsLeft:
-        Offsets:
-          0xFF:
-            type: uint32_t
-  path: /xyz/openbmc_project/state/host0
-  # A special case of assertion, where the entire assert bitfield
-  # serves as the value, or reading. Hence, the offset above is intentionally
-  # 0xFF, to indicate not to check any specific bits in the assertion.
-  readingType: readingAssertion
-  # Sensor name would be AttemptsLeft
-  sensorNamePattern: nameProperty
-  sensorReadingType: 0x6F
-  mutability: Mutability::Write|Mutability::Read
-  sensorType: 0xC3
-  serviceInterface: org.freedesktop.DBus.Properties
+    interfaces:
+        xyz.openbmc_project.Control.Boot.RebootAttempts:
+            AttemptsLeft:
+                Offsets:
+                    0xFF:
+                        type: uint32_t
+    path: /xyz/openbmc_project/state/host0
+    # A special case of assertion, where the entire assert bitfield
+    # serves as the value, or reading. Hence, the offset above is intentionally
+    # 0xFF, to indicate not to check any specific bits in the assertion.
+    readingType: readingAssertion
+    # Sensor name would be AttemptsLeft
+    sensorNamePattern: nameProperty
+    sensorReadingType: 0x6F
+    mutability: Mutability::Write|Mutability::Read
+    sensorType: 0xC3
+    serviceInterface: org.freedesktop.DBus.Properties
 
 0x62:
-  interfaces:
-    xyz.openbmc_project.Control.Boot.RebootAttempts:
-      AttemptsLeft:
-        Offsets:
-          0xFF:
-            type: uint32_t
-  path: /xyz/openbmc_project/state/host1
-  readingType: readingAssertion
-  # set an explicit name for the sensor
-  sensorName: RebootAttempts
-  sensorReadingType: 0x6F
-  mutability: Mutability::Write|Mutability::Read
-  sensorType: 0xC3
-  serviceInterface: org.freedesktop.DBus.Properties
+    interfaces:
+        xyz.openbmc_project.Control.Boot.RebootAttempts:
+            AttemptsLeft:
+                Offsets:
+                    0xFF:
+                        type: uint32_t
+    path: /xyz/openbmc_project/state/host1
+    readingType: readingAssertion
+    # set an explicit name for the sensor
+    sensorName: RebootAttempts
+    sensorReadingType: 0x6F
+    mutability: Mutability::Write|Mutability::Read
+    sensorType: 0xC3
+    serviceInterface: org.freedesktop.DBus.Properties
 
 0xD0:
-  sensorType: 0x01
-  path: /xyz/openbmc_project/sensors/temperature/fleeting0
-  sensorReadingType: 0x01
-  multiplierM: 511
-  offsetB: 0
-  bExp: 0
-  # Result exponent field in Type 1 SDR(2's complement, signed)
-  rExp: 0
-  # Applies for analog sensors, the actual reading value for the sensor is
-  # Value * 10^N
-  scale: -3
-  # Indicate Analog Data Format, Rate unit, Modifier unit and Percentage
-  sensorUnits1 : 0x80
-  mutability: Mutability::Write|Mutability::Read
-  serviceInterface: org.freedesktop.DBus.Properties
-  readingType: readingData
-  sensorNamePattern: nameLeaf
-  interfaces:
-    xyz.openbmc_project.Sensor.Value:
-      Value:
-        Offsets:
-          0xFF:
-            type: int64_t
+    sensorType: 0x01
+    path: /xyz/openbmc_project/sensors/temperature/fleeting0
+    sensorReadingType: 0x01
+    multiplierM: 511
+    offsetB: 0
+    bExp: 0
+    # Result exponent field in Type 1 SDR(2's complement, signed)
+    rExp: 0
+    # Applies for analog sensors, the actual reading value for the sensor is
+    # Value * 10^N
+    scale: -3
+    # Indicate Analog Data Format, Rate unit, Modifier unit and Percentage
+    sensorUnits1: 0x80
+    mutability: Mutability::Write|Mutability::Read
+    serviceInterface: org.freedesktop.DBus.Properties
+    readingType: readingData
+    sensorNamePattern: nameLeaf
+    interfaces:
+        xyz.openbmc_project.Sensor.Value:
+            Value:
+                Offsets:
+                    0xFF:
+                        type: int64_t
 
 0x54:
-  sensorType: 0x07
-  path: /system/chassis/motherboard/cpu0/core22
-  sensorReadingType: 0x6F
-  serviceInterface: xyz.openbmc_project.Inventory.Manager
-  readingType: assertion
-  mutability: Mutability::Write|Mutability::Read
-  # Sensor name would be cpu0_core22
-  sensorNamePattern: nameParentLeaf
-  interfaces:
-    xyz.openbmc_project.State.Decorator.OperationalStatus:
-      Functional:
-        Offsets:
-          0x08:
-            assert: false
-            deassert: true
-            type: bool
-        Prereqs:
-          0x07:
-            assert: true
-            deassert: false
-    xyz.openbmc_project.Inventory.Item:
-      Present:
-        Offsets:
-          0x07:
-            assert: true
-            deassert: false
-            #The update will be skipped based on the value of skipOn
-            #in this case if offset 0x07 is deasserted
-            #the update will be skipped.
-            skipOn: deassert
-            type: bool
+    sensorType: 0x07
+    path: /system/chassis/motherboard/cpu0/core22
+    sensorReadingType: 0x6F
+    serviceInterface: xyz.openbmc_project.Inventory.Manager
+    readingType: assertion
+    mutability: Mutability::Write|Mutability::Read
+    # Sensor name would be cpu0_core22
+    sensorNamePattern: nameParentLeaf
+    interfaces:
+        xyz.openbmc_project.State.Decorator.OperationalStatus:
+            Functional:
+                Offsets:
+                    0x08:
+                        assert: false
+                        deassert: true
+                        type: bool
+                Prereqs:
+                    0x07:
+                        assert: true
+                        deassert: false
+        xyz.openbmc_project.Inventory.Item:
+            Present:
+                Offsets:
+                    0x07:
+                        assert: true
+                        deassert: false
+                        #The update will be skipped based on the value of skipOn
+                        #in this case if offset 0x07 is deasserted
+                        #the update will be skipped.
+                        skipOn: deassert
+                        type: bool
 
 0xC5:
-  sensorType: 0x17
-  path: /system/chassis/motherboard/gv100card0
-  sensorReadingType: 1
-  serviceInterface: xyz.openbmc_project.Inventory.Manager
-  readingType: assertion
-  mutability: Mutability::Write|Mutability::Read
-  sensorNamePattern: nameLeaf
-  interfaces:
-    xyz.openbmc_project.Inventory.Decorator.Replaceable:
-      FieldReplaceable:
-        Offsets:
-          7:
-            assert: true
-            type: bool
-    xyz.openbmc_project.Inventory.Item:
-      Present:
-        Offsets:
-          7:
-            assert: true
-            deassert: false
-            type: bool
-    # Example of an interface with no attached properties
-    xyz.openbmc_project.Inventory.Item.Accelerator:
-    xyz.openbmc_project.State.Decorator.OperationalStatus:
-      Functional:
-        Offsets:
-          8:
-            assert: false
-            type: bool
-        Prereqs:
-          7:
-            assert: true
-            type: bool
+    sensorType: 0x17
+    path: /system/chassis/motherboard/gv100card0
+    sensorReadingType: 1
+    serviceInterface: xyz.openbmc_project.Inventory.Manager
+    readingType: assertion
+    mutability: Mutability::Write|Mutability::Read
+    sensorNamePattern: nameLeaf
+    interfaces:
+        xyz.openbmc_project.Inventory.Decorator.Replaceable:
+            FieldReplaceable:
+                Offsets:
+                    7:
+                        assert: true
+                        type: bool
+        xyz.openbmc_project.Inventory.Item:
+            Present:
+                Offsets:
+                    7:
+                        assert: true
+                        deassert: false
+                        type: bool
+        # Example of an interface with no attached properties
+        xyz.openbmc_project.Inventory.Item.Accelerator:
+        xyz.openbmc_project.State.Decorator.OperationalStatus:
+            Functional:
+                Offsets:
+                    8:
+                        assert: false
+                        type: bool
+                Prereqs:
+                    7:
+                        assert: true
+                        type: bool
diff --git a/xyz/openbmc_project/Ipmi/Internal/SoftPowerOff.interface.yaml b/xyz/openbmc_project/Ipmi/Internal/SoftPowerOff.interface.yaml
index 2bae9a7..9e34734 100644
--- a/xyz/openbmc_project/Ipmi/Internal/SoftPowerOff.interface.yaml
+++ b/xyz/openbmc_project/Ipmi/Internal/SoftPowerOff.interface.yaml
@@ -1,36 +1,35 @@
 description: >
-  Implement the Soft Power Off function.
-  On receiving the SMS_ATTN from BMC, Host will respond with a
-  GetMessageFlags command and the BMC will respond with a static
-  data indicating that Event Message Buffer is full. Host then sends
-  'ReadEvent' command and BMC responds with an architected packet
-  mentioning that the type is SOFT_OFF. Host then goes ahead and starts
-  to quiesce. Once that is done, Host will send a hard
-  power off command to BMC and then BMC will issue a hard power off.
+    Implement the Soft Power Off function. On receiving the SMS_ATTN from BMC,
+    Host will respond with a GetMessageFlags command and the BMC will respond
+    with a static data indicating that Event Message Buffer is full. Host then
+    sends 'ReadEvent' command and BMC responds with an architected packet
+    mentioning that the type is SOFT_OFF. Host then goes ahead and starts to
+    quiesce. Once that is done, Host will send a hard power off command to BMC
+    and then BMC will issue a hard power off.
 
 properties:
     - name: ResponseReceived
       type: enum[self.HostResponse]
       default: NotApplicable
       description: >
-        When the response is received for 'SMS_ATN', this is set to
-        'SoftOffReceived' and is set to 'HostShutdown' when Host
-        sends a Power Off request.
+          When the response is received for 'SMS_ATN', this is set to
+          'SoftOffReceived' and is set to 'HostShutdown' when Host sends a Power
+          Off request.
 
 enumerations:
     - name: HostResponse
       description: >
-        Possible response types from Host for a Soft Power Off function.
+          Possible response types from Host for a Soft Power Off function.
       values:
-        - name: NotApplicable
-          description: >
-            Default initial value.
-        - name: SoftOffReceived
-          description: >
-            Host has received the SMS_ATN from BMC indicating that
-            Host needs to do a Soft Power Off.
-        - name: HostShutdown
-          description: >
-            Host has sufficiently quiesced and acknowledged the shutdown
-            request such that the hardware shutdown sequence can safely
-            be performed.
+          - name: NotApplicable
+            description: >
+                Default initial value.
+          - name: SoftOffReceived
+            description: >
+                Host has received the SMS_ATN from BMC indicating that Host
+                needs to do a Soft Power Off.
+          - name: HostShutdown
+            description: >
+                Host has sufficiently quiesced and acknowledged the shutdown
+                request such that the hardware shutdown sequence can safely be
+                performed.