diff --git a/.editorconfig b/.editorconfig
deleted file mode 100644
index 4a4080a..0000000
--- a/.editorconfig
+++ /dev/null
@@ -1,6 +0,0 @@
-[*]
-indent_style = space
-indent_size = 4
-# Config for shfmt
-switch_case_indent = true
-space_redirects = true
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
index f5cfbee..15c9e81 100644
--- a/.markdownlint.yaml
+++ b/.markdownlint.yaml
@@ -1,5 +1,3 @@
 default: true
 MD024:
     siblings_only: true
-MD013:
-    stern: true
diff --git a/.prettierrc.yaml b/.prettierrc.yaml
index f07fbdd..a69b879 100644
--- a/.prettierrc.yaml
+++ b/.prettierrc.yaml
@@ -1,3 +1,7 @@
-tabWidth: 2
+tabWidth: 4
+printWidth: 80
+proseWrap: "always"
 overrides:
-    - { "files": "*.yaml", "options": { "tabWidth": 4 } }
+    - files: "*.md"
+      options:
+          tabWidth: 2
diff --git a/README.md b/README.md
index d08f59a..50704a5 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # phosphor-dbus-interfaces
 
-YAML descriptors of standard D-Bus interfaces.
-The format is described by the [sdbusplus binding generation tool sdbus++][].
+YAML descriptors of standard D-Bus interfaces. The format is described by the
+[sdbusplus binding generation tool sdbus++][].
 
 Before defining a new D-Bus interface or modifying an existing one, please read
 through the documented set of the common [requirements and expectations][].
@@ -11,10 +11,10 @@
 This project can be built with `meson`. The typical `meson` workflow is:
 `meson builddir && ninja -C builddir`.
 
-The meson files used to handle the YAML files are automatically generated
-and found under the `gen` subdirectory. When adding or removing YAML files,
-this must be regenerated. This can be done with the helper script found
-in the `gen` subdirectory: `cd gen && ./regenerate-meson`.
+The meson files used to handle the YAML files are automatically generated and
+found under the `gen` subdirectory. When adding or removing YAML files, this
+must be regenerated. This can be done with the helper script found in the `gen`
+subdirectory: `cd gen && ./regenerate-meson`.
 
 ## Configuration
 
@@ -28,5 +28,6 @@
 
 ## References
 
-[sdbusplus binding generation tool sdbus++]: https://github.com/openbmc/sdbusplus/blob/master/README.md#binding-generation-tool
+[sdbusplus binding generation tool sdbus++]:
+  https://github.com/openbmc/sdbusplus/blob/master/README.md#binding-generation-tool
 [requirements and expectations]: requirements.md
diff --git a/requirements.md b/requirements.md
index c890751..cca9e66 100644
--- a/requirements.md
+++ b/requirements.md
@@ -1,8 +1,8 @@
 # Requirements and Expectations for dbus interfaces
 
-This document outlines requirements and expectations for dbus interfaces.
-These are usually specified as requirements due to our dbus architecture
-or for consistency in implementations.
+This document outlines requirements and expectations for dbus interfaces. These
+are usually specified as requirements due to our dbus architecture or for
+consistency in implementations.
 
 ## General
 
@@ -13,30 +13,32 @@
 protocol's specification).
 
 For countable entities always prefer `size`, which are an sdbusplus implemented
-type that maps to the C equivalent of `size_t` on the architecture.  For
+type that maps to the C equivalent of `size_t` on the architecture. For
 non-countable values prefer `uint64` or `int64`.
 
 ### Avoid use of arbitrary strings
 
-Arbitrary strings should only be utilized for human consumption and never
-parsed by code. Any arbitrary string is typically expected to have a
-description such as "... can be shown in user interfaces but this field should
-not be used for any programmatic interrogation of an object".
+Arbitrary strings should only be utilized for human consumption and never parsed
+by code. Any arbitrary string is typically expected to have a description such
+as "... can be shown in user interfaces but this field should not be used for
+any programmatic interrogation of an object".
 
 ### Leverage enumerations instead of strings or magic values
 
-The sdbusplus implementation has built-in support for enumerations, which
-flow across the dbus as uniquely encoded string values but has support in the
+The sdbusplus implementation has built-in support for enumerations, which flow
+across the dbus as uniquely encoded string values but has support in the
 bindings for automatically converting to a C++ enum type.
 
 In some cases it is useful to have hardware-specific or OEM values for
-enumerations. In those cases a property may be a string, but should specify
-that the values contained within are to be sdbusplus-enumerations of a specific
-pattern. See the [software compatiblity][software-compat] and
-[dump interface][dump-interface] as two current examples of this.
+enumerations. In those cases a property may be a string, but should specify that
+the values contained within are to be sdbusplus-enumerations of a specific
+pattern. See the [software compatiblity][software-compat] and [dump
+interface][dump-interface] as two current examples of this.
 
-[software-compat]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/README.md#compatibility
-[dump-interface]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/991b2b8bdbc950f2a85aebfc29d1b34ea3264686/yaml/xyz/openbmc_project/Dump/Create.interface.yaml#L25
+[software-compat]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/README.md#compatibility
+[dump-interface]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/991b2b8bdbc950f2a85aebfc29d1b34ea3264686/yaml/xyz/openbmc_project/Dump/Create.interface.yaml#L25
 
 ## Interfaces
 
@@ -58,24 +60,24 @@
 overriding aspect of the dbus design.
 
 Directed associations are more common and are used to show a relationship
-between two different entities. Though it may at times feel contrived,
-directed associations should be considered to have a "primary" and "secondary"
-end, which helps establish a pattern for naming consistency.  For example, a
-chassis might be "containing" (primary) any number of other inventory objects
-which are "contained_by" (secondary) the chassis.
+between two different entities. Though it may at times feel contrived, directed
+associations should be considered to have a "primary" and "secondary" end, which
+helps establish a pattern for naming consistency. For example, a chassis might
+be "containing" (primary) any number of other inventory objects which are
+"contained_by" (secondary) the chassis.
 
 ### Peer associations should be named with hierarchy names
 
 Consider an entity which is contained at `/.../foo/entity` and
-`/.../bar/entity`. The association is what links the `foo` and `bar` aspects
-of the entity in the dbus path hierarchy. Accordingly, the association should
-be named with end-points "foo" and "bar".
+`/.../bar/entity`. The association is what links the `foo` and `bar` aspects of
+the entity in the dbus path hierarchy. Accordingly, the association should be
+named with end-points "foo" and "bar".
 
 A made-up example of a peer association might be a `Inventory.Processor`,
 located under the `.../inventory` hierarchy, and a `Control.Power.Cap` for that
-processor, located under the `.../control` hierarchy.  The peer association
-allows traversal between the `inventory` and `control` namespaces for the
-single Processor entity.
+processor, located under the `.../control` hierarchy. The peer association
+allows traversal between the `inventory` and `control` namespaces for the single
+Processor entity.
 
 ### Directed associations should not codify type
 
@@ -91,8 +93,8 @@
 (ending in '-ing'). The secondary relationship should be a verb with a Past
 Participle tense (typically ending in '-ed').
 
-The association end-points should be named in a way that the following
-sentences are grammatically correct:
+The association end-points should be named in a way that the following sentences
+are grammatically correct:
 
 - The `{primary element}` is `{primary association}` the `{secondary element}`.
 - The `{secondary element}` is `{secondary association}` the
diff --git a/yaml/com/google/gbmc/Hoth.errors.yaml b/yaml/com/google/gbmc/Hoth.errors.yaml
index 76b4d7a..0b61989 100644
--- a/yaml/com/google/gbmc/Hoth.errors.yaml
+++ b/yaml/com/google/gbmc/Hoth.errors.yaml
@@ -5,7 +5,8 @@
 - name: FirmwareFailure
   description: Failed to send firmware update to Hoth.
 - name: ResponseNotFound
-  description: Could not find a response. The command may not have completed yet.
+  description:
+      Could not find a response. The command may not have completed yet.
 - name: InterfaceError
   description: A system error occured with the Hoth interface.
 - name: ExpectedInfoNotFound
diff --git a/yaml/com/google/gbmc/Hoth.interface.yaml b/yaml/com/google/gbmc/Hoth.interface.yaml
index 429f01d..685f745 100644
--- a/yaml/com/google/gbmc/Hoth.interface.yaml
+++ b/yaml/com/google/gbmc/Hoth.interface.yaml
@@ -4,10 +4,10 @@
 methods:
     - name: SendHostCommand
       description: >
-          Send a host command to Hoth and return the response.
-          This will block on Hoth completing its internal operations.
-          Critical host commands like LoadTokens are banned.
-          This method should be called from the IPMI HostCommand passthrough.
+          Send a host command to Hoth and return the response. This will block
+          on Hoth completing its internal operations. Critical host commands
+          like LoadTokens are banned. This method should be called from the IPMI
+          HostCommand passthrough.
       parameters:
           - name: Command
             type: array[byte]
@@ -26,10 +26,10 @@
 
     - name: SendTrustedHostCommand
       description: >
-          Send a host command to Hoth and return the response.
-          This will block on Hoth completing its internal operations.
-          Critical host commands like LoadTokens are allowed.
-          This method should be called from the BMC.
+          Send a host command to Hoth and return the response. This will block
+          on Hoth completing its internal operations. Critical host commands
+          like LoadTokens are allowed. This method should be called from the
+          BMC.
       parameters:
           - name: Command
             type: array[byte]
@@ -104,9 +104,9 @@
 
     - name: InitiatePayload
       description: >
-          Initiates erasure of the EEPROM staging area. Note that this will lock up
-          access to Hoth for an extended time and may go over the kernel's SPI
-          write timeout. Calling multiple small ErasePayload is recommended.
+          Initiates erasure of the EEPROM staging area. Note that this will lock
+          up access to Hoth for an extended time and may go over the kernel's
+          SPI write timeout. Calling multiple small ErasePayload is recommended.
       errors:
           - self.Error.CommandFailure
           - self.Error.ResponseFailure
@@ -177,14 +177,14 @@
 
     - name: ActivatePayload
       description: >
-          Activates the staging area as persistent or non-persistent for next boot
-          if verification was successful.
+          Activates the staging area as persistent or non-persistent for next
+          boot if verification was successful.
       parameters:
           - name: MakePersistent
             type: boolean
             description: >
-                Flag to determine whether to activate the staged image as persistent
-                or non-persistent for next boot.
+                Flag to determine whether to activate the staged image as
+                persistent or non-persistent for next boot.
       errors:
           - self.Error.CommandFailure
           - self.Error.ResponseFailure
@@ -205,8 +205,8 @@
 
     - name: Confirm
       description: >
-          Prevents hoth from rolling back and using the previous image.
-          When an image can be comfirmed to be working well, this command is given,
+          Prevents hoth from rolling back and using the previous image. When an
+          image can be comfirmed to be working well, this command is given,
           which disarms the hoth watchdog.
       errors:
           - self.Error.CommandFailure
@@ -227,8 +227,8 @@
 
     - name: GetFirmwareUpdateTime
       description: >
-          Get time spending in the self update routine. Since a proper self update
-          involves a reset, this time is always expected to be low.
+          Get time spending in the self update routine. Since a proper self
+          update involves a reset, this time is always expected to be low.
       returns:
           - name: Time
             type: uint32
@@ -240,8 +240,8 @@
 
     - name: GetFirmwareMirroringTime
       description: >
-          Get time spending in mirroing the self-update. This time is a reasonable
-          proxy for the total self update time.
+          Get time spending in mirroing the self-update. This time is a
+          reasonable proxy for the total self update time.
       returns:
           - name: Time
             type: uint32
@@ -253,8 +253,8 @@
 
     - name: GetPayloadValidationTime
       description: >
-          Get time spending in validating the payload, copying mutable regions and/or
-          dealing with failsafe fallback.
+          Get time spending in validating the payload, copying mutable regions
+          and/or dealing with failsafe fallback.
       returns:
           - name: Time
             type: uint32
diff --git a/yaml/com/ibm/Dump/Create.interface.yaml b/yaml/com/ibm/Dump/Create.interface.yaml
index 847b64a..80147c0 100644
--- a/yaml/com/ibm/Dump/Create.interface.yaml
+++ b/yaml/com/ibm/Dump/Create.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement this to pass additional parameters to the create dump.
-    Each required parameter for the dump in the ibm domain should be added
-    here as an enum.
+    Implement this to pass additional parameters to the create dump. Each
+    required parameter for the dump in the ibm domain should be added here as an
+    enum.
 
 enumerations:
     - name: CreateParameters
@@ -10,11 +10,10 @@
       values:
           - name: "VSPString"
             description: >
-                The resouce dump is collected from various host resources.
-                The resource to collect the dump is indicated by using the
-                resource selector.
-                The resource selector string needs to be passed to host to
-                generate a resource dump.
+                The resouce dump is collected from various host resources. The
+                resource to collect the dump is indicated by using the resource
+                selector. The resource selector string needs to be passed to
+                host to generate a resource dump.
           - name: "Password"
             description: >
                 The password for authenticating the resource dump request.
diff --git a/yaml/com/ibm/Dump/Entry/Hardware.interface.yaml b/yaml/com/ibm/Dump/Entry/Hardware.interface.yaml
index fd9ac4b..9053cee 100644
--- a/yaml/com/ibm/Dump/Entry/Hardware.interface.yaml
+++ b/yaml/com/ibm/Dump/Entry/Hardware.interface.yaml
@@ -1,7 +1,7 @@
 description: >
     Implement this to add Hardware dump management.
 
-    Hardware dump is a collection hardware state information,
-    including various registers, and it is used for debugging
-    system checkstop. checkstop is the descriptive term for
-    entire system termination by the hardware due to a detected error.
+    Hardware dump is a collection hardware state information, including various
+    registers, and it is used for debugging system checkstop. checkstop is the
+    descriptive term for entire system termination by the hardware due to a
+    detected error.
diff --git a/yaml/com/ibm/Dump/Entry/Hostboot.interface.yaml b/yaml/com/ibm/Dump/Entry/Hostboot.interface.yaml
index da8a0f6..f2b5f2f 100644
--- a/yaml/com/ibm/Dump/Entry/Hostboot.interface.yaml
+++ b/yaml/com/ibm/Dump/Entry/Hostboot.interface.yaml
@@ -1,6 +1,5 @@
 description: >
     Implement this to add Hostboot dump management.
 
-    Hostboot dump collects memory and hardware states
-    in the case of a failure during hostboot booting
-    phase.
+    Hostboot dump collects memory and hardware states in the case of a failure
+    during hostboot booting phase.
diff --git a/yaml/com/ibm/Dump/Entry/Resource.interface.yaml b/yaml/com/ibm/Dump/Entry/Resource.interface.yaml
index 17a38d9..ffedff4 100644
--- a/yaml/com/ibm/Dump/Entry/Resource.interface.yaml
+++ b/yaml/com/ibm/Dump/Entry/Resource.interface.yaml
@@ -1,20 +1,19 @@
 description: >
     Implement this to add Resource dump management.
 
-    The resource dumps are special types of dumps
-    generated by host hypervisor. The dump is generated
-    based on the resource selector. Hyperviosr needs
-    a password to validate the request before creating the dump.
+    The resource dumps are special types of dumps generated by host hypervisor.
+    The dump is generated based on the resource selector. Hyperviosr needs a
+    password to validate the request before creating the dump.
 
 properties:
     - name: SourceDumpId
       type: uint32
       description: >
-          The dump id provided by the source of the dump.
-          There are dumps which get generated outside the BMC, like a
-          resource dump which gets generated and stored in the host memory.
-          All dumps will have a unique id but when communicating
-          to the source of the dump the SourceDumpId will be used.
+          The dump id provided by the source of the dump. There are dumps which
+          get generated outside the BMC, like a resource dump which gets
+          generated and stored in the host memory. All dumps will have a unique
+          id but when communicating to the source of the dump the SourceDumpId
+          will be used.
     - name: VSPString
       type: string
       description: >
diff --git a/yaml/com/ibm/Logging/Policy.interface.yaml b/yaml/com/ibm/Logging/Policy.interface.yaml
index 2dc6d05..8b971e7 100644
--- a/yaml/com/ibm/Logging/Policy.interface.yaml
+++ b/yaml/com/ibm/Logging/Policy.interface.yaml
@@ -4,8 +4,8 @@
     - name: EventID
       type: string
       description: >
-          This ID is defined by IBM service to uniquely identify an error
-          in the service documentation.
+          This ID is defined by IBM service to uniquely identify an error in the
+          service documentation.
     - name: Description
       type: string
       description: >
diff --git a/yaml/com/ibm/VPD.errors.yaml b/yaml/com/ibm/VPD.errors.yaml
index a69e8c1..da408f0 100644
--- a/yaml/com/ibm/VPD.errors.yaml
+++ b/yaml/com/ibm/VPD.errors.yaml
@@ -9,16 +9,14 @@
 - name: KeywordNotFound
   description: Keyword is not found.
 - name: BlankSystemVPD
-  description: System VPD is blank on both hardware and cache.
-      On IBM systems, certain VPD data must be available
-      for the system to boot. This error is used to
+  description:
+      System VPD is blank on both hardware and cache. On IBM systems, certain
+      VPD data must be available for the system to boot. This error is used to
       indicate that no valid data was found by the BMC.
 - name: InvalidEepromPath
-  description: EEPROM path is invalid. Parser failed to access the
-      path.
+  description: EEPROM path is invalid. Parser failed to access the path.
 - name: InvalidVPD
-  description: VPD file is not valid. Mandatory records are missing
-      in VPD file.
+  description: VPD file is not valid. Mandatory records are missing in VPD file.
 - name: EccCheckFailed
   desciption: Invalid VPD data. Ecc check for the data failed.
 - name: InvalidJson
diff --git a/yaml/com/ibm/VPD/Manager.interface.yaml b/yaml/com/ibm/VPD/Manager.interface.yaml
index 2dfae1b..8d1409d 100644
--- a/yaml/com/ibm/VPD/Manager.interface.yaml
+++ b/yaml/com/ibm/VPD/Manager.interface.yaml
@@ -29,8 +29,8 @@
 
     - name: GetFRUsByUnexpandedLocationCode
       description: >
-          A method to get list of FRU D-BUS object paths for a given
-          unexpanded location code.
+          A method to get list of FRU D-BUS object paths for a given unexpanded
+          location code.
       parameters:
           - name: locationCode
             type: string
@@ -39,8 +39,8 @@
           - name: nodeNumber
             type: uint16
             description: >
-                Denotes the node in case of a multi-node configuration,
-                ignored on a single node system.
+                Denotes the node in case of a multi-node configuration, ignored
+                on a single node system.
       returns:
           - name: inventoryList
             type: array[object_path]
@@ -75,8 +75,8 @@
     - name: GetExpandedLocationCode
       description: >
           An api to get expanded location code corresponding to a given
-          un-expanded location code.
-          Expanded location codes gives the location of the FRU in the system.
+          un-expanded location code. Expanded location codes gives the location
+          of the FRU in the system.
       parameters:
           - name: locationCode
             type: string
@@ -85,8 +85,8 @@
           - name: nodeNumber
             type: uint16
             description: >
-                Denotes the node in case of multi-node configuration.
-                Ignored in case of single node configuration.
+                Denotes the node in case of multi-node configuration. Ignored in
+                case of single node configuration.
       returns:
           - name: locationCode
             type: string
diff --git a/yaml/com/ibm/ipzvpd/CP00.interface.yaml b/yaml/com/ibm/ipzvpd/CP00.interface.yaml
index bbc5652..9016512 100644
--- a/yaml/com/ibm/ipzvpd/CP00.interface.yaml
+++ b/yaml/com/ibm/ipzvpd/CP00.interface.yaml
@@ -32,8 +32,7 @@
     - name: PZ
       type: array[byte]
       description: >
-          PZ keyword.On Chip Precision Voltage Reference,
-          PVREF.
+          PZ keyword.On Chip Precision Voltage Reference, PVREF.
     - name: AW
       type: array[byte]
       description: >
diff --git a/yaml/com/ibm/ipzvpd/CRP0.interface.yaml b/yaml/com/ibm/ipzvpd/CRP0.interface.yaml
index 558c450..c5d2a91 100644
--- a/yaml/com/ibm/ipzvpd/CRP0.interface.yaml
+++ b/yaml/com/ibm/ipzvpd/CRP0.interface.yaml
@@ -44,8 +44,7 @@
     - name: PD_W
       type: array[byte]
       description: >
-          The "#W" keyword.DDS configuration and calibration
-          settings.
+          The "#W" keyword.DDS configuration and calibration settings.
     - name: PD_V
       type: array[byte]
       description: >
diff --git a/yaml/com/ibm/ipzvpd/Location.interface.yaml b/yaml/com/ibm/ipzvpd/Location.interface.yaml
index c64e7a8..5244db8 100644
--- a/yaml/com/ibm/ipzvpd/Location.interface.yaml
+++ b/yaml/com/ibm/ipzvpd/Location.interface.yaml
@@ -4,5 +4,5 @@
     - name: LocationCode
       type: string
       description: >
-          A string describing the physical location of the FRU.
-          The location is determined based on the system design.
+          A string describing the physical location of the FRU. The location is
+          determined based on the system design.
diff --git a/yaml/com/ibm/ipzvpd/README.md b/yaml/com/ibm/ipzvpd/README.md
index 6604577..839a114 100644
--- a/yaml/com/ibm/ipzvpd/README.md
+++ b/yaml/com/ibm/ipzvpd/README.md
@@ -1,12 +1,12 @@
 # IPZ VPD D-Bus Interfaces
 
-IPZ is a VPD (Vital Product Data) format used in IBM Power systems.
-The format consists of keywords that are stored as key-value
-pairs (Keyword name and its value). Keywords are grouped into records,
-usually with similar function grouped into a single record.
+IPZ is a VPD (Vital Product Data) format used in IBM Power systems. The format
+consists of keywords that are stored as key-value pairs (Keyword name and its
+value). Keywords are grouped into records, usually with similar function grouped
+into a single record.
 
-The [OpenPower VPD] [1] format is quite similar to the IPZ format
-and describes the record-keyword structure.
+The [OpenPower VPD] [1] format is quite similar to the IPZ format and describes
+the record-keyword structure.
 
 Also refer to the [VPD Collection design document] [2] that describes how the
 VPD collection application on the BMC will parse and publish the VPD data for
@@ -14,8 +14,9 @@
 
 The D-Bus interfaces defined here describe how IPZ VPD will be made available on
 D-Bus. Each YAML here represents a record in the IPZ VPD and keywords that
-belong to that record are represented as properties under that interface.
-The type of every property shall be a byte array.
+belong to that record are represented as properties under that interface. The
+type of every property shall be a byte array.
 
-[1]: https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=1D060729AC96891885257E1B0053BC95
+[1]:
+  https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=1D060729AC96891885257E1B0053BC95
 [2]: https://github.com/openbmc/docs/blob/master/designs/vpd-collection.md
diff --git a/yaml/com/ibm/ipzvpd/VER0.interface.yaml b/yaml/com/ibm/ipzvpd/VER0.interface.yaml
index 1c0d3c8..413a6ea 100644
--- a/yaml/com/ibm/ipzvpd/VER0.interface.yaml
+++ b/yaml/com/ibm/ipzvpd/VER0.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Implement to represent the VER0 record (contains vendor repair data)
-    in IPZ VPD
+    Implement to represent the VER0 record (contains vendor repair data) in IPZ
+    VPD
 properties:
     - name: RT
       type: array[byte]
diff --git a/yaml/com/intel/Control/NMISource.interface.yaml b/yaml/com/intel/Control/NMISource.interface.yaml
index a172159..5d95eff 100644
--- a/yaml/com/intel/Control/NMISource.interface.yaml
+++ b/yaml/com/intel/Control/NMISource.interface.yaml
@@ -5,7 +5,7 @@
       type: enum[self.BMCSourceSignal]
       description: >
           Keeps track of NMI signal source in BMC.
-      default: 'None'
+      default: "None"
     - name: Enabled
       type: boolean
       description: >
@@ -13,34 +13,34 @@
       default: true
 
 enumerations:
-   - name: BMCSourceSignal
-     description: >
-       The type of NMI source.
-     values:
-       - name: None
-         description: >
-           NONE NMI signal.
-       - name: FpBtn
-         description: >
-           Via Front Panel NMI button.
-       - name: WdPreTimeout
-         description: >
-           Via watchdog pre-timeout.
-       - name: PefMatch
-         description: >
-           Via PEF match.
-       - name: ChassisCmd
-         description: >
-           Via Chassis command.
-       - name: MemoryError
-         description: >
-           Via memory error.
-       - name: PciSerrPerr
-         description: >
-           Via PCI SERR PERR.
-       - name: SouthbridgeNmi
-         description: >
-           Via southbridge NMI.
-       - name: ChipsetNmi
-         description: >
-           Via chipset NMI.
+    - name: BMCSourceSignal
+      description: >
+          The type of NMI source.
+      values:
+          - name: None
+            description: >
+                NONE NMI signal.
+          - name: FpBtn
+            description: >
+                Via Front Panel NMI button.
+          - name: WdPreTimeout
+            description: >
+                Via watchdog pre-timeout.
+          - name: PefMatch
+            description: >
+                Via PEF match.
+          - name: ChassisCmd
+            description: >
+                Via Chassis command.
+          - name: MemoryError
+            description: >
+                Via memory error.
+          - name: PciSerrPerr
+            description: >
+                Via PCI SERR PERR.
+          - name: SouthbridgeNmi
+            description: >
+                Via southbridge NMI.
+          - name: ChipsetNmi
+            description: >
+                Via chipset NMI.
diff --git a/yaml/com/intel/Control/OCOTShutdownPolicy.interface.yaml b/yaml/com/intel/Control/OCOTShutdownPolicy.interface.yaml
index ccbb6e2..86d239e 100644
--- a/yaml/com/intel/Control/OCOTShutdownPolicy.interface.yaml
+++ b/yaml/com/intel/Control/OCOTShutdownPolicy.interface.yaml
@@ -1,24 +1,23 @@
 description: >
-    An interface for node shutdown policy on multi-node products.
-    It is used by Intel OEM IPMI command.
+    An interface for node shutdown policy on multi-node products. It is used by
+    Intel OEM IPMI command.
 properties:
     - name: OCOTPolicy
       type: enum[self.Policy]
       description: >
-          Node shutdown policy on a power supply over current(OC)
-          or over temperature(OT) event,
-          Only available on multi-node products.
+          Node shutdown policy on a power supply over current(OC) or over
+          temperature(OT) event, Only available on multi-node products.
 
-      default: 'NoShutdownOnOCOT'
+      default: "NoShutdownOnOCOT"
 
 enumerations:
-   - name: Policy
-     description: >
-       The type of shutdown policy.
-     values:
-       - name: 'NoShutdownOnOCOT'
-         description: >
-           Do not shutdown node on an OC/OT event.
-       - name: 'ShutdownOnOCOT'
-         description: >
-           Shutdown node on an OC/OT event.
\ No newline at end of file
+    - name: Policy
+      description: >
+          The type of shutdown policy.
+      values:
+          - name: "NoShutdownOnOCOT"
+            description: >
+                Do not shutdown node on an OC/OT event.
+          - name: "ShutdownOnOCOT"
+            description: >
+                Shutdown node on an OC/OT event.
diff --git a/yaml/com/intel/Protocol/PECI/Raw.interface.yaml b/yaml/com/intel/Protocol/PECI/Raw.interface.yaml
index f2fdb34..60adf89 100644
--- a/yaml/com/intel/Protocol/PECI/Raw.interface.yaml
+++ b/yaml/com/intel/Protocol/PECI/Raw.interface.yaml
@@ -21,5 +21,5 @@
             type: array[array[byte]]
             description: >
                 An array of byte arrays where each byte array holds the raw
-                bytes for a single PECI response corresponding to the command
-                in the command array.
+                bytes for a single PECI response corresponding to the command in
+                the command array.
diff --git a/yaml/org/freedesktop/UPower/Device.interface.yaml b/yaml/org/freedesktop/UPower/Device.interface.yaml
index cb1ef82..b98c120 100644
--- a/yaml/org/freedesktop/UPower/Device.interface.yaml
+++ b/yaml/org/freedesktop/UPower/Device.interface.yaml
@@ -28,17 +28,21 @@
           - name: resolution
             type: uint32
             description: >
-                "The approximate number of points to return. A higher resolution is
+                "The approximate number of points to return. A higher resolution
+                is
                  more accurate, at the expense of plotting speed."
       returns:
           - name: data
             type: array[struct[uint32, double, uint32]]
             description: >
                 "The history data for the power device, if the device supports
-                 history. Data is ordered from the earliest in time, to the newest
+                 history. Data is ordered from the earliest in time, to the
+                newest
                  data point. Each element contains the following members:
-                   time: The time value in seconds from the gettimeofday() method.
-                   value: The data value, for instance the rate in W or the charge
+                   time: The time value in seconds from the gettimeofday()
+                method.
+                   value: The data value, for instance the rate in W or the
+                charge
                           in %.
                    state: The state of the device, for instance charging or
                           discharging."
@@ -57,7 +61,8 @@
           - name: data
             type: array[struct[double, double]]
             description: >
-                "The statistics data for the power device. Each element contains the
+                "The statistics data for the power device. Each element contains
+                the
                  following members:
                    value: The value of the percentage point, usually in seconds.
                    accuracy: The accuracy of the prediction in percent."
@@ -277,7 +282,8 @@
       description: >
           "Level of the battery:
               0: Unknown
-              1: None (the battery does not use a coarse level of battery reporting)
+              1: None (the battery does not use a coarse level of battery
+          reporting)
               3: Low
               4: Critical
               6: Normal
diff --git a/yaml/org/open_power/Control/Host.interface.yaml b/yaml/org/open_power/Control/Host.interface.yaml
index 86dcde1..86014c4 100644
--- a/yaml/org/open_power/Control/Host.interface.yaml
+++ b/yaml/org/open_power/Control/Host.interface.yaml
@@ -1,10 +1,10 @@
 description: >
-    Implement to provide host interface support.
-    This will define the interfaces using which, a OpenPower
-    machine can communicate with host on agreed commands.
+    Implement to provide host interface support. This will define the interfaces
+    using which, a OpenPower machine can communicate with host on agreed
+    commands.
 
-    This is for Internal use by the Firmware only. The D-Bus object
-    is visible for the REST but it must not be used.
+    This is for Internal use by the Firmware only. The D-Bus object is visible
+    for the REST but it must not be used.
 
 methods:
     - name: Execute
@@ -39,11 +39,10 @@
       values:
           - name: OCCReset
             description: >
-                Host firmware should reset the OCC. This is invoked by
-                OCC error monitor application on detecting the error.
-                Sensor ID of the failing OCC will be sent as data.
-                This command will return once the command has been placed
-                in command Queue.
+                Host firmware should reset the OCC. This is invoked by OCC error
+                monitor application on detecting the error. Sensor ID of the
+                failing OCC will be sent as data. This command will return once
+                the command has been placed in command Queue.
 
     - name: Result
       description: >
diff --git a/yaml/org/open_power/Control/TPM/SecurityKeys.interface.yaml b/yaml/org/open_power/Control/TPM/SecurityKeys.interface.yaml
index 89f46a4..459c5cc 100644
--- a/yaml/org/open_power/Control/TPM/SecurityKeys.interface.yaml
+++ b/yaml/org/open_power/Control/TPM/SecurityKeys.interface.yaml
@@ -5,15 +5,15 @@
     - name: ClearHostSecurityKeys
       type: byte
       description: >
-          This is a bit mask used to specify clearing different security keys
-          or resetting those values back to default by the host. Setting this
+          This is a bit mask used to specify clearing different security keys or
+          resetting those values back to default by the host. Setting this
           property does not guarantee a successful operation as additional
           conditions will be checked by the host to clear/reset the sensitive
           data. This property will be mapped to a new IPMI sensor.
 
-          The new property is having an integer value and the default value
-          will be zero. The end operation is determined by the bit value set
-          and some of the customer use cases which maps to bit value are
+          The new property is having an integer value and the default value will
+          be zero. The end operation is determined by the bit value set and some
+          of the customer use cases which maps to bit value are
 
           Bit 0 - Clear All : Clear/reset all the sensitive data controlled by
                   platform firmware from the system. System can generate new
diff --git a/yaml/org/open_power/Logging/PEL.interface.yaml b/yaml/org/open_power/Logging/PEL.interface.yaml
index a3e39f4..2765d64 100644
--- a/yaml/org/open_power/Logging/PEL.interface.yaml
+++ b/yaml/org/open_power/Logging/PEL.interface.yaml
@@ -70,8 +70,8 @@
           - name: Message
             type: string
             description: >
-                The Message property of the OpenBMC event log entry.
-                This is also the key into the PEL message registry.
+                The Message property of the OpenBMC event log entry. This is
+                also the key into the PEL message registry.
           - name: Severity
             type: enum[xyz.openbmc_project.Logging.Entry.Level]
             description: >
@@ -79,8 +79,7 @@
           - name: AdditionalData
             type: dict[string, string]
             description: >
-                The AdditionalData property of the event entry.
-                e.g.:
+                The AdditionalData property of the event entry. e.g.:
                   {
                     "key1": "value1",
                     "key2": "value2"
@@ -88,22 +87,25 @@
                 ends up in AdditionaData like:
                   ["KEY1=value1", "KEY2=value2"]
           - name: FFDC
-            type: array[struct[enum[xyz.openbmc_project.Logging.Create.FFDCFormat], byte, byte, unixfd]]
+            type:
+                array[struct[enum[xyz.openbmc_project.Logging.Create.FFDCFormat],
+                byte, byte, unixfd]]
             description: >
-                File descriptors for any files containing FFDC, along with metadata
-                about the contents:
+                File descriptors for any files containing FFDC, along with
+                metadata about the contents:
 
                   FFDCFormat- The format type of the contained data.
                   subType - The format subtype, used for the 'Custom' type.
-                  version - The version of the data format, used for the 'Custom'
+                  version - The version of the data format, used for the
+                'Custom'
                             type.
                   unixfd - The file descriptor to the data file.
 
-                e.g.:
-                [
-                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.JSON", 0, 0, 5},
-                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.Custom", 1, 2, 6}
-                ]
+                e.g.: [
+                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.JSON", 0, 0,
+                5},
+                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.Custom", 1, 2,
+                6} ]
       returns:
           - name: IDs
             type: struct[uint32, uint32]
@@ -111,13 +113,13 @@
                 The IDs of the 2 created logs:
                   - OpenBMC event log ID
                   - PEL log ID: The unique ID of the PEL
-                Note that the PEL's platform log ID (PLID) field is always
-                equal to the PEL log ID for BMC created PELs.
+                Note that the PEL's platform log ID (PLID) field is always equal
+                to the PEL log ID for BMC created PELs.
 
     - name: GetPELIdFromBMCLogId
       description: >
-          Returns the PEL Id (aka Entry ID (EID)) based on the
-          given BMC event log id.
+          Returns the PEL Id (aka Entry ID (EID)) based on the given BMC event
+          log id.
       parameters:
           - name: bmcLogId
             type: uint32
@@ -133,8 +135,8 @@
 
     - name: GetBMCLogIdFromPELId
       description: >
-          Returns the BMC event log id based on the given PEL id (aka
-          Entry ID (EID)).
+          Returns the BMC event log id based on the given PEL id (aka Entry ID
+          (EID)).
       parameters:
           - name: pelId
             type: uint32
@@ -150,8 +152,7 @@
 
     - name: GetPELJSON
       description: >
-          Returns a string containing the JSON representation
-          of the PEL.
+          Returns a string containing the JSON representation of the PEL.
       parameters:
           - name: bmcLogId
             type: uint32
diff --git a/yaml/org/open_power/Logging/PEL/Entry.interface.yaml b/yaml/org/open_power/Logging/PEL/Entry.interface.yaml
index 8576943..ad2a9a3 100644
--- a/yaml/org/open_power/Logging/PEL/Entry.interface.yaml
+++ b/yaml/org/open_power/Logging/PEL/Entry.interface.yaml
@@ -9,10 +9,10 @@
           remain hidden from the customer. This event log is visible to
           development personnel only, e.g. hardware recovered error, etc. No
           service action is required for this type of errors. In general, when
-          this value is used, the Error Action Flags has the value of
-          "Hidden Error". An event log with this value is used primarily for
-          error thresholding design/code debug or as a record to indicate an
-          error frequency or trend.
+          this value is used, the Error Action Flags has the value of "Hidden
+          Error". An event log with this value is used primarily for error
+          thresholding design/code debug or as a record to indicate an error
+          frequency or trend.
     - name: Subsystem
       type: string
       description: >
@@ -23,5 +23,5 @@
       type: boolean
       default: false
       description: >
-          Notifies the PEL handler that the management system acknowledged a PEL.
-          The management system can be any system monitoring the hardware.
+          Notifies the PEL handler that the management system acknowledged a
+          PEL. The management system can be any system monitoring the hardware.
diff --git a/yaml/org/open_power/OCC/PassThrough.interface.yaml b/yaml/org/open_power/OCC/PassThrough.interface.yaml
index 1a4ef66..d592b26 100644
--- a/yaml/org/open_power/OCC/PassThrough.interface.yaml
+++ b/yaml/org/open_power/OCC/PassThrough.interface.yaml
@@ -12,8 +12,9 @@
             type: array[int32]
             description: >
                 An array of integers representing the command and payload. This
-                should still be bytes worth of data (as though using array[byte]),
-                so each entry in the array should pack as many bytes as possible.
+                should still be bytes worth of data (as though using
+                array[byte]), so each entry in the array should pack as many
+                bytes as possible.
       returns:
           - name: response
             # TODO via https://github.com/openbmc/openbmc/issues/1160. This should
@@ -21,9 +22,9 @@
             # data to int32.
             type: array[int32]
             description: >
-                An array of integers representing the response. This
-                should still be bytes worth of data (as though using array[byte]),
-                so each entry in the array should pack as many bytes as possible.
+                An array of integers representing the response. This should
+                still be bytes worth of data (as though using array[byte]), so
+                each entry in the array should pack as many bytes as possible.
 
     - name: SetMode
       description: >
diff --git a/yaml/org/open_power/Sensor/Aggregation/History/Average.interface.yaml b/yaml/org/open_power/Sensor/Aggregation/History/Average.interface.yaml
index ae2c326..1d6e89f 100644
--- a/yaml/org/open_power/Sensor/Aggregation/History/Average.interface.yaml
+++ b/yaml/org/open_power/Sensor/Aggregation/History/Average.interface.yaml
@@ -7,20 +7,20 @@
     - name: Scale
       type: int64
       description: >
-          The reading scaling factor N, where the actual reading is value * 10^N.
-          This is immutable once set.
+          The reading scaling factor N, where the actual reading is value *
+          10^N. This is immutable once set.
 
     - name: Unit
       type: enum[self.Unit]
       description: >
-          The unit of the reading.  Immutable once set for a sensor.
-          For objects in the temperature namespace, Unit must be "DegreesC".
-          For objects in the fan_tach namespace, Unit must be "RPMS".
-          For objects in the voltage namespace, Unit must be "Volts".
-          For objects in the altitude namespace, Unit must be "Meters".
-          For objects in the current namespace, Unit must be "Amperes".
-          For objects in the power namespace, Unit must be "Watts".
-          For objects in the energy namespace, Unit must be "Joules".
+          The unit of the reading.  Immutable once set for a sensor. For objects
+          in the temperature namespace, Unit must be "DegreesC". For objects in
+          the fan_tach namespace, Unit must be "RPMS". For objects in the
+          voltage namespace, Unit must be "Volts". For objects in the altitude
+          namespace, Unit must be "Meters". For objects in the current
+          namespace, Unit must be "Amperes". For objects in the power namespace,
+          Unit must be "Watts". For objects in the energy namespace, Unit must
+          be "Joules".
 
     - name: Values
       type: array[struct[uint64,int64]]
diff --git a/yaml/org/open_power/Sensor/Aggregation/History/Maximum.interface.yaml b/yaml/org/open_power/Sensor/Aggregation/History/Maximum.interface.yaml
index 9143ce4..92adeae 100644
--- a/yaml/org/open_power/Sensor/Aggregation/History/Maximum.interface.yaml
+++ b/yaml/org/open_power/Sensor/Aggregation/History/Maximum.interface.yaml
@@ -7,20 +7,20 @@
     - name: Scale
       type: int64
       description: >
-          The reading scaling factor N, where the actual reading is value * 10^N.
-          This is immutable once set.
+          The reading scaling factor N, where the actual reading is value *
+          10^N. This is immutable once set.
 
     - name: Unit
       type: enum[self.Unit]
       description: >
-          The unit of the reading.  Immutable once set for a sensor.
-          For objects in the temperature namespace, Unit must be "DegreesC".
-          For objects in the fan_tach namespace, Unit must be "RPMS".
-          For objects in the voltage namespace, Unit must be "Volts".
-          For objects in the altitude namespace, Unit must be "Meters".
-          For objects in the current namespace, Unit must be "Amperes".
-          For objects in the power namespace, Unit must be "Watts".
-          For objects in the energy namespace, Unit must be "Joules".
+          The unit of the reading.  Immutable once set for a sensor. For objects
+          in the temperature namespace, Unit must be "DegreesC". For objects in
+          the fan_tach namespace, Unit must be "RPMS". For objects in the
+          voltage namespace, Unit must be "Volts". For objects in the altitude
+          namespace, Unit must be "Meters". For objects in the current
+          namespace, Unit must be "Amperes". For objects in the power namespace,
+          Unit must be "Watts". For objects in the energy namespace, Unit must
+          be "Joules".
 
     - name: Values
       type: array[struct[uint64,int64]]
diff --git a/yaml/xyz/openbmc_project/Association.interface.yaml b/yaml/xyz/openbmc_project/Association.interface.yaml
index f936bc0..a5dd958 100644
--- a/yaml/xyz/openbmc_project/Association.interface.yaml
+++ b/yaml/xyz/openbmc_project/Association.interface.yaml
@@ -3,9 +3,9 @@
     namespace.
 
     An object implementing Association describes a one way, one to many
-    association where the parent object is associated to the objects
-    in the Endpoints property, with the association type defined as the name
-    of the object implementing Association.
+    association where the parent object is associated to the objects in the
+    Endpoints property, with the association type defined as the name of the
+    object implementing Association.
 properties:
     - name: Endpoints
       type: array[object_path]
diff --git a/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml b/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml
index 7a1903b..b1b7a38 100644
--- a/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml
+++ b/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml
@@ -1,14 +1,14 @@
 description: >
-    Provides Remote BIOS Configuration management functionality.
-    As communication to this service is done through authenticated
-    & authorized session, there won't be any validation for both.
+    Provides Remote BIOS Configuration management functionality. As
+    communication to this service is done through authenticated & authorized
+    session, there won't be any validation for both.
     https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/29320
 
 methods:
     - name: SetAttribute
       description: >
-          To set the new value on existing attribute name.
-          It will create or add the pending attributes.
+          To set the new value on existing attribute name. It will create or add
+          the pending attributes.
       parameters:
           - name: AttributeName
             type: string
@@ -31,9 +31,8 @@
           - name: AttributeName
             type: string
             description: >
-                To get the bios attribute current values and
-                pending values if previously set by setAttribute or
-                SetPendingAttributes.
+                To get the bios attribute current values and pending values if
+                previously set by setAttribute or SetPendingAttributes.
 
       returns:
           - name: AttributeValueType
@@ -57,18 +56,17 @@
       type: enum[self.ResetFlag]
       default: NoAction
       description: >
-          Contain reset BIOS setting type:
-          Interface have to set NoAction this property.
-          when Reset BIOS settings are informed to the BIOS.
+          Contain reset BIOS setting type: Interface have to set NoAction this
+          property. when Reset BIOS settings are informed to the BIOS.
 
     - name: BaseBIOSTable
-      type: dict[string,struct[enum[self.AttributeType],boolean,string,string,string,variant[int64,string],variant[int64,string],array[struct[enum[self.BoundType], variant[int64, string]]]]]
+      type:
+          dict[string,struct[enum[self.AttributeType],boolean,string,string,string,variant[int64,string],variant[int64,string],array[struct[enum[self.BoundType],
+          variant[int64, string]]]]]
       description: >
           map{attributeName,struct{attributeType,readonlyStatus,displayname,
           description,menuPath,current,default,
-          array{struct{optionstring,optionvalue}}}}
-          Example 1:
-          {"DdrFreqLimit",
+          array{struct{optionstring,optionvalue}}}} Example 1: {"DdrFreqLimit",
           {xyz.openbmc_project.BIOSConfig.Manager.AttributeType.String,
            false,
            "Memory Operating Speed Selection",
@@ -82,8 +80,7 @@
              {"OneOf", "2664"},
              {"OneOf", "2933"}
            }
-          }
-          }
+          } }
            Example 2:
           {"BIOSSerialDebugLevel",
           {xyz.openbmc_project.BIOSConfig.Manager.AttributeType.Integer,
@@ -97,14 +94,13 @@
              {"MaxBound", 4},
              {"ScalarIncrement",1}
            }
-          }
-          }
+          } }
 
     - name: PendingAttributes
       type: dict[string,struct[enum[self.AttributeType],variant[int64,string]]]
       description: >
-          The Pending attribute name and new value.
-          ex- { {"QuietBoot",Type.Integer, 0x1},
+          The Pending attribute name and new value. ex- {
+          {"QuietBoot",Type.Integer, 0x1},
                 { "DdrFreqLimit",Type.String,"2933"}
               }
       errors:
diff --git a/yaml/xyz/openbmc_project/BIOSConfig/Password.interface.yaml b/yaml/xyz/openbmc_project/BIOSConfig/Password.interface.yaml
index 2f20786..ba0f823 100644
--- a/yaml/xyz/openbmc_project/BIOSConfig/Password.interface.yaml
+++ b/yaml/xyz/openbmc_project/BIOSConfig/Password.interface.yaml
@@ -1,8 +1,8 @@
 description: >
-    Remote BIOS Config manager daemon will create payload objects
-    for every payload received in the system under
-    object path /xyz/openbmc_project/biosconfigMgr/<PayloadType>.
-    Password interface is used to change and verify the BIOS setup Password
+    Remote BIOS Config manager daemon will create payload objects for every
+    payload received in the system under object path
+    /xyz/openbmc_project/biosconfigMgr/<PayloadType>. Password interface is used
+    to change and verify the BIOS setup Password
 methods:
     - name: ChangePassword
       description: >
diff --git a/yaml/xyz/openbmc_project/BIOSConfig/README.md b/yaml/xyz/openbmc_project/BIOSConfig/README.md
index 3627ebc..8d42311 100644
--- a/yaml/xyz/openbmc_project/BIOSConfig/README.md
+++ b/yaml/xyz/openbmc_project/BIOSConfig/README.md
@@ -46,4 +46,5 @@
 - `IsPasswordInitDone` - To indicate BIOS password related details are received
   or not.
 
-[design]: https://github.com/openbmc/docs/blob/master/designs/remote-bios-configuration.md
+[design]:
+  https://github.com/openbmc/docs/blob/master/designs/remote-bios-configuration.md
diff --git a/yaml/xyz/openbmc_project/Certs/Authority.interface.yaml b/yaml/xyz/openbmc_project/Certs/Authority.interface.yaml
index e081bfa..b994a51 100644
--- a/yaml/xyz/openbmc_project/Certs/Authority.interface.yaml
+++ b/yaml/xyz/openbmc_project/Certs/Authority.interface.yaml
@@ -9,14 +9,16 @@
           - name: CSR
             type: string
             description: >
-                Should be a valid PEM encoded Certificate signing request string.
+                Should be a valid PEM encoded Certificate signing request
+                string.
 
       returns:
           - name: path
             type: object_path
             description: >
                 The object path of an object that implements, at a minimum,
-                xyz.openbmc_project.Certs.Entry and xyz.openbmc_project.Object.Delete
+                xyz.openbmc_project.Certs.Entry and
+                xyz.openbmc_project.Object.Delete
 
       errors:
           - xyz.openbmc_project.Common.Error.InvalidArgument
diff --git a/yaml/xyz/openbmc_project/Certs/CSR.interface.yaml b/yaml/xyz/openbmc_project/Certs/CSR.interface.yaml
index 0741de7..61d037a 100644
--- a/yaml/xyz/openbmc_project/Certs/CSR.interface.yaml
+++ b/yaml/xyz/openbmc_project/Certs/CSR.interface.yaml
@@ -7,7 +7,8 @@
           Method to get the CSR string.
 
           Object which implements this interface should implement
-          xyz.openbmc_project.Object.Delete to allow the deletion of CSR objects.
+          xyz.openbmc_project.Object.Delete to allow the deletion of CSR
+          objects.
 
       returns:
           - name: CSRString
diff --git a/yaml/xyz/openbmc_project/Certs/CSR/Create.interface.yaml b/yaml/xyz/openbmc_project/Certs/CSR/Create.interface.yaml
index 824c6cc..7404d83 100644
--- a/yaml/xyz/openbmc_project/Certs/CSR/Create.interface.yaml
+++ b/yaml/xyz/openbmc_project/Certs/CSR/Create.interface.yaml
@@ -4,11 +4,11 @@
 methods:
     - name: GenerateCSR
       description: >
-          This command is used to initiate a certificate signing request.
-          This command only returns the D-Bus path name for the new CSR object.
-          User need to listen on InterfacesAdded signal emitted by
-          /xyz/openbmc_project/Certs to retrieve the CSR string after
-          successful CSR creation.
+          This command is used to initiate a certificate signing request. This
+          command only returns the D-Bus path name for the new CSR object. User
+          need to listen on InterfacesAdded signal emitted by
+          /xyz/openbmc_project/Certs to retrieve the CSR string after successful
+          CSR creation.
 
           Note: Following Parameters are mandatory or optional based on the
                 Redfish documentation.
@@ -32,15 +32,13 @@
           - name: City
             type: string
             description: >
-                The city or locality of the organization making the request.
-                For Example Austin
-                This is a required parameter.
+                The city or locality of the organization making the request. For
+                Example Austin This is a required parameter.
           - name: CommonName
             type: string
             description: >
                 The fully qualified domain name of the component that is being
-                secured.
-                This is a required parameter.
+                secured. This is a required parameter.
           - name: ContactPerson
             type: string
             description: >
@@ -48,13 +46,13 @@
           - name: Country
             type: string
             description: >
-                The country of the organization making the request.
-                This is a required parameter.
+                The country of the organization making the request. This is a
+                required parameter.
           - name: Email
             type: string
             description: >
-                The email address of the contact within the organization
-                making the request.
+                The email address of the contact within the organization making
+                the request.
           - name: GivenName
             type: string
             description: >
@@ -66,8 +64,8 @@
           - name: KeyBitLength
             type: int64
             description: >
-                The length of the key in bits, if needed based on the value
-                of the KeyPairAlgorithm parameter.
+                The length of the key in bits, if needed based on the value of
+                the KeyPairAlgorithm parameter.
 
                 Refer https://www.openssl.org/docs/man1.0.2/man1/genpkey.html
           - name: KeyCurveId
@@ -87,35 +85,43 @@
           - name: KeyUsage
             type: array[string]
             description: >
-                Key usage extensions define the purpose of the public key contained
-                in a certificate.
+                Key usage extensions define the purpose of the public key
+                contained in a certificate.
 
                 Valid Key usage extensions and its usage description.
 
                 ClientAuthentication: The public key is used for TLS WWW client
                                       authentication.
-                CodeSigning: The public key is used for the signing of executable code.
-                CRLSigning: The public key is used for verifying signatures on
+                CodeSigning: The public key is used for the signing of
+                executable code. CRLSigning: The public key is used for
+                verifying signatures on
                             certificate revocation lists (CLRs).
-                DataEncipherment: The public key is used for directly enciphering
-                                  raw user data without the use of an intermediate
+                DataEncipherment: The public key is used for directly
+                enciphering
+                                  raw user data without the use of an
+                intermediate
                                   symmetric cipher.
                 DecipherOnly: The public key could be used for deciphering data
                               while performing key agreement.
                 DigitalSignature: The public key is used for verifying digital
-                                  signatures, other than signatures on certificates
+                                  signatures, other than signatures on
+                certificates
                                   and CRLs.
                 EmailProtection: The public key is used for email protection.
                 EncipherOnly: The public key could be used for enciphering data
                               while performing key agreement.
                 KeyCertSign: The public key is used for verifying signatures on
                              public key certificates.
-                KeyEncipherment: The public key is used for enciphering private or
+                KeyEncipherment: The public key is used for enciphering private
+                or
                                  secret keys.
-                NonRepudiation: The public key is used to verify digital signatures,
+                NonRepudiation: The public key is used to verify digital
+                signatures,
                                 other than signatures on certificates and CRLs,
-                                and used to provide a non- repudiation service that
-                                protects against the signing entity falsely denying
+                                and used to provide a non- repudiation service
+                that
+                                protects against the signing entity falsely
+                denying
                                 some action.
                 OCSPSigning: The public key is used for signing OCSP responses.
                 ServerAuthentication: The public key is used for TLS WWW server
@@ -125,22 +131,20 @@
           - name: Organization
             type: string
             description: >
-                The legal name of the organization. This should not be abbreviated
-                and should include suffixes such as Inc, Corp, or LLC.
-                For example, IBM Corp.
-                This is a required parameter.
+                The legal name of the organization. This should not be
+                abbreviated and should include suffixes such as Inc, Corp, or
+                LLC. For example, IBM Corp. This is a required parameter.
           - name: OrganizationalUnit
             type: string
             description: >
                 The name of the unit or division of the organization making the
-                request.
-                This is a required parameter.
+                request. This is a required parameter.
           - name: State
             type: string
             description: >
-                The state or province where the organization is located.
-                This should not be abbreviated. For example, Texas.
-                This is a required parameter.
+                The state or province where the organization is located. This
+                should not be abbreviated. For example, Texas. This is a
+                required parameter.
           - name: Surname
             type: string
             description: >
diff --git a/yaml/xyz/openbmc_project/Certs/Certificate.interface.yaml b/yaml/xyz/openbmc_project/Certs/Certificate.interface.yaml
index 5bddd3b..799d9da 100644
--- a/yaml/xyz/openbmc_project/Certs/Certificate.interface.yaml
+++ b/yaml/xyz/openbmc_project/Certs/Certificate.interface.yaml
@@ -11,18 +11,18 @@
       description: >
           The string for the certificate.
 
-          This is a X.509 public certificate in PEM format.
-          PEM wiki - https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail
+          This is a X.509 public certificate in PEM format. PEM wiki -
+          https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail
 
-          An X.509 certificate contains a public key, validity, and an
-          identity (a hostname, or an organization, or an individual),
-          and is either signed by a certificate authority or self-signed.
-          Refer https://en.wikipedia.org/wiki/X.509 for details.
+          An X.509 certificate contains a public key, validity, and an identity
+          (a hostname, or an organization, or an individual), and is either
+          signed by a certificate authority or self-signed. Refer
+          https://en.wikipedia.org/wiki/X.509 for details.
     - name: KeyUsage
       type: array[string]
       description: >
-          Key usage extensions define the purpose of the public key contained
-          in a certificate.
+          Key usage extensions define the purpose of the public key contained in
+          a certificate.
 
           Valid Key usage extensions and its usage description is based on
           Redfish Resource and Schema Guide 2018.3 version.
@@ -30,8 +30,8 @@
 
           ClientAuthentication: The public key is used for TLS WWW client
                                 authentication.
-          CodeSigning: The public key is used for the signing of executable code.
-          CRLSigning: The public key is used for verifying signatures on
+          CodeSigning: The public key is used for the signing of executable
+          code. CRLSigning: The public key is used for verifying signatures on
                       certificate revocation lists (CLRs).
           DataEncipherment: The public key is used for directly enciphering
                             raw user data without the use of an intermediate
@@ -66,8 +66,8 @@
 
           Refer X.509 certificate wiki for the "Issuer" Key and value details.
 
-          Example: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
-          Here C = country, O=organization, CN= common name.
+          Example: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA Here
+          C = country, O=organization, CN= common name.
 
     - name: Subject
       type: string
@@ -90,5 +90,5 @@
     - name: ValidNotBefore
       type: uint64
       description: >
-          The certificate validity start date and time,
-          in epoch time, in milliseconds.
+          The certificate validity start date and time, in epoch time, in
+          milliseconds.
diff --git a/yaml/xyz/openbmc_project/Certs/Entry.interface.yaml b/yaml/xyz/openbmc_project/Certs/Entry.interface.yaml
index 4547798..1ac93fd 100644
--- a/yaml/xyz/openbmc_project/Certs/Entry.interface.yaml
+++ b/yaml/xyz/openbmc_project/Certs/Entry.interface.yaml
@@ -1,13 +1,11 @@
 description: >
-    Implement to get CSR string signed by authority and get
-    client certificate.
+    Implement to get CSR string signed by authority and get client certificate.
 
 properties:
     - name: ClientCertificate
       type: string
       description: >
-          Client certificate content.
-          User reads this property based on status.
+          Client certificate content. User reads this property based on status.
           The value of this property is empty until Status.State == complete.
     - name: Status
       type: enum[self.State]
diff --git a/yaml/xyz/openbmc_project/Certs/README.md b/yaml/xyz/openbmc_project/Certs/README.md
index abfdf6d..31d9005 100644
--- a/yaml/xyz/openbmc_project/Certs/README.md
+++ b/yaml/xyz/openbmc_project/Certs/README.md
@@ -3,11 +3,11 @@
 ## Overview
 
 Certificate management allows to replace the existing certificate and private
-key file with another (possibly certification Authority (CA) signed)
-certificate and private key file. Certificate management allows the user to
-install both the server and client certificates. The REST interface allows to
-update the certificate, using an unencrypted certificate and private key file
-in .pem format, which includes both private key and signed certificate.
+key file with another (possibly certification Authority (CA) signed) certificate
+and private key file. Certificate management allows the user to install both the
+server and client certificates. The REST interface allows to update the
+certificate, using an unencrypted certificate and private key file in .pem
+format, which includes both private key and signed certificate.
 
 ### Signed Certificate upload Design flow(Pre-generated)
 
@@ -15,15 +15,13 @@
   location.
 - REST server should map the URI to the target DBus application (Certs) object.
   The recommendation for the D-Bus application implementing certificate D-Bus
-  objects is to use the same path structure as the REST endpoint.
-  e.g.:
-  - The URI /xyz/openbmc_project/certs/server/https maps to instance
-    of the certificate application handling Https server certificate.
-  - The URI /xyz/openbmc_project/certs/client/ldap maps to instance
-    of the certificate application handling LDAP client certificate.
-  - The URI /xyz/openbmc_project/certs/authority/ldap maps to instance
-    of the certificate application handling Certificate Autohority
-    certificates.
+  objects is to use the same path structure as the REST endpoint. e.g.:
+  - The URI /xyz/openbmc_project/certs/server/https maps to instance of the
+    certificate application handling Https server certificate.
+  - The URI /xyz/openbmc_project/certs/client/ldap maps to instance of the
+    certificate application handling LDAP client certificate.
+  - The URI /xyz/openbmc_project/certs/authority/ldap maps to instance of the
+    certificate application handling Certificate Autohority certificates.
 - REST server should call the install method of the certificate application
   instance.
 - Certificate manager application also implements d-bus object
@@ -31,9 +29,8 @@
   "certificates specific d-bus objects" installed in the system. This d-bus
   provide option to view the certificate on PEM format and delete the same.
   Refer [Wikipedia][privacy-enhanced-mail] for details.
-- Applications should subscribe the xyz.openbmc_project.Certs.Manager
-  to see any new certificate is uploaded or change in the existing
-  certificates.
+- Applications should subscribe the xyz.openbmc_project.Certs.Manager to see any
+  new certificate is uploaded or change in the existing certificates.
 - Certificate manager scope is limited to manage the certificate and impacted
   application is responsible for application specific changes.
 - In case of delete action, certificate manager creates a new self signed
@@ -73,20 +70,19 @@
 
 ### User flow for generating and installing Certificates(CSR Based)
 
-[Certificate Signing Request][csr](CSR) is a message sent from an applicant to
-a certitificate authority in order to apply for a digital identity certificate.
+[Certificate Signing Request][csr](CSR) is a message sent from an applicant to a
+certitificate authority in order to apply for a digital identity certificate.
 This section provides the details of the CSR based certificate user flow.
 
-- The user performs the CSR/create interface
-  BMC creates new private key and CSR object which includes CSR information.
-- The user performs the CSR/export interface
-  Allows the user to export the CSR file which is part of newly created
-  CSR object. This can be provided to the CA to create SSL certificate.
-- The user perform the certificate upload on appropriate services.
-  Example: if trying to replace the HTTPS certificate for a Manager,
-  navigate to the Manager’s Certificate object upload interface.
-  The Upload method internally pairs the private key used in the first
-  step with the installed certificate.
+- The user performs the CSR/create interface BMC creates new private key and CSR
+  object which includes CSR information.
+- The user performs the CSR/export interface Allows the user to export the CSR
+  file which is part of newly created CSR object. This can be provided to the CA
+  to create SSL certificate.
+- The user perform the certificate upload on appropriate services. Example: if
+  trying to replace the HTTPS certificate for a Manager, navigate to the
+  Manager’s Certificate object upload interface. The Upload method internally
+  pairs the private key used in the first step with the installed certificate.
 
 [csr]: https://en.wikipedia.org/wiki/Certificate_signing_request
 
@@ -100,16 +96,16 @@
 
 ### CSR Request
 
-- CSR requests initiated through D-Bus are time-consuming and might result
-  D-Bus time-out error.
-- To overcome the time-out error, parent process is forked and CSR operation
-  is performed in the child process so that parent process can return the
-  calling thread immediately.
+- CSR requests initiated through D-Bus are time-consuming and might result D-Bus
+  time-out error.
+- To overcome the time-out error, parent process is forked and CSR operation is
+  performed in the child process so that parent process can return the calling
+  thread immediately.
 - OpenSSL library is used in generating CSR based on the algorithm type.
 - At present supporting generating CSR for only "RSA" algorithm type.
 - Parent process registers child process PID and a callback method in the
-  sd_event_lopp so that callback method is invoked upon completion
-  the CSR request in the child process.
+  sd_event_lopp so that callback method is invoked upon completion the CSR
+  request in the child process.
 - Callback method invoked creates a CSR object with the status of the CSR
   operation returned from the child process.
 - CSR read operation will return the CSR string if status is SUCCESS else throws
@@ -118,8 +114,8 @@
   interface.
 - CSR object created implements "/xyz/openbmc_project/Certs/CSR" interface.
 - Caller needs to validate the CSR request parameters.
-- Caller need to wait on "InterfacesAdded" signal generated upon creation
-  of the CSR object to start reading CSR string.
+- Caller need to wait on "InterfacesAdded" signal generated upon creation of the
+  CSR object to start reading CSR string.
 
 ### Example usage for the GenerateCSR POST request
 
@@ -154,8 +150,8 @@
 
 ### Additional interfaces
 
-- CertificateService.ReplaceCertificate
-  Allows the user to replace an existing certificate.
+- CertificateService.ReplaceCertificate Allows the user to replace an existing
+  certificate.
 
 ### d-bus interfaces
 
@@ -164,16 +160,16 @@
 - Certs application must:
   - validate the certificate and Private key file by checking, if the Private
     key matches the public key in the certificate file.
-  - copy the certificate and Public Key file to the service specific path
-    based on a configuration file.
+  - copy the certificate and Public Key file to the service specific path based
+    on a configuration file.
   - Reload the listed service(s) for which the certificate is updated.
 
 #### d-bus interface to Delete certificate and Private Key
 
 - certificate manager should provide interface to delete the existing
   certificate.
-- Incase of server type certificate deleting a signed certificate will
-  create a new self signed certificate and will install the same.
+- Incase of server type certificate deleting a signed certificate will create a
+  new self signed certificate and will install the same.
 
 ### Boot process
 
@@ -202,9 +198,8 @@
   "/redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates"
 
 - Bmcweb receives the POST request and it maps the Redfish URI to the
-  corresponding Certificate Manager D-Bus URI.
-  e.g: HTTPS certificate collection URI
-  /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates mapped to
+  corresponding Certificate Manager D-Bus URI. e.g: HTTPS certificate collection
+  URI /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates mapped to
   /xyz/openbmc_project/certs/server/https.
 - Bmcweb initiates an asynchronous call which invokes the "Install" method of
   the Certificate Manager.
@@ -221,8 +216,8 @@
   the response message with newly created certificate details for success.
 - Certificate object D-Bus path mapped to corresponding Redfish certificate URI.
   e.g: /xyz/openbmc_project/certs/server/https/1 is mapped to
-  /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1
-  ID of the certificate is appended to the collection URI.
+  /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1 ID of the
+  certificate is appended to the collection URI.
 
 #### Certificate Replace
 
@@ -231,8 +226,7 @@
 - Redfish issues Replace certificate request by invoking the ReplaceCertificate
   action of the CertificateService.
 - Redfish Certificate Collection URI is mapped to corresponding Certificate
-  D-Bus object URI
-  e.g: HTTPS certificate object 1 URI
+  D-Bus object URI e.g: HTTPS certificate object 1 URI
   /redfish/v1/Managers/bmc/NetworkProtocol/HTTPS/Certificates/1 is mapped to
   /xyz/openbmc_project/certs/server/https/1.
 - Bmcweb receives POST request for Replace Certificate, invokes the Replace
@@ -257,8 +251,8 @@
 #### Certificate Deletion
 
 - For server and client certificate type the certificate deletion is not
-  allowed. In case of authority certificate type the delete option is
-  acceptable and can be done on individial certificates, for example:
+  allowed. In case of authority certificate type the delete option is acceptable
+  and can be done on individial certificates, for example:
 
 ```plain
 url: redfish/v1/Managers/bmc/Truststore/Certificates/1
diff --git a/yaml/xyz/openbmc_project/Channel/ChannelAccess.interface.yaml b/yaml/xyz/openbmc_project/Channel/ChannelAccess.interface.yaml
index 03abc50..072c04d 100644
--- a/yaml/xyz/openbmc_project/Channel/ChannelAccess.interface.yaml
+++ b/yaml/xyz/openbmc_project/Channel/ChannelAccess.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    This interface defines channel specific privilege access information
-    which is used for channel authorization. Application must determine
-    channel level privilege restriction based on this property.
+    This interface defines channel specific privilege access information which
+    is used for channel authorization. Application must determine channel level
+    privilege restriction based on this property.
 
 properties:
     - name: MaxPrivilege
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/Button.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/Button.interface.yaml
index 4acaf70..f5f4704 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/Button.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/Button.interface.yaml
@@ -1,36 +1,35 @@
 description: >
-    Button interface is a generic phosphor button interface  which supports
-    two primary actions (pressed/releasd). When the button is pressed
-    "Pressed" signal is emitted and when button is released then "Released"
+    Button interface is a generic phosphor button interface  which supports two
+    primary actions (pressed/releasd). When the button is pressed "Pressed"
+    signal is emitted and when button is released then "Released"
       signal is emitted.
 methods:
-  - name: simPress
-    description: >
-      Emulate button press.
-    errors:
-      - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
-      - xyz.openbmc_project.Chassis.Common.Error.IOError
-  - name: simRelease
-    description: >
-      Emulate button release.
-    errors:
-      - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
-      - xyz.openbmc_project.Chassis.Common.Error.IOError
-  - name: simLongPress
-    description: >
-      Emulate long button press.
-    errors:
-      - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
-      - xyz.openbmc_project.Chassis.Common.Error.IOError
+    - name: simPress
+      description: >
+          Emulate button press.
+      errors:
+          - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
+          - xyz.openbmc_project.Chassis.Common.Error.IOError
+    - name: simRelease
+      description: >
+          Emulate button release.
+      errors:
+          - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
+          - xyz.openbmc_project.Chassis.Common.Error.IOError
+    - name: simLongPress
+      description: >
+          Emulate long button press.
+      errors:
+          - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
+          - xyz.openbmc_project.Chassis.Common.Error.IOError
 
 properties:
     - name: Enabled
       type: boolean
       default: true
       description: >
-          Enable/disable the button object.
-          false means button is disabled
-          true means button is enabled
+          Enable/disable the button object. false means button is disabled true
+          means button is enabled
       errors:
           - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
           - xyz.openbmc_project.Chassis.Common.Error.IOError
@@ -38,10 +37,10 @@
 signals:
     - name: Released
       description: >
-        Button released signal
+          Button released signal
     - name: Pressed
       description: >
-        Button pressed signal
+          Button pressed signal
     - name: PressedLong
       description: >
-        Button long pressed signal
+          Button long pressed signal
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/HostSelector.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/HostSelector.interface.yaml
index 378f5f4..677b5f7 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/HostSelector.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/HostSelector.interface.yaml
@@ -1,18 +1,18 @@
 description: >
-    Host selector interface is used to keep the position of the host
-    selector HW switch as a property.This host selector position value
-    decides which host or bmc is currently selected in a multihost bmc
-    system so that the power and reset button events are routed to
-    the currently selected host or bmc's power control events.
+    Host selector interface is used to keep the position of the host selector HW
+    switch as a property.This host selector position value decides which host or
+    bmc is currently selected in a multihost bmc system so that the power and
+    reset button events are routed to the currently selected host or bmc's power
+    control events.
 
 properties:
     - name: Position
       type: size
       default: 0
       description: >
-          The current position of the selector. Position 1 to N selects
-          Host Instance t to N,Position 0 selects the BMC
-          ( N is maximum number of hosts ).
+          The current position of the selector. Position 1 to N selects Host
+          Instance t to N,Position 0 selects the BMC ( N is maximum number of
+          hosts ).
     - name: MaxPosition
       type: size
       default: 0
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/ID.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/ID.interface.yaml
index 5962652..d564185 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/ID.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/ID.interface.yaml
@@ -1,8 +1,8 @@
 description: >
     ID button is the system identification button, that allows the server to be
-    located in a rack, and can be enabled remotely via WebUI;
-    user can press ID button on the front panel and then walk around to the back
-    and quickly identify the rear bulkhead of the same server unit.
+    located in a rack, and can be enabled remotely via WebUI; user can press ID
+    button on the front panel and then walk around to the back and quickly
+    identify the rear bulkhead of the same server unit.
 methods:
     - name: simPress
       description: >
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/NMI.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/NMI.interface.yaml
index ba36a69..83c11f9 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/NMI.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/NMI.interface.yaml
@@ -1,9 +1,9 @@
 description: >
     NMI button is a Diagnostic Interrupt(Front Panel NMI).Diagnostic interrupt
-    is a non-maskable interrupt or signal for generating diagnostic traces
-    and core dumps from the operating system. The diagnostic interrupt button
-    is connected to the BMC through a front panel connector.
-    user can press NMI button on the front panel and then trigger NMI signal.
+    is a non-maskable interrupt or signal for generating diagnostic traces and
+    core dumps from the operating system. The diagnostic interrupt button is
+    connected to the BMC through a front panel connector. user can press NMI
+    button on the front panel and then trigger NMI signal.
 methods:
     - name: simPress
       description: >
@@ -17,9 +17,8 @@
       type: boolean
       default: true
       description: >
-          Enable/disable NMI button.
-          false means NMI button is disabled
-          true means NMI button is enabled
+          Enable/disable NMI button. false means NMI button is disabled true
+          means NMI button is enabled
       errors:
           - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
           - xyz.openbmc_project.Chassis.Common.Error.IOError
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/Power.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/Power.interface.yaml
index d594bd0..ad41aa4 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/Power.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/Power.interface.yaml
@@ -20,9 +20,8 @@
       type: boolean
       default: true
       description: >
-          Enable/disable power button.
-          false means power button is disabled
-          true means power button is enabled
+          Enable/disable power button. false means power button is disabled true
+          means power button is enabled
       errors:
           - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
           - xyz.openbmc_project.Chassis.Common.Error.IOError
diff --git a/yaml/xyz/openbmc_project/Chassis/Buttons/Reset.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Buttons/Reset.interface.yaml
index f67ed71..844c53c 100644
--- a/yaml/xyz/openbmc_project/Chassis/Buttons/Reset.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Buttons/Reset.interface.yaml
@@ -13,9 +13,8 @@
       type: boolean
       default: true
       description: >
-          Enable/disable reset button.
-          false means reset button is disabled
-          true means reset button is enabled
+          Enable/disable reset button. false means reset button is disabled true
+          means reset button is enabled
       errors:
           - xyz.openbmc_project.Chassis.Common.Error.UnsupportedCommand
           - xyz.openbmc_project.Chassis.Common.Error.IOError
diff --git a/yaml/xyz/openbmc_project/Chassis/Control/Power.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Control/Power.interface.yaml
index 702152e..bc4b156 100644
--- a/yaml/xyz/openbmc_project/Chassis/Control/Power.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Control/Power.interface.yaml
@@ -18,14 +18,10 @@
       type: boolean
       default: false
       description: >
-          PSU Power good property
-          It is a read-only property.
+          PSU Power good property It is a read-only property.
     - name: State
       type: int32
       default: 0
       description: >
-          System power status
-          0: power is off
-          1: power is on
-          Setting its value to change the system state
-          Read its value to get the system state.
+          System power status 0: power is off 1: power is on Setting its value
+          to change the system state Read its value to get the system state.
diff --git a/yaml/xyz/openbmc_project/Chassis/Intrusion.interface.yaml b/yaml/xyz/openbmc_project/Chassis/Intrusion.interface.yaml
index 2f9f50f..b2b5dfb 100644
--- a/yaml/xyz/openbmc_project/Chassis/Intrusion.interface.yaml
+++ b/yaml/xyz/openbmc_project/Chassis/Intrusion.interface.yaml
@@ -5,6 +5,5 @@
     - name: Status
       type: string
       description: >
-          Status string of chassis intrusion detector.
-          The value is defined in chassis redfish schema.
-          Can be "Normal" or "HardwareIntrusion".
+          Status string of chassis intrusion detector. The value is defined in
+          chassis redfish schema. Can be "Normal" or "HardwareIntrusion".
diff --git a/yaml/xyz/openbmc_project/Chassis/README.md b/yaml/xyz/openbmc_project/Chassis/README.md
index b32a54d..91ea16c 100644
--- a/yaml/xyz/openbmc_project/Chassis/README.md
+++ b/yaml/xyz/openbmc_project/Chassis/README.md
@@ -6,8 +6,8 @@
 
 ### Power Button Interface
 
-Power button interface `xyz.openbmc_project.Chassis.Buttons.Power`
-provides following methods, signals.
+Power button interface `xyz.openbmc_project.Chassis.Buttons.Power` provides
+following methods, signals.
 
 #### methods
 
@@ -22,8 +22,8 @@
 
 ### ID Button Interface
 
-ID button interface `xyz.openbmc_project.Chassis.Buttons.ID`
-provides following methods, signals.
+ID button interface `xyz.openbmc_project.Chassis.Buttons.ID` provides following
+methods, signals.
 
 #### methods
 
@@ -36,8 +36,8 @@
 
 ### Reset Button Interface
 
-ID button interface `xyz.openbmc_project.Chassis.Buttons.Reset`
-provides following methods, signals.
+ID button interface `xyz.openbmc_project.Chassis.Buttons.Reset` provides
+following methods, signals.
 
 #### methods
 
@@ -55,5 +55,5 @@
 
 ### properties
 
-Position - Value of the Host selector.
-MaxPosition - Max value that the Position value can hold.
+Position - Value of the Host selector. MaxPosition - Max value that the Position
+value can hold.
diff --git a/yaml/xyz/openbmc_project/Common/Callout/README.md b/yaml/xyz/openbmc_project/Common/Callout/README.md
index 995f958..d8d3384 100644
--- a/yaml/xyz/openbmc_project/Common/Callout/README.md
+++ b/yaml/xyz/openbmc_project/Common/Callout/README.md
@@ -43,9 +43,9 @@
 
 The way this inheritance will be implemented is that, Foo's metadata will
 include Callout.IIC's as well, so an application wanting to add an IIC callout
-will have to provide values for Foo and IIC metadata. Like mentioned before,
-due to the presence of the Callout.IIC metadata, the error handling component
-can figure out that the error Foo includes an IIC callout.
+will have to provide values for Foo and IIC metadata. Like mentioned before, due
+to the presence of the Callout.IIC metadata, the error handling component can
+figure out that the error Foo includes an IIC callout.
 
 Currently, defined callout interfaces in turn inherit
 `xyz.openbmc_project.Error.Callout.Device`, which has metadata common to
@@ -62,9 +62,9 @@
 
 This way, say an application wants to express an IIC callout in terms of a
 device path, for lack of IIC information. The application can add the callout
-metadata fields for both Callout.Device and Callout.IIC, but provide values
-only for Callout.Callout. That way the error handling component can still
-decipher this as an IIC callout.
+metadata fields for both Callout.Device and Callout.IIC, but provide values only
+for Callout.Callout. That way the error handling component can still decipher
+this as an IIC callout.
 
 ## Creation of a callout
 
@@ -79,18 +79,18 @@
 
 - The error-log server will detect that callout metadata is present, will
   extract the same and hand it over to a sub-module which will map callout
-  metadata to one or more inventory object paths, and will create an
-  association between the error object and the inventory object(s). The
-  mapping from callout metadata to inventory objects is mostly done via
-  the aid of code generated by the system MRW parsers.
+  metadata to one or more inventory object paths, and will create an association
+  between the error object and the inventory object(s). The mapping from callout
+  metadata to inventory objects is mostly done via the aid of code generated by
+  the system MRW parsers.
 
-- Generated code : consider a case where an application wants to callout
-  an EEPROM on the BMC planar, via a device path, such as
+- Generated code : consider a case where an application wants to callout an
+  EEPROM on the BMC planar, via a device path, such as
   /sys/devices/platform/ahb/ahb:apb/1e78a000.i2c/i2c-11/i2c-11/11-0051/eeprom.
   This would have to be mapped to the BMC planar as the FRU to be called out.
   MRW parser(s) could be written which, for every device in the IIC subsystem,
   can provide a corresponding inventory object path. The error-log server, in
-  this case, has to, by looking at the device path, determine that the device
-  is on an IIC bus, and make use of the code generated to map the device to
-  inventory objects.
-  Similar MRW parsers could be written for other device subsystems.
+  this case, has to, by looking at the device path, determine that the device is
+  on an IIC bus, and make use of the code generated to map the device to
+  inventory objects. Similar MRW parsers could be written for other device
+  subsystems.
diff --git a/yaml/xyz/openbmc_project/Common/FactoryReset/README.md b/yaml/xyz/openbmc_project/Common/FactoryReset/README.md
index d7fbcd8..719b453 100644
--- a/yaml/xyz/openbmc_project/Common/FactoryReset/README.md
+++ b/yaml/xyz/openbmc_project/Common/FactoryReset/README.md
@@ -12,14 +12,13 @@
 
 ### xyz.openbmc_project.Network
 
-Path: `/xyz/openbmc_project/network`
-The network factory reset overwrites the configuration for all configured
-network interfaces to a DHCP setting. Configuration changes will take effect
-the next time each interface is brought up - either manually or during a BMC
-reboot.
+Path: `/xyz/openbmc_project/network` The network factory reset overwrites the
+configuration for all configured network interfaces to a DHCP setting.
+Configuration changes will take effect the next time each interface is brought
+up - either manually or during a BMC reboot.
 
 ### xyz.openbmc_project.Software.BMC.Updater
 
-Path: `/xyz/openbmc_project/software`
-The BMC software updater factory reset clears any volumes and persistence files
-created by the BMC processes. This reset occurs only on the next BMC reboot.
+Path: `/xyz/openbmc_project/software` The BMC software updater factory reset
+clears any volumes and persistence files created by the BMC processes. This
+reset occurs only on the next BMC reboot.
diff --git a/yaml/xyz/openbmc_project/Common/FilePath.interface.yaml b/yaml/xyz/openbmc_project/Common/FilePath.interface.yaml
index 2b332ae..2accd42 100644
--- a/yaml/xyz/openbmc_project/Common/FilePath.interface.yaml
+++ b/yaml/xyz/openbmc_project/Common/FilePath.interface.yaml
@@ -1,9 +1,9 @@
 description: >
     An interface which encapsulates a file-system path on the BMC.
 
-    Typically, this is added onto an existing object path to show a
-    relationship between the object, in the dbus namespace, and a file, in
-    the filesystem namespace.
+    Typically, this is added onto an existing object path to show a relationship
+    between the object, in the dbus namespace, and a file, in the filesystem
+    namespace.
 properties:
     - name: Path
       type: string
diff --git a/yaml/xyz/openbmc_project/Common/ObjectPath.interface.yaml b/yaml/xyz/openbmc_project/Common/ObjectPath.interface.yaml
index 0c7a101..16b33ab 100644
--- a/yaml/xyz/openbmc_project/Common/ObjectPath.interface.yaml
+++ b/yaml/xyz/openbmc_project/Common/ObjectPath.interface.yaml
@@ -1,9 +1,9 @@
 description: >
     An interface which contains a D-Bus object path.
 
-    This may be used along with other interfaces when a particular
-    D-Bus object needs to show information about another object
-    and using associations is not possible.
+    This may be used along with other interfaces when a particular D-Bus object
+    needs to show information about another object and using associations is not
+    possible.
 
 properties:
     - name: Path
diff --git a/yaml/xyz/openbmc_project/Common/OriginatedBy.interface.yaml b/yaml/xyz/openbmc_project/Common/OriginatedBy.interface.yaml
index 10cf61a..a6cb9d1 100644
--- a/yaml/xyz/openbmc_project/Common/OriginatedBy.interface.yaml
+++ b/yaml/xyz/openbmc_project/Common/OriginatedBy.interface.yaml
@@ -5,17 +5,16 @@
     - name: OriginatorId
       type: string
       description: >
-          Unique Id of the originator that initiated the respective
-          operation. This is an implementation-defined string described
-          by a value of type OriginatorType. The originator id can be
-          shown in user interfaces but this field should not be used for
-          any programmatic interrogation of an object.
+          Unique Id of the originator that initiated the respective operation.
+          This is an implementation-defined string described by a value of type
+          OriginatorType. The originator id can be shown in user interfaces but
+          this field should not be used for any programmatic interrogation of an
+          object.
 
     - name: OriginatorType
       type: enum[self.OriginatorTypes]
       description: >
-          Type of the originator that initiated the respective
-          operation.
+          Type of the originator that initiated the respective operation.
 
 enumerations:
     - name: OriginatorTypes
@@ -30,5 +29,5 @@
                 A process running on the service initiated the operation.
           - name: SupportingService
             description: >
-                A process not running on the service but running on a supporting service
-                initiated the operation.
+                A process not running on the service but running on a supporting
+                service initiated the operation.
diff --git a/yaml/xyz/openbmc_project/Common/Progress.interface.yaml b/yaml/xyz/openbmc_project/Common/Progress.interface.yaml
index 139a1ff..2afa5b3 100644
--- a/yaml/xyz/openbmc_project/Common/Progress.interface.yaml
+++ b/yaml/xyz/openbmc_project/Common/Progress.interface.yaml
@@ -1,10 +1,9 @@
 description: >
-    Implement to provide the progress on user requested activity.
-    Objects which implements this interface should implement
-    xyz.openbmc_project.Object.Delete to delete individual entries.
-    The service hosting this interface should clear the entries after
-    some time or reaching some number of entries in stable states like
-    completed, failed or aborted.
+    Implement to provide the progress on user requested activity. Objects which
+    implements this interface should implement xyz.openbmc_project.Object.Delete
+    to delete individual entries. The service hosting this interface should
+    clear the entries after some time or reaching some number of entries in
+    stable states like completed, failed or aborted.
 
 properties:
     - name: Status
@@ -17,13 +16,13 @@
     - name: StartTime
       type: uint64
       description: >
-          Indicates when the request is created since the Epoch
-          (1 Jan 1970 00:00:00 UTC), in microseconds.
+          Indicates when the request is created since the Epoch (1 Jan 1970
+          00:00:00 UTC), in microseconds.
     - name: CompletedTime
       type: uint64
       description: >
-          Indicates when the state is completed since the Epoch
-          (1 Jan 1970 00:00:00 UTC), in microseconds.
+          Indicates when the state is completed since the Epoch (1 Jan 1970
+          00:00:00 UTC), in microseconds.
 
 enumerations:
     - name: OperationStatus
diff --git a/yaml/xyz/openbmc_project/Common/UUID.interface.yaml b/yaml/xyz/openbmc_project/Common/UUID.interface.yaml
index 7699674..c48c13e 100644
--- a/yaml/xyz/openbmc_project/Common/UUID.interface.yaml
+++ b/yaml/xyz/openbmc_project/Common/UUID.interface.yaml
@@ -4,5 +4,5 @@
     - name: UUID
       type: string
       description: >
-          UUID of object to which the interface is bound.
-          It is in canonical 8-4-4-4-12 format as per RFC 4122.
+          UUID of object to which the interface is bound. It is in canonical
+          8-4-4-4-12 format as per RFC 4122.
diff --git a/yaml/xyz/openbmc_project/Condition/HostFirmware.interface.yaml b/yaml/xyz/openbmc_project/Condition/HostFirmware.interface.yaml
index acb44a3..c4140a6 100644
--- a/yaml/xyz/openbmc_project/Condition/HostFirmware.interface.yaml
+++ b/yaml/xyz/openbmc_project/Condition/HostFirmware.interface.yaml
@@ -1,8 +1,8 @@
 description: >
-    Implement to provide information on the condition of the host firmware.
-    The expectation is the implementer of this interface utilize their host
-    protocol (IPMI, PLDM, ...) to check the state of the host firmware running
-    on the system.
+    Implement to provide information on the condition of the host firmware. The
+    expectation is the implementer of this interface utilize their host protocol
+    (IPMI, PLDM, ...) to check the state of the host firmware running on the
+    system.
 
 properties:
     - name: CurrentFirmwareCondition
diff --git a/yaml/xyz/openbmc_project/Control/Boot/Mode.interface.yaml b/yaml/xyz/openbmc_project/Control/Boot/Mode.interface.yaml
index 6d9608a..a807585 100644
--- a/yaml/xyz/openbmc_project/Control/Boot/Mode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Boot/Mode.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Implement to set boot mode. The mode typically identifies
-    the end target of the boot process.
+    Implement to set boot mode. The mode typically identifies the end target of
+    the boot process.
 
 properties:
     - name: BootMode
diff --git a/yaml/xyz/openbmc_project/Control/Boot/RebootAttempts.interface.yaml b/yaml/xyz/openbmc_project/Control/Boot/RebootAttempts.interface.yaml
index 63d13ee..dbd6443 100644
--- a/yaml/xyz/openbmc_project/Control/Boot/RebootAttempts.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Boot/RebootAttempts.interface.yaml
@@ -10,4 +10,4 @@
       type: uint32
       description: >
           Number of total reboot attempts allowed.
-      default: 3
\ No newline at end of file
+      default: 3
diff --git a/yaml/xyz/openbmc_project/Control/CFMLimit.interface.yaml b/yaml/xyz/openbmc_project/Control/CFMLimit.interface.yaml
index 5946f3c..ae47c86 100644
--- a/yaml/xyz/openbmc_project/Control/CFMLimit.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/CFMLimit.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement to provide a CFM upper limit for fan control.
-    This can be used with a CFM algorithm to calculate the
-    maximum allowed fan speed for a system.
+    Implement to provide a CFM upper limit for fan control. This can be used
+    with a CFM algorithm to calculate the maximum allowed fan speed for a
+    system.
 
 properties:
     - name: Limit
diff --git a/yaml/xyz/openbmc_project/Control/ChassisCapabilities.interface.yaml b/yaml/xyz/openbmc_project/Control/ChassisCapabilities.interface.yaml
index 3ea57ab..83a5362 100644
--- a/yaml/xyz/openbmc_project/Control/ChassisCapabilities.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/ChassisCapabilities.interface.yaml
@@ -5,9 +5,9 @@
       type: byte
       description: >
           Note: Please use the individual bit fields for Capabilities Flags
-          going forward. This common byte representation is deprecated.
-          Chassis capabilities flags. bit1= Provides front panel lockout,
-          bit0 = Provides intrusion. All other bits reserved.
+          going forward. This common byte representation is deprecated. Chassis
+          capabilities flags. bit1= Provides front panel lockout, bit0 =
+          Provides intrusion. All other bits reserved.
     - name: ChassisIntrusionEnabled
       type: boolean
       description: >
diff --git a/yaml/xyz/openbmc_project/Control/Host.interface.yaml b/yaml/xyz/openbmc_project/Control/Host.interface.yaml
index eec2ce0..2ff27d5 100644
--- a/yaml/xyz/openbmc_project/Control/Host.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Host.interface.yaml
@@ -33,14 +33,14 @@
       values:
           - name: SoftOff
             description: >
-                Host firmware should do a clean shutdown and request a chassis power
-                off to the BMC when complete.  This command will return once the
-                command has been sent to the host.
+                Host firmware should do a clean shutdown and request a chassis
+                power off to the BMC when complete.  This command will return
+                once the command has been sent to the host.
           - name: Heartbeat
             description: >
                 Note: This is in the process of being deprecated in favor of the
-                new xyz.openbmc_project.Condition.HostFirmware interface.
-                Used to determine if the host is running and functional.  This
+                new xyz.openbmc_project.Condition.HostFirmware interface. Used
+                to determine if the host is running and functional.  This
                 command will return once the command has been sent to the host.
                 The response to the attention and the reading of the command
                 provides the needed functional information.
diff --git a/yaml/xyz/openbmc_project/Control/Host/NMI.interface.yaml b/yaml/xyz/openbmc_project/Control/Host/NMI.interface.yaml
index 8b9c17a..8b2c19e 100644
--- a/yaml/xyz/openbmc_project/Control/Host/NMI.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Host/NMI.interface.yaml
@@ -5,7 +5,7 @@
 methods:
     - name: NMI
       description: >
-          Generic method to initiate non maskable interrupt on all
-          host processors.
+          Generic method to initiate non maskable interrupt on all host
+          processors.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
diff --git a/yaml/xyz/openbmc_project/Control/Host/TurboAllowed.interface.yaml b/yaml/xyz/openbmc_project/Control/Host/TurboAllowed.interface.yaml
index 41b7394..7e9f902 100644
--- a/yaml/xyz/openbmc_project/Control/Host/TurboAllowed.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Host/TurboAllowed.interface.yaml
@@ -1,7 +1,6 @@
 description: >
-    Turbo mode is a setting to enable processor frequency boosting.
-    This interface is used to tell host that it is allowed to turn
-    on turbo mode.
+    Turbo mode is a setting to enable processor frequency boosting. This
+    interface is used to tell host that it is allowed to turn on turbo mode.
 
 properties:
     - name: TurboAllowed
diff --git a/yaml/xyz/openbmc_project/Control/MinimumShipLevel.interface.yaml b/yaml/xyz/openbmc_project/Control/MinimumShipLevel.interface.yaml
index 7de8070..fac7d05 100644
--- a/yaml/xyz/openbmc_project/Control/MinimumShipLevel.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/MinimumShipLevel.interface.yaml
@@ -1,7 +1,6 @@
 description: >
-    'An implementation may provide a single instance of
-    MinimumShipLevelRequired on
-    /xyz/openbmc_project/control/minimum_ship_level_required.
+    'An implementation may provide a single instance of MinimumShipLevelRequired
+    on /xyz/openbmc_project/control/minimum_ship_level_required.
 
     The definition of enforcement of this setting is implementation defined.'
 
@@ -9,6 +8,6 @@
     - name: MinimumShipLevelRequired
       type: boolean
       description: >
-          'A user has requested that the implementation
-          specific requirements associated with minimum ship level
-          enforcement be applied when MinimumShipLevelRequired is true.'
+          'A user has requested that the implementation specific requirements
+          associated with minimum ship level enforcement be applied when
+          MinimumShipLevelRequired is true.'
diff --git a/yaml/xyz/openbmc_project/Control/Mode.interface.yaml b/yaml/xyz/openbmc_project/Control/Mode.interface.yaml
index da40d0d..4a49daf 100644
--- a/yaml/xyz/openbmc_project/Control/Mode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Mode.interface.yaml
@@ -1,10 +1,10 @@
 description: >
-    Implement to provide manual control for an object.  Also provides
-    for the notion of a fail-safe mode.
+    Implement to provide manual control for an object.  Also provides for the
+    notion of a fail-safe mode.
 
-    Control.Mode.Manual is read/write.
-    Control.Mode.FailSafe is read/write, however not all implementations
-    may respect having this property set externally.
+    Control.Mode.Manual is read/write. Control.Mode.FailSafe is read/write,
+    however not all implementations may respect having this property set
+    externally.
 
 properties:
     - name: Manual
diff --git a/yaml/xyz/openbmc_project/Control/Power/ACPIPowerState.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/ACPIPowerState.interface.yaml
index d7ae808..70676c8 100644
--- a/yaml/xyz/openbmc_project/Control/Power/ACPIPowerState.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/ACPIPowerState.interface.yaml
@@ -24,11 +24,12 @@
                 Working, the system is running
           - name: S1_D1
             description: >
-                Hardware context maintained, typically equates to proc/chip
-                set clocks stopped.
+                Hardware context maintained, typically equates to proc/chip set
+                clocks stopped.
           - name: S2_D2
             description: >
-                Typically equates to stopped clocks with proc/cache context lost.
+                Typically equates to stopped clocks with proc/cache context
+                lost.
           - name: S3_D3
             description: >
                 Typically equates to "suspend-to-RAM".
diff --git a/yaml/xyz/openbmc_project/Control/Power/Cap.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/Cap.interface.yaml
index 393bb1f..acbf5e9 100644
--- a/yaml/xyz/openbmc_project/Control/Power/Cap.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/Cap.interface.yaml
@@ -12,8 +12,8 @@
     - name: PowerCapEnable
       type: boolean
       description: >
-          Power cap enable.  Set to true to enable the PowerCap, false
-          to disable it.
+          Power cap enable.  Set to true to enable the PowerCap, false to
+          disable it.
 
     #TODO: These following bounds are currently owned by Settings but need to be
     #      written by OCC.Control service so must be writable for now.
@@ -37,8 +37,8 @@
       #    - readonly
       default: 0
       description: >
-          Minimum supported soft user PowerCap setting.
-          The min soft user PowerCap value is normally less than or equal to
-          the MinPowerCapValue. When the PowerCap is set to any value between
-          MinSoftPowerCapValue and MinPowerCapValue an attempt will be made to
-          maintain the cap but it will not be guaranted.
+          Minimum supported soft user PowerCap setting. The min soft user
+          PowerCap value is normally less than or equal to the MinPowerCapValue.
+          When the PowerCap is set to any value between MinSoftPowerCapValue and
+          MinPowerCapValue an attempt will be made to maintain the cap but it
+          will not be guaranted.
diff --git a/yaml/xyz/openbmc_project/Control/Power/CapLimits.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/CapLimits.interface.yaml
index 2fe322f..9e17801 100644
--- a/yaml/xyz/openbmc_project/Control/Power/CapLimits.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/CapLimits.interface.yaml
@@ -22,9 +22,8 @@
           - readonly
       default: 0
       description: >
-          Minimum supported soft user PowerCap setting.
-          The min soft user PowerCap value is normally less than or equal to
-          the MinPowerCapValue. When the PowerCap is set to any value between
-          MinSoftPowerCapValue and MinPowerCapValue an attempt will be made to
-          maintain the cap but it will not be guaranted.
-
+          Minimum supported soft user PowerCap setting. The min soft user
+          PowerCap value is normally less than or equal to the MinPowerCapValue.
+          When the PowerCap is set to any value between MinSoftPowerCapValue and
+          MinPowerCapValue an attempt will be made to maintain the cap but it
+          will not be guaranted.
diff --git a/yaml/xyz/openbmc_project/Control/Power/IdlePowerSaver.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/IdlePowerSaver.interface.yaml
index ce8c857..c1a2d98 100644
--- a/yaml/xyz/openbmc_project/Control/Power/IdlePowerSaver.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/IdlePowerSaver.interface.yaml
@@ -30,8 +30,8 @@
       type: uint64
       description: >
           This property shall indicate the duration in milliseconds the computer
-          system is above the ExitUtilizationPercent value before the idle
-          power saver is deactivated.
+          system is above the ExitUtilizationPercent value before the idle power
+          saver is deactivated.
 
     - name: Active
       type: boolean
diff --git a/yaml/xyz/openbmc_project/Control/Power/Mode.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/Mode.interface.yaml
index cb35501..bca1f18 100644
--- a/yaml/xyz/openbmc_project/Control/Power/Mode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/Mode.interface.yaml
@@ -14,9 +14,8 @@
           - readonly
       default: false
       description: >
-          This property shall indicate whether the System is in Safe Mode.
-          When this is true, the system power mode is not being used in the
-          system.
+          This property shall indicate whether the System is in Safe Mode. When
+          this is true, the system power mode is not being used in the system.
 
 enumerations:
     - name: PowerMode
diff --git a/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml b/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml
index 34f4217..2b21ce2 100644
--- a/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Power/RestorePolicy.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement to specify power transition behavior on a BMC reset.
-    The implementation may choose to only enforce the policy on
-    a power loss or on both a power loss and BMC reboot.
+    Implement to specify power transition behavior on a BMC reset. The
+    implementation may choose to only enforce the policy on a power loss or on
+    both a power loss and BMC reboot.
 
 properties:
     - name: PowerRestorePolicy
@@ -14,8 +14,7 @@
       default: 0
       description: >
           The delay in microseconds before invoke power restore policy after
-          power applied.
-          0 - disable delay.
+          power applied. 0 - disable delay.
 
 enumerations:
     - name: Policy
@@ -33,5 +32,5 @@
                 Perform a complete power off process.
           - name: Restore
             description: >
-                Restore power to last requested state recorded before the BMC was
-                reset.
+                Restore power to last requested state recorded before the BMC
+                was reset.
diff --git a/yaml/xyz/openbmc_project/Control/PowerSupplyRedundancy.interface.yaml b/yaml/xyz/openbmc_project/Control/PowerSupplyRedundancy.interface.yaml
index 28b8474..432b2c2 100644
--- a/yaml/xyz/openbmc_project/Control/PowerSupplyRedundancy.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/PowerSupplyRedundancy.interface.yaml
@@ -14,8 +14,8 @@
     - name: RotationAlgorithm
       type: enum[self.Algo]
       description: >
-          Rotation algorithm use for cold redundancy. 0 is BMC Specific, 1 is User
-          Specific.
+          Rotation algorithm use for cold redundancy. 0 is BMC Specific, 1 is
+          User Specific.
     - name: RotationRankOrder
       type: array[byte]
       description: >
@@ -25,8 +25,8 @@
       type: uint32
       description: >
           Rotation Period for cold redundancy. If rotation algorithm is BMC
-          Specific, and rotation is enabled, BMC will change PSU rank order after
-          this time. The unit of this PeriodOfRotation is in seconds.
+          Specific, and rotation is enabled, BMC will change PSU rank order
+          after this time. The unit of this PeriodOfRotation is in seconds.
     - name: ColdRedundancyStatus
       type: enum[self.Status]
       description: >
@@ -48,14 +48,14 @@
       values:
           - name: bmcSpecific
             description: >
-                With BMC Specific algorithm, when rotation happen, BMC will add 1 to
-                the rank order in each PSU and change the last rank order to the
-                first rank order.
+                With BMC Specific algorithm, when rotation happen, BMC will add
+                1 to the rank order in each PSU and change the last rank order
+                to the first rank order.
           - name: userSpecific
             description: >
-                With User Specific algorithm, user need to set the RotationRankOrder
-                every time before rotation happen, then BMC will update the rank
-                order to PSU.
+                With User Specific algorithm, user need to set the
+                RotationRankOrder every time before rotation happen, then BMC
+                will update the rank order to PSU.
     - name: Status
       description: >
           Cold redundancy setting status.
@@ -67,6 +67,6 @@
                 value, the status will show in progress.
           - name: completed
             description: >
-                For single ndoe system, the status always keep show completed. For
-                multi-node system, only after all the nodes sync to same value of
-                the properties, the status will be completed.
+                For single ndoe system, the status always keep show completed.
+                For multi-node system, only after all the nodes sync to same
+                value of the properties, the status will be completed.
diff --git a/yaml/xyz/openbmc_project/Control/README.msl.md b/yaml/xyz/openbmc_project/Control/README.msl.md
index cd853ab..ff96fce 100644
--- a/yaml/xyz/openbmc_project/Control/README.msl.md
+++ b/yaml/xyz/openbmc_project/Control/README.msl.md
@@ -4,13 +4,13 @@
 
 The OpenBMC API provides a global setting for enforcement of minimum ship level.
 Typically a setting like this would be used to enable the use of hardware
-configurations in platform development that may not necessarily be supported
-in a manufacturing or field environment.
+configurations in platform development that may not necessarily be supported in
+a manufacturing or field environment.
 
-If an OpenBMC implementation provides MinimumShipLevelRequired, it must be
-on `/xyz/openbmc_project/control/minimum_ship_level_required`. There are
-**no** requirements on how the setting is used; implementations are free to
-react to the value of the setting however they choose.
+If an OpenBMC implementation provides MinimumShipLevelRequired, it must be on
+`/xyz/openbmc_project/control/minimum_ship_level_required`. There are **no**
+requirements on how the setting is used; implementations are free to react to
+the value of the setting however they choose.
 
 In anticipation of a common use case of examining hardware assets, determining
 if they are of a certain revision or part, and taking some action if they are
@@ -18,18 +18,17 @@
 MeetsMinimumShipLevel.
 
 MeetsMinimumShipLevel can be implemented on any object in the inventory
-namespace. Again, there are no requirements on what an implementation does
-when a particular inventory object does or does not meet the minimum ship
-level.
+namespace. Again, there are no requirements on what an implementation does when
+a particular inventory object does or does not meet the minimum ship level.
 
 ## Implementation Notes
 
-Consider a server platform with an MSL requirement that a fan control card is
-a certain revision, and if it is not, the server must not be allowed to
-boot, unless a user explicitly specifies otherwise.
+Consider a server platform with an MSL requirement that a fan control card is a
+certain revision, and if it is not, the server must not be allowed to boot,
+unless a user explicitly specifies otherwise.
 
-Phosphor OpenBMC provides a basic implementation of MinimumShipLevelRequired.
-It maintains a setting store and interface for the setting value. This
+Phosphor OpenBMC provides a basic implementation of MinimumShipLevelRequired. It
+maintains a setting store and interface for the setting value. This
 implementation is suitable for the hypothetical platform implementation
 requirements, allowing a user to toggle the setting back and forth.
 
@@ -39,9 +38,9 @@
 Phosphor OpenBMC does not provide any applications that do this. If your
 application is general purpose and could meet the needs of others, consider
 contributing it to Phosphor OpenBMC. A possible implementation for the
-hypothetical fan control card might be an application that validates a number
-of hwmon sensors exist and then sets the MinimumShipLevelRequired on the
-fan inventory object accordingly.
+hypothetical fan control card might be an application that validates a number of
+hwmon sensors exist and then sets the MinimumShipLevelRequired on the fan
+inventory object accordingly.
 
 Finally, the setting and the inventory assets must be compared and the server
 prevented from powering on. This could be accomplished with a custom application
diff --git a/yaml/xyz/openbmc_project/Control/Security/RestrictionMode.interface.yaml b/yaml/xyz/openbmc_project/Control/Security/RestrictionMode.interface.yaml
index fa69d7b..98e7589 100644
--- a/yaml/xyz/openbmc_project/Control/Security/RestrictionMode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Security/RestrictionMode.interface.yaml
@@ -23,17 +23,15 @@
                 Prevent, if in the blacklist.
           - name: Provisioning
             description: >
-                Indicate that system is in provisioning mode
-                and all commands are allowed in system interface
-                in both pre and post BIOS boot.
+                Indicate that system is in provisioning mode and all commands
+                are allowed in system interface in both pre and post BIOS boot.
           - name: ProvisionedHostWhitelist
             description: >
-                Commands in the whitelist will only be executed
-                through system interface after BIOS POST complete.
-                All KCS commands are supported before POST complete.
+                Commands in the whitelist will only be executed through system
+                interface after BIOS POST complete. All KCS commands are
+                supported before POST complete.
           - name: ProvisionedHostDisabled
             description: >
-                Commands through system interface are executed only
-                till BIOS POST complete notification, after
-                which system interface commands are blocked (except BIOS SMI
-                based ones).
+                Commands through system interface are executed only till BIOS
+                POST complete notification, after which system interface
+                commands are blocked (except BIOS SMI based ones).
diff --git a/yaml/xyz/openbmc_project/Control/Security/SpecialMode.interface.yaml b/yaml/xyz/openbmc_project/Control/Security/SpecialMode.interface.yaml
index e8649a2..c0cef1d 100644
--- a/yaml/xyz/openbmc_project/Control/Security/SpecialMode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Security/SpecialMode.interface.yaml
@@ -17,10 +17,9 @@
                 BMC is under normal working condition.
           - name: Manufacturing
             description: >
-                Indicate that BMC is in manufacturing mode
-                and is allowed to perform any manufacturing related
-                activity
+                Indicate that BMC is in manufacturing mode and is allowed to
+                perform any manufacturing related activity
           - name: ValidationUnsecure
             description: >
-                Indicate that BMC is in validation mode, and can
-                execute any special validation related commands
+                Indicate that BMC is in validation mode, and can execute any
+                special validation related commands
diff --git a/yaml/xyz/openbmc_project/Control/Service/README.md b/yaml/xyz/openbmc_project/Control/Service/README.md
index f0ae013..38a016e 100644
--- a/yaml/xyz/openbmc_project/Control/Service/README.md
+++ b/yaml/xyz/openbmc_project/Control/Service/README.md
@@ -4,9 +4,9 @@
 
 Applications must use service manager daemon to configure services like
 phosphor-ipmi-net, bmcweb, obmc-console etc in the system, instead of directly
-controlling the same using 'systemd' or 'iptables'. This way client
-applications doesn't need to change to configure services, when the
-implementations differ. The list of services supported are:
+controlling the same using 'systemd' or 'iptables'. This way client applications
+doesn't need to change to configure services, when the implementations differ.
+The list of services supported are:
 
 - "bmcweb"
 - "obmc-console"`
@@ -16,16 +16,15 @@
 
 ## Implementation Details
 
-Service manager daemon will create D-Bus objects for configurable services
-in the system under the object path `/xyz/openbmc_project/control/service`. For
+Service manager daemon will create D-Bus objects for configurable services in
+the system under the object path `/xyz/openbmc_project/control/service`. For
 each instance of the service there will be a D-Bus object
-`/xyz/openbmc_project/control/service/<service-name>`.
-For example, if there are two instances of `phosphor-ipmi-net` then there
-will be two D-Bus objects
-`/xyz/openbmc_project/control/service/phosphor_2dipmi_2dnet_40eth0`
-and `/xyz/openbmc_project/control/service/phosphor_2dipmi_2dnet_40eth1`.
-The D-Bus object manages both the associated service and socket unit files.
-The D-Bus object implements the interface
+`/xyz/openbmc_project/control/service/<service-name>`. For example, if there are
+two instances of `phosphor-ipmi-net` then there will be two D-Bus objects
+`/xyz/openbmc_project/control/service/phosphor_2dipmi_2dnet_40eth0` and
+`/xyz/openbmc_project/control/service/phosphor_2dipmi_2dnet_40eth1`. The D-Bus
+object manages both the associated service and socket unit files. The D-Bus
+object implements the interface
 `xyz.openbmc_project.Control.Service.Attributes`. Network services like bmcweb,
 phosphor-ipmi-net also implements the
 `xyz.openbmc_project.Control.Service.SocketAttributes` interface.
@@ -47,25 +46,24 @@
   other service dependencies to satisfy. The service cannot be enabled if the
   service is masked.
 
-- Masked - indicates whether the service is masked, `true` indicates the
-  service is permanently disabled and `false` indicates the service
-  is enabled. If the property is set to `true`, then the service is
-  permanently disabled and the service is stopped. If the property
-  is set to `false` then the service is enabled and starts running.
+- Masked - indicates whether the service is masked, `true` indicates the service
+  is permanently disabled and `false` indicates the service is enabled. If the
+  property is set to `true`, then the service is permanently disabled and the
+  service is stopped. If the property is set to `false` then the service is
+  enabled and starts running.
 
-- Running - indicates the current state of the service, `true` if the service
-  is running and `false` if the service is not running. This property
-  can be used to change the running state of the service, to start the
-  service set to `true` and to stop the service set to `false`. The
-  service cannot be started if the service is Masked.
+- Running - indicates the current state of the service, `true` if the service is
+  running and `false` if the service is not running. This property can be used
+  to change the running state of the service, to start the service set to `true`
+  and to stop the service set to `false`. The service cannot be started if the
+  service is Masked.
 
 ### xyz.openbmc_project.Control.Service.SocketAttributes interface
 
 #### properties
 
-- Port - Port number to which the service is configured to listen, if
-  applicable for service. Services like obmc-console will not
-  implement this interface.
+- Port - Port number to which the service is configured to listen, if applicable
+  for service. Services like obmc-console will not implement this interface.
 
 ## Usage
 
diff --git a/yaml/xyz/openbmc_project/Control/Service/SocketAttributes.interface.yaml b/yaml/xyz/openbmc_project/Control/Service/SocketAttributes.interface.yaml
index 67a73a7..0c8ba2a 100644
--- a/yaml/xyz/openbmc_project/Control/Service/SocketAttributes.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/Service/SocketAttributes.interface.yaml
@@ -3,7 +3,8 @@
     activation. Applications can expose the port number of a network service by
     implementing this interface. For example, application like
     service-config-manager will implement this interface for network services
-    like bmcweb and phosphor-ipmi-net and allow the port number to be configured.
+    like bmcweb and phosphor-ipmi-net and allow the port number to be
+    configured.
 
 properties:
     - name: Port
diff --git a/yaml/xyz/openbmc_project/Control/ThermalMode.interface.yaml b/yaml/xyz/openbmc_project/Control/ThermalMode.interface.yaml
index 742ba35..901c934 100644
--- a/yaml/xyz/openbmc_project/Control/ThermalMode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/ThermalMode.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Implement to provide alternative thermal control modes of a system
-    that can be enabled, overriding the system defaults.
+    Implement to provide alternative thermal control modes of a system that can
+    be enabled, overriding the system defaults.
 
     Control.ThermalMode.Supported is read only.
         Implementation of this interface populates the list of supported modes.
diff --git a/yaml/xyz/openbmc_project/Control/VoltageRegulatorMode.interface.yaml b/yaml/xyz/openbmc_project/Control/VoltageRegulatorMode.interface.yaml
index 185b9d2..0c2bcd2 100644
--- a/yaml/xyz/openbmc_project/Control/VoltageRegulatorMode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Control/VoltageRegulatorMode.interface.yaml
@@ -3,16 +3,15 @@
     Control.VoltageRegulatorProfile.Supported is read only.  Implementation of
     the Supported property populates the list of supported modes.  In the case
     where the VR has a well defined default, implementations should place the
-    default in index 0.
-    Control.VoltageRegulatorProfile.Current is read/write and sets the
-    implementation specific mode for the voltage regulator to run in.  The
-    definitions of said enum are implementation defined, as systems likely will
-    have a multitude of possible states.  Some examples of naming might be
-    "HighPower" or "LowPower" in the case of bipolar power states, or might be
-    something more complex like, "Profile 1", "Profile 2", "Profile 3" if the VR
-    itself defines the interfaces.
-    Implementations may implement this alongside to a VoltageRegulatorControl
-    interface, and may react to the results of changes to the Control interface.
+    default in index 0. Control.VoltageRegulatorProfile.Current is read/write
+    and sets the implementation specific mode for the voltage regulator to run
+    in.  The definitions of said enum are implementation defined, as systems
+    likely will have a multitude of possible states.  Some examples of naming
+    might be "HighPower" or "LowPower" in the case of bipolar power states, or
+    might be something more complex like, "Profile 1", "Profile 2", "Profile 3"
+    if the VR itself defines the interfaces. Implementations may implement this
+    alongside to a VoltageRegulatorControl interface, and may react to the
+    results of changes to the Control interface.
 
 properties:
     - name: Supported
diff --git a/yaml/xyz/openbmc_project/Dump/Create.interface.yaml b/yaml/xyz/openbmc_project/Dump/Create.interface.yaml
index e8094d2..bc43fe2 100644
--- a/yaml/xyz/openbmc_project/Dump/Create.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/Create.interface.yaml
@@ -1,13 +1,12 @@
 description: >
-    Implement to capture various types of dumps from the
-    host or BMC. This interface is for user to request a particular
-    type of dump.
+    Implement to capture various types of dumps from the host or BMC. This
+    interface is for user to request a particular type of dump.
 
-    Any OpenBMC implementation should provide one implementation
-    of xyz.openbmc_project.Dump.Create per dump type on
-    /xyz/openbmc_project/dump/<dump type>. On multi-host or on multi-BMC
-    systems the instance number can be added to the path to differentiate,
-    for example /xyz/openbmc_project/dump/<dump type><instance-id>.
+    Any OpenBMC implementation should provide one implementation of
+    xyz.openbmc_project.Dump.Create per dump type on
+    /xyz/openbmc_project/dump/<dump type>. On multi-host or on multi-BMC systems
+    the instance number can be added to the path to differentiate, for example
+    /xyz/openbmc_project/dump/<dump type><instance-id>.
 
 methods:
     - name: CreateDump
@@ -17,15 +16,13 @@
           - name: AdditionalData
             type: dict[string, variant[string,uint64]]
             description: >
-                The additional data, if any, for initiating the dump.
-                The key in this case should be an implementation
-                specific enum defined for the specific type of dump
-                either in xyz or in a domain.
-                The values can be either a string or a 64 bit number.
-                The enum-format string is required to come from a
-                parallel class with this specific Enum name.
-                All of the Enum strings should be in the format
-                'domain.Dump.Create.CreateParameters.ParamName'.
+                The additional data, if any, for initiating the dump. The key in
+                this case should be an implementation specific enum defined for
+                the specific type of dump either in xyz or in a domain. The
+                values can be either a string or a 64 bit number. The
+                enum-format string is required to come from a parallel class
+                with this specific Enum name. All of the Enum strings should be
+                in the format 'domain.Dump.Create.CreateParameters.ParamName'.
                 e.g.:
                   {
                     "key1": "value1",
@@ -38,8 +35,8 @@
             type: object_path
             description: >
                 The object path of the object that implements
-                xyz.openbmc_project.Common.Progress to track the progress
-                of the dump
+                xyz.openbmc_project.Common.Progress to track the progress of the
+                dump
       errors:
           - xyz.openbmc_project.Common.File.Error.Open
           - xyz.openbmc_project.Common.File.Error.Write
@@ -54,13 +51,13 @@
       description: >
           Additional parameters for creating the dump.
       values:
-        - name: 'OriginatorId'
-          description: >
-              Unique Id of the originator of the respective
-              operation. This property is defined in xyz.openbmc_project.
-              Common.OriginatedBy interface.
-        - name: 'OriginatorType'
-          description: >
-              Type of the originator that initiated the respective
-              operation. This property is defined in xyz.openbmc_project.
-              Common.OriginatedBy interface.
+          - name: "OriginatorId"
+            description: >
+                Unique Id of the originator of the respective operation. This
+                property is defined in xyz.openbmc_project. Common.OriginatedBy
+                interface.
+          - name: "OriginatorType"
+            description: >
+                Type of the originator that initiated the respective operation.
+                This property is defined in xyz.openbmc_project.
+                Common.OriginatedBy interface.
diff --git a/yaml/xyz/openbmc_project/Dump/Entry.interface.yaml b/yaml/xyz/openbmc_project/Dump/Entry.interface.yaml
index a6de741..34c0868 100644
--- a/yaml/xyz/openbmc_project/Dump/Entry.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/Entry.interface.yaml
@@ -2,12 +2,10 @@
     Implement to provide Dump attributes.
 
     Object which implements this interface must implement
-    xyz.openbmc_project.Time.EpochTime for the Dump
-    creation time.
-    Object which implements this interface should implement
-    xyz.openbmc_project.Object.Delete to allow the deletion of
-    individual Dump objects (and its dump object manager should
-    implement xyz.openbmc_project.Collection.DeleteAll).
+    xyz.openbmc_project.Time.EpochTime for the Dump creation time. Object which
+    implements this interface should implement xyz.openbmc_project.Object.Delete
+    to allow the deletion of individual Dump objects (and its dump object
+    manager should implement xyz.openbmc_project.Collection.DeleteAll).
 
 methods:
     - name: InitiateOffload
@@ -40,10 +38,9 @@
     - name: Offloaded
       type: boolean
       description: >
-          Indicates whether the dump is offloaded to a client.
-          The BMC application which knows the status of the offload
-          operation should set this to true once the entire dump is
-          offloaded.
+          Indicates whether the dump is offloaded to a client. The BMC
+          application which knows the status of the offload operation should set
+          this to true once the entire dump is offloaded.
     - name: OffloadUri
       type: string
       description: >
diff --git a/yaml/xyz/openbmc_project/Dump/Entry/BMC.interface.yaml b/yaml/xyz/openbmc_project/Dump/Entry/BMC.interface.yaml
index 562939b..7503cec 100644
--- a/yaml/xyz/openbmc_project/Dump/Entry/BMC.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/Entry/BMC.interface.yaml
@@ -1,5 +1,5 @@
 description: >
     Implement this to add BMC dump management.
 
-    BMC dump is generated on the BMC with debug data
-    for debugging the issues encountered on the BMC.
+    BMC dump is generated on the BMC with debug data for debugging the issues
+    encountered on the BMC.
diff --git a/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml b/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml
index 6d74228..5c8b6b8 100644
--- a/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/Entry/FaultLog.interface.yaml
@@ -11,17 +11,16 @@
     - name: AdditionalTypeName
       type: string
       description: >
-          Additional string to further identify the Type (e.g. it
-          can indicate the OEM format of a Crashdump)
+          Additional string to further identify the Type (e.g. it can indicate
+          the OEM format of a Crashdump)
       flags:
           - const
     - name: PrimaryLogId
       type: string
       description: >
-          This is intended to be a unique identifier, depending on
-          Type, to reference the primary fault data log but is not
-          intended otherwise to be programatically interpreted
-          (e.g. string parsing)
+          This is intended to be a unique identifier, depending on Type, to
+          reference the primary fault data log but is not intended otherwise to
+          be programatically interpreted (e.g. string parsing)
       flags:
           - const
 
@@ -35,6 +34,6 @@
                 UEFI Common Platform Error Record
           - name: Crashdump
             description: >
-                Collection of processor and chipset register values
-                typically gathered for debugging purposes at the time
-                of a crash (or sometimes on-demand)
+                Collection of processor and chipset register values typically
+                gathered for debugging purposes at the time of a crash (or
+                sometimes on-demand)
diff --git a/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml b/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml
index 634c3b7..397aed2 100644
--- a/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/Entry/System.interface.yaml
@@ -1,19 +1,18 @@
 description: >
     Implement this to add system dump management.
 
-    System dumps are dump of the host memory and hardware states
-    generated during a failure in the host firmware. This can be a huge
-    dump stored in the host memory, the BMC doesnt store this dump but
-    stream this dump to an external client based on the offload request.
-    Apart from system generated system dump, users can also request for
-    this kind of dump.
+    System dumps are dump of the host memory and hardware states generated
+    during a failure in the host firmware. This can be a huge dump stored in the
+    host memory, the BMC doesnt store this dump but stream this dump to an
+    external client based on the offload request. Apart from system generated
+    system dump, users can also request for this kind of dump.
 
 properties:
     - name: SourceDumpId
       type: uint32
       description: >
-          The dump id provided by the source of the dump.
-          There are dumps which get generated outside the BMC, like a
-          system dump which gets generated and stored in the host memory.
-          All dumps will have a  unique id  but when communicating
-          to the source of the dump the SourceDumpId will be used.
+          The dump id provided by the source of the dump. There are dumps which
+          get generated outside the BMC, like a system dump which gets generated
+          and stored in the host memory. All dumps will have a  unique id  but
+          when communicating to the source of the dump the SourceDumpId will be
+          used.
diff --git a/yaml/xyz/openbmc_project/Dump/NewDump.interface.yaml b/yaml/xyz/openbmc_project/Dump/NewDump.interface.yaml
index 330f1c2..ed603fb 100644
--- a/yaml/xyz/openbmc_project/Dump/NewDump.interface.yaml
+++ b/yaml/xyz/openbmc_project/Dump/NewDump.interface.yaml
@@ -1,9 +1,9 @@
 description: >
-    Implement to notify the creation of new dump.
-    Use this interface when the dump is already created and ready
-    to be offloaded. This interface will add a new dump object with the
-    properties provided. The existing internal create interface should
-    be used when the data is collected and the dump needs to be packaged.
+    Implement to notify the creation of new dump. Use this interface when the
+    dump is already created and ready to be offloaded. This interface will add a
+    new dump object with the properties provided. The existing internal create
+    interface should be used when the data is collected and the dump needs to be
+    packaged.
 
     Any OpenBMC implementation must provide exactly one implementation of
     xyz.openbmc_project.Dump.NewDump on /xyz/openbmc_project/dump.
@@ -16,11 +16,11 @@
           - name: SourceDumpId
             type: uint32
             description: >
-                The dump id provided by the source of the dump.
-                There are dumps which get generated outside the BMC, like a
-                system dump which gets generated and stored in the host memory.
-                All dumps will have a  unique id  but when communicating
-                to the source of the dump the SourceDumpId will be used.
+                The dump id provided by the source of the dump. There are dumps
+                which get generated outside the BMC, like a system dump which
+                gets generated and stored in the host memory. All dumps will
+                have a  unique id  but when communicating to the source of the
+                dump the SourceDumpId will be used.
           - name: Size
             type: uint64
             description: >
diff --git a/yaml/xyz/openbmc_project/HardwareIsolation/Create.interface.yaml b/yaml/xyz/openbmc_project/HardwareIsolation/Create.interface.yaml
index 0262660..ca14aeb 100644
--- a/yaml/xyz/openbmc_project/HardwareIsolation/Create.interface.yaml
+++ b/yaml/xyz/openbmc_project/HardwareIsolation/Create.interface.yaml
@@ -1,15 +1,15 @@
 description: >
-    This interface contains create method, which can be implemented to
-    create an xyz.openbmc_project.HardwareIsolation.Entry object
-    which will use to provide the information of isolated hardware.
+    This interface contains create method, which can be implemented to create an
+    xyz.openbmc_project.HardwareIsolation.Entry object which will use to provide
+    the information of isolated hardware.
 
 methods:
     - name: Create
       description: >
-          Create an xyz.openbmc_project.HardwareIsolation.Entry object
-          if any of the hardware, needs to be isolated. This interface
-          can be used if want to isolate hardware without an error log,
-          for example, the user voluntarily tried to isolate hardware.
+          Create an xyz.openbmc_project.HardwareIsolation.Entry object if any of
+          the hardware, needs to be isolated. This interface can be used if want
+          to isolate hardware without an error log, for example, the user
+          voluntarily tried to isolate hardware.
       parameters:
           - name: IsolateHardware
             type: object_path
@@ -34,13 +34,12 @@
 
     - name: CreateWithErrorLog
       description: >
-          Create an xyz.openbmc_project.HardwareIsolation.Entry object
-          if any of the hardware, needs to be isolated. This interface
-          can be used if the system wants to isolate hardware with
-          an error log that is caused to isolate hardware.
-          This method is not going to create an error log and the consumer
-          of this method need to pass the bmc error log which caused
-          the isolation.
+          Create an xyz.openbmc_project.HardwareIsolation.Entry object if any of
+          the hardware, needs to be isolated. This interface can be used if the
+          system wants to isolate hardware with an error log that is caused to
+          isolate hardware. This method is not going to create an error log and
+          the consumer of this method need to pass the bmc error log which
+          caused the isolation.
       parameters:
           - name: IsolateHardware
             type: object_path
diff --git a/yaml/xyz/openbmc_project/HardwareIsolation/Entry.interface.yaml b/yaml/xyz/openbmc_project/HardwareIsolation/Entry.interface.yaml
index bc49434..a435307 100644
--- a/yaml/xyz/openbmc_project/HardwareIsolation/Entry.interface.yaml
+++ b/yaml/xyz/openbmc_project/HardwareIsolation/Entry.interface.yaml
@@ -2,21 +2,19 @@
     Implement to provide the isolated hardware entry attributes.
 
     The object which implements this interface must implement
-    xyz.openbmc_project.Association.Definitions to point associated
-    object, for example, isolated hardware inventory path and error
-    log if it caused to isolate hardware. The isolated hardware
-    association of forward and reverse name must be following
-    respectively "isolated_hw" and "isolated_hw_entry". The error
-    log association of forward and reverse types must be following
+    xyz.openbmc_project.Association.Definitions to point associated object, for
+    example, isolated hardware inventory path and error log if it caused to
+    isolate hardware. The isolated hardware association of forward and reverse
+    name must be following respectively "isolated_hw" and "isolated_hw_entry".
+    The error log association of forward and reverse types must be following
     respectively "isolated_hw_errorlog" and "isolated_hw_entry".
 
     The object which implements this interface should implement
-    xyz.openbmc_project.Object.Delete to allow the deletion of
-    individual isolated hardware object.
+    xyz.openbmc_project.Object.Delete to allow the deletion of individual
+    isolated hardware object.
 
     The object which implements this interface must implement
-    xyz.openbmc_project.Time.EpochTime for the isolated hardware
-    creation time.
+    xyz.openbmc_project.Time.EpochTime for the isolated hardware creation time.
 
 properties:
     - name: Severity
@@ -27,11 +25,11 @@
       type: boolean
       default: false
       description: >
-          The isolated hardware resolution status is used to indicate
-          whether the isolated hardware is repaired or replaced.
-          Setting this to "true" may not delete this entry object because
-          in a few system platforms isolated hardware entries may not be
-          deleted and used for further analysis.
+          The isolated hardware resolution status is used to indicate whether
+          the isolated hardware is repaired or replaced. Setting this to "true"
+          may not delete this entry object because in a few system platforms
+          isolated hardware entries may not be deleted and used for further
+          analysis.
 
 enumerations:
     - name: Type
@@ -43,10 +41,9 @@
                 Critical hardware to repair or replace.
           - name: Warning
             description: >
-                The system can boot without the isolated hardware but,
-                will lose the system configuration benefits of isolated
-                hardware.
+                The system can boot without the isolated hardware but, will lose
+                the system configuration benefits of isolated hardware.
           - name: Manual
             description: >
-                A user attempted to isolate hardware to proceed with
-                the host to boot.
+                A user attempted to isolate hardware to proceed with the host to
+                boot.
diff --git a/yaml/xyz/openbmc_project/Inventory/Connector/Slot.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Connector/Slot.interface.yaml
index e3c6855..c19d4ae 100644
--- a/yaml/xyz/openbmc_project/Inventory/Connector/Slot.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Connector/Slot.interface.yaml
@@ -1,4 +1,4 @@
 description: >
-    Implement to provide slot connector attributes. An slot component is
-    a swappable component that can be removed by a user and considered
+    Implement to provide slot connector attributes. An slot component is a
+    swappable component that can be removed by a user and considered
     field-replaceable. The slot compoment represents a PCIe slot connections.
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/Asset.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/Asset.interface.yaml
index 5db5c00..ac8a440 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/Asset.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/Asset.interface.yaml
@@ -16,10 +16,9 @@
     - name: BuildDate
       type: string
       description: >
-          The date of item manufacture in ISO 8601 format, either as
-          YYYYMMDD or YYYYMMDDThhmmssZ.  Where 'T' is a literal character
-          to separate date fields from time and 'Z' is a literal character
-          to indicate UTC.
+          The date of item manufacture in ISO 8601 format, either as YYYYMMDD or
+          YYYYMMDDThhmmssZ.  Where 'T' is a literal character to separate date
+          fields from time and 'Z' is a literal character to indicate UTC.
     - name: Model
       type: string
       description: >
@@ -32,9 +31,8 @@
     - name: SparePartNumber
       type: string
       description: >
-          An alternative PartNumber used for field replacement of the
-          Asset.
-          A default value (empty string) indicates that the Asset has
-          no specific SparePartNumber and instead PartNumber should
-          be used in user interfaces.
+          An alternative PartNumber used for field replacement of the Asset. A
+          default value (empty string) indicates that the Asset has no specific
+          SparePartNumber and instead PartNumber should be used in user
+          interfaces.
       default: ""
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/Cacheable.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/Cacheable.interface.yaml
index 36019dc..88938ed 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/Cacheable.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/Cacheable.interface.yaml
@@ -4,5 +4,5 @@
     - name: Cached
       type: boolean
       description: >
-          Whether or not the item is cached.  When true, the item
-          and its remaining attributes are undefined.
+          Whether or not the item is cached.  When true, the item and its
+          remaining attributes are undefined.
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/Compatible.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/Compatible.interface.yaml
index 1f86b3a..1743b87 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/Compatible.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/Compatible.interface.yaml
@@ -3,9 +3,9 @@
     (xyz.openbmc_project.Inventory.Decorator.Asset) for their components that
     don't require different software configurations.
 
-    xyz.openbmc_project.Inventory.Decorator.Compatible can be implemented to
-    add an additional, more generalized dimension of classification to
-    inventory components.
+    xyz.openbmc_project.Inventory.Decorator.Compatible can be implemented to add
+    an additional, more generalized dimension of classification to inventory
+    components.
 properties:
     - name: Names
       type: array[string]
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/CoolingType.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/CoolingType.interface.yaml
index 759cbda..9139c20 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/CoolingType.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/CoolingType.interface.yaml
@@ -1,5 +1,6 @@
 description: >
-    Implement properties to indicate the element cooling type (air, water, etc.).
+    Implement properties to indicate the element cooling type (air, water,
+    etc.).
 properties:
     - name: AirCooled
       type: boolean
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/LocationCode.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/LocationCode.interface.yaml
index 3ca7145..81de698 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/LocationCode.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/LocationCode.interface.yaml
@@ -3,9 +3,9 @@
 properties:
     - name: LocationCode
       type: string
-      description: A free form, implementation defined string to provide
-          location code of an Inventory Item.
-          Location codes can be used to identify specific parts
-          in a system. Although this field should not be used for
+      description:
+          A free form, implementation defined string to provide location code of
+          an Inventory Item. Location codes can be used to identify specific
+          parts in a system. Although this field should not be used for
           programmatic interrogation of an inventory object.
       default: ""
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/ManufacturerExt.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/ManufacturerExt.interface.yaml
index d2b6831..d0a8449 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/ManufacturerExt.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/ManufacturerExt.interface.yaml
@@ -5,11 +5,11 @@
     - name: ExtendedMFGData
       type: dict[string, string]
       description: >
-          A dictionary of manufacturer-specific extended data fields, which
-          may contain fields such as manufacturing plant, lot number, etc.
+          A dictionary of manufacturer-specific extended data fields, which may
+          contain fields such as manufacturing plant, lot number, etc.
 
-          These fields must not be used for programmatic interrogation of
-          an inventory object but may be useful for various human-oriented
-          tasks, such as part failure analysis.  Any field needed for
-          programmatic interrogation should be promoted to a first-class
-          property in another Item or Decorator interface.
+          These fields must not be used for programmatic interrogation of an
+          inventory object but may be useful for various human-oriented tasks,
+          such as part failure analysis.  Any field needed for programmatic
+          interrogation should be promoted to a first-class property in another
+          Item or Decorator interface.
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/MeetsMinimumShipLevel.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/MeetsMinimumShipLevel.interface.yaml
index bc7b7f1..2869c30 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/MeetsMinimumShipLevel.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/MeetsMinimumShipLevel.interface.yaml
@@ -1,11 +1,11 @@
 description: >
     'Applications may implement the MeetsMinimumShipLevel (MSL) decorator on an
-    object in the inventory namespace to denote that the item does or does
-    not meet an implementation defined minimum level for shipment requirement.
+    object in the inventory namespace to denote that the item does or does not
+    meet an implementation defined minimum level for shipment requirement.
 
     There are no requirements on how implementations react to inventory items
-    that do or do not meet the MSL.  Typical reactions might be to prevent
-    a system from powering on or logging events.'
+    that do or do not meet the MSL.  Typical reactions might be to prevent a
+    system from powering on or logging events.'
 
 properties:
     - name: MeetsMinimumShipLevel
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/UniqueIdentifier.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/UniqueIdentifier.interface.yaml
index fbfc423..adc0e70 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/UniqueIdentifier.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/UniqueIdentifier.interface.yaml
@@ -5,6 +5,6 @@
       type: string
       description: >
           A free form, implementation defined string which uniquely and
-          permanently identifies a specific inventory item. This is complementary
-          to the item's serial number. This field should not be used for
-          programmatic interrogation of an object.
+          permanently identifies a specific inventory item. This is
+          complementary to the item's serial number. This field should not be
+          used for programmatic interrogation of an object.
diff --git a/yaml/xyz/openbmc_project/Inventory/Decorator/VendorInformation.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Decorator/VendorInformation.interface.yaml
index 6d4eadc..1d9535b 100644
--- a/yaml/xyz/openbmc_project/Inventory/Decorator/VendorInformation.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Decorator/VendorInformation.interface.yaml
@@ -1,6 +1,5 @@
 description: >
-    Implement to provide custom properties added to an item by the
-    item vendor.
+    Implement to provide custom properties added to an item by the item vendor.
 properties:
     - name: CustomField1
       type: string
diff --git a/yaml/xyz/openbmc_project/Inventory/Item.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item.interface.yaml
index 44f8d8c..4ef840b 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Implement to provide basic item attributes.  Required by all objects
-    within the inventory namespace.
+    Implement to provide basic item attributes.  Required by all objects within
+    the inventory namespace.
 
     Any service implementing Inventory.Item on one or more objects must
     implement org.freedesktop.DBus.ObjectManager on
@@ -20,8 +20,8 @@
     - name: containing
       description: >
           Any inventory Items (usually Boards or Chassis) can optionally
-          implement the 'containing' association to provide one or more links
-          to Items which it physically contains.
+          implement the 'containing' association to provide one or more links to
+          Items which it physically contains.
       reverse_name: contained_by
       required_endpoint_interfaces:
           - xyz.openbmc_project.Inventory.Item
@@ -35,40 +35,39 @@
           - xyz.openbmc_project.Inventory.Item
     - name: sensors
       description: >
-          Sensors may implement an 'inventory' to 'sensors' association with
-          the inventory item related to it.
+          Sensors may implement an 'inventory' to 'sensors' association with the
+          inventory item related to it.
       reverse_names:
           - inventory
       required_endpoint_interfaces:
           - xyz.openbmc_project.Sensor.Value
     - name: cooled_by
       description: >
-          Objects that implement Item can optionally implement the
-          'cooled_by' association to provide a link to one or more fans.
+          Objects that implement Item can optionally implement the 'cooled_by'
+          association to provide a link to one or more fans.
       reverse_name: cooling
       required_endpoint_interfaces:
           - xyz.openbmc_project.Inventory.Item.Fan
     - name: identified_by
       description: >
           Objects that implement Item can optionally implement the
-          'identified_by' association to provide a link to one or more
-          LED Groups.
+          'identified_by' association to provide a link to one or more LED
+          Groups.
       reverse_name: identifying
       required_endpoint_interfaces:
           - xyz.openbmc_project.Led.Group
     - name: fault_identified_by
       description: >
           Objects that implement Item can optionally implement the
-          'fault_identified_by' association to provide a link to one or more
-          LED Groups.
+          'fault_identified_by' association to provide a link to one or more LED
+          Groups.
       reverse_name: fault_identifying
       required_endpoint_interfaces:
           - xyz.openbmc_project.Led.Group
     - name: powered_by
       description: >
-          Objects that implement Item can optionally implement the
-          'powered_by' association to provide a link to one or more
-          power supplies.
+          Objects that implement Item can optionally implement the 'powered_by'
+          association to provide a link to one or more power supplies.
       reverse_name: powering
       required_endpoint_interfaces:
           - xyz.openbmc_project.Inventory.Item.PowerSupply
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Accelerator.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Accelerator.interface.yaml
index b6ed9d5..e88b9c6 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Accelerator.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Accelerator.interface.yaml
@@ -1,8 +1,8 @@
 description: >
-    Implement to provide hardware accelerator attributes. A hardware
-    accelerator used to perform some functions more efficiently than is
-    possible in software running on a general-purpose CPU. Examples of
-    possible hardware accelerators include: GPUs, FPGAs, and ASICs.
+    Implement to provide hardware accelerator attributes. A hardware accelerator
+    used to perform some functions more efficiently than is possible in software
+    running on a general-purpose CPU. Examples of possible hardware accelerators
+    include: GPUs, FPGAs, and ASICs.
 
 properties:
     - name: Type
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Bmc.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Bmc.interface.yaml
index 0472bab..5ca97bf 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Bmc.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Bmc.interface.yaml
@@ -1,15 +1,13 @@
 description: >
-    Implement to provide BMC attributes. Example attributes are
-    the resource utilization of the BMC itself (BMC's CPU and memory,
-    etc).
+    Implement to provide BMC attributes. Example attributes are the resource
+    utilization of the BMC itself (BMC's CPU and memory, etc).
 
 associations:
     - name: monitored_by
       description: >
-          Objects that implement Bmc can implement the
-          'monitored_by' association to link to utilization sensors
-          for indicating the utilization sensors are for the BMC and
-          not the host.
+          Objects that implement Bmc can implement the 'monitored_by'
+          association to link to utilization sensors for indicating the
+          utilization sensors are for the BMC and not the host.
       reverse_names: monitoring
       required_endpoint_interfaces:
-        - xyz.openbmc_project.Sensor.Value
+          - xyz.openbmc_project.Sensor.Value
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Cable.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Cable.interface.yaml
index d2f32a2..74d7a56 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Cable.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Cable.interface.yaml
@@ -12,8 +12,8 @@
       type: string
       default: ""
       description: >
-          A free form, implementation defined string used to provide the type
-          of a cable, such as optical or copper.  The cable type can be shown
-          in user interfaces but this field should not be used for programmatic
+          A free form, implementation defined string used to provide the type of
+          a cable, such as optical or copper.  The cable type can be shown in
+          user interfaces but this field should not be used for programmatic
           interrogation of a cable beyond ignoring the default value of the
           empty string.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Chassis.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Chassis.interface.yaml
index 597ec4b..f82639c 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Chassis.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Chassis.interface.yaml
@@ -41,5 +41,16 @@
                 An unknown chassis type.
           - name: Zone
             description: >
-                A logical division or portion of a physical chassis that contains
-                multiple devices or systems that cannot be physically separated.
+                A logical division or portion of a physical chassis that
+                contains multiple devices or systems that cannot be physically
+                separated.
+
+associations:
+    - name: powered_by
+      description: >
+          Objects that implement Chassis can optionally implement the
+          'powered_by' association to provide a link to one or more power
+          supplies.
+      reverse_name: powering
+      required_endpoint_interfaces:
+          - xyz.openbmc_project.Inventory.Item.PowerSupply
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Connector.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Connector.interface.yaml
index f6aeed4..f95d850 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Connector.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Connector.interface.yaml
@@ -1,4 +1,3 @@
 description: >
-    Implement to provide connector attributes. A connector is
-    typically an external port or a slot into which cables are
-    plugged.
+    Implement to provide connector attributes. A connector is typically an
+    external port or a slot into which cables are plugged.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Cpu.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Cpu.interface.yaml
index 74f5671..7b81528 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Cpu.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Cpu.interface.yaml
@@ -9,31 +9,29 @@
     - name: Family
       type: string
       description: >
-          A free form string indicates processor family type.
-          For example, values can be "Intel Xeon
-          processor", "AS400 Family", etc.
+          A free form string indicates processor family type. For example,
+          values can be "Intel Xeon processor", "AS400 Family", etc.
       default: ""
     - name: EffectiveFamily
       type: uint16
       description: >
-          The effective Family information as provided by the
-          manufacturer of this processor in unsigned integer.
-          Default set to 0x02 which is defined as "Unknown" Processor
-          Family in DSP0134 section 7.5.2.
+          The effective Family information as provided by the manufacturer of
+          this processor in unsigned integer. Default set to 0x02 which is
+          defined as "Unknown" Processor Family in DSP0134 section 7.5.2.
       default: 0x02
     - name: EffectiveModel
       type: uint16
       description: >
-          The effective Model information as provided by the
-          manufacturer of this processor in unsigned integer.
+          The effective Model information as provided by the manufacturer of
+          this processor in unsigned integer.
       default: 0
     - name: Id
       type: uint64
       description: >
-          This Processor ID field contains processor-specific information
-          that describes the processor's features. Details depend on
-          processor architecture.
-          For x86 and ARM processors, DMTF DSP0134 Section 7.5.3 is used.
+          This Processor ID field contains processor-specific information that
+          describes the processor's features. Details depend on processor
+          architecture. For x86 and ARM processors, DMTF DSP0134 Section 7.5.3
+          is used.
       default: 0
     - name: MaxSpeedInMhz
       type: uint32
@@ -42,9 +40,9 @@
     - name: Characteristics
       type: array[enum[self.Capability]]
       description: >
-          The set of boolean flags for processor's capability, such as
-          64-bit Capable, Multi-Core, Hardware Thread, Execute Protection,
-          Enhanced Virtualization, Power/Performance Control etc.
+          The set of boolean flags for processor's capability, such as 64-bit
+          Capable, Multi-Core, Hardware Thread, Execute Protection, Enhanced
+          Virtualization, Power/Performance Control etc.
     - name: CoreCount
       type: uint16
       description: >
@@ -67,8 +65,8 @@
 enumerations:
     - name: Capability
       description: >
-          List of capabilities that a processor can support.
-          Values are based off DMTF DSP0134 specification.
+          List of capabilities that a processor can support. Values are based
+          off DMTF DSP0134 specification.
       values:
           - name: Capable64bit
             description: >
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Cpu/OperatingConfig.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Cpu/OperatingConfig.interface.yaml
index 2460505..cc30d90 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Cpu/OperatingConfig.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Cpu/OperatingConfig.interface.yaml
@@ -24,7 +24,8 @@
     - name: MaxSpeed
       type: uint32
       description: >
-          The maximum clock speed to which the processor can be configured in MHz.
+          The maximum clock speed to which the processor can be configured in
+          MHz.
       flags:
           - readonly
     - name: PowerLimit
@@ -43,7 +44,8 @@
       type: array[struct[uint32, size]]
       description: >
           An array of objects that specify the turbo profile for a set of active
-          cores. Each entry contains two members, first is the maximum turbo clock
-          speed in MHz, and second is number of cores which can run at that speed.
+          cores. Each entry contains two members, first is the maximum turbo
+          clock speed in MHz, and second is number of cores which can run at
+          that speed.
       flags:
           - readonly
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Dimm.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Dimm.interface.yaml
index 0a18cfb..1c668b1 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Dimm.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Dimm.interface.yaml
@@ -43,8 +43,8 @@
       description: >
           CAS Latency (CL) values are supported. The CAS latency is the delay
           between the time at which the column address and the column address
-          strobe signal are presented to the memory module and the time at
-          which the corresponding data is made available by the memory module.
+          strobe signal are presented to the memory module and the time at which
+          the corresponding data is made available by the memory module.
     - name: RevisionCode
       type: uint16
       description: >
@@ -111,7 +111,8 @@
                 and volatile memory.
           - name: IntelOptane
             description: >
-                The memory module is an Intel Optane DC Persistent Memory Module.
+                The memory module is an Intel Optane DC Persistent Memory
+                Module.
     - name: DeviceType
       description: >
           This property shall contain the Memory Device Type as defined by
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Dimm/MemoryLocation.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Dimm/MemoryLocation.interface.yaml
index 6e9e48d..8c742f6 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Dimm/MemoryLocation.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Dimm/MemoryLocation.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Implement to provide Memory connection information to sockets
-    and memory controllers.
+    Implement to provide Memory connection information to sockets and memory
+    controllers.
 properties:
     - name: Socket
       type: byte
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/DiskBackplane.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/DiskBackplane.interface.yaml
index db0c666..3a1b109 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/DiskBackplane.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/DiskBackplane.interface.yaml
@@ -1,4 +1,3 @@
 description: >
-    Implement to provide disk backplane attributes. A disk
-    backplane is a card that typically houses storage disks
-    such as hard drives and SSDs.
+    Implement to provide disk backplane attributes. A disk backplane is a card
+    that typically houses storage disks such as hard drives and SSDs.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Drive.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Drive.interface.yaml
index 12fa508..56dca8d 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Drive.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Drive.interface.yaml
@@ -26,8 +26,8 @@
       default: Unknown
       type: enum[self.DriveLockState]
       description: >
-          Indicates if the data on the drive is accessible.
-          This does not correspond to write locked
+          Indicates if the data on the drive is accessible. This does not
+          correspond to write locked
     - name: PredictedMediaLifeLeftPercent
       default: maxint
       type: byte
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/FabricAdapter.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/FabricAdapter.interface.yaml
index b355c9c..315f6bb 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/FabricAdapter.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/FabricAdapter.interface.yaml
@@ -1,6 +1,4 @@
 description: >
-    Implement to provide fabric adapter attributes.
-    A physical fabric adapter capable of connecting
-    to an interconnect fabric. Examples include but
-    are not limited to Ethernet, NVMe over Fabrics,
-    etc.
+    Implement to provide fabric adapter attributes. A physical fabric adapter
+    capable of connecting to an interconnect fabric. Examples include but are
+    not limited to Ethernet, NVMe over Fabrics, etc.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Fan.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Fan.interface.yaml
index 2b6ba4b..bd5b6d7 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Fan.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Fan.interface.yaml
@@ -4,8 +4,8 @@
 associations:
     - name: cooling
       description: >
-          Objects that implement Fan can optionally implement the
-          'cooling' association to provide a link back to a Item.
+          Objects that implement Fan can optionally implement the 'cooling'
+          association to provide a link back to a Item.
       reverse_name: cooled_by
       required_endpoint_interfaces:
-          - xyz.openbmc_project.Inventory.Item
\ No newline at end of file
+          - xyz.openbmc_project.Inventory.Item
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/PCIeDevice.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/PCIeDevice.interface.yaml
index d0a2187..f2a7954 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/PCIeDevice.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/PCIeDevice.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    This defines a PCIe device to be exposed for system management.  It
-    includes the device properties and function properties for all 8
-    possible functions that are needed for the device identification.
+    This defines a PCIe device to be exposed for system management.  It includes
+    the device properties and function properties for all 8 possible functions
+    that are needed for the device identification.
 
 properties:
     - name: DeviceType
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/PCIeSlot.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/PCIeSlot.interface.yaml
index 224b2d6..7c42a75 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/PCIeSlot.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/PCIeSlot.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    This defines a PCIe slot to be exposed for system management.
-    It includes the slot properties.
+    This defines a PCIe slot to be exposed for system management. It includes
+    the slot properties.
 
 properties:
     - name: Generation
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Panel.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Panel.interface.yaml
index a1c2d57..2f84646 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Panel.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Panel.interface.yaml
@@ -1,5 +1,4 @@
 description: >
-    Implement to provide Panel FRU attributes. A panel
-    is typically found on the chassis of a system and can
-    be used to physically control the system and/or display
-    system status.
+    Implement to provide Panel FRU attributes. A panel is typically found on the
+    chassis of a system and can be used to physically control the system and/or
+    display system status.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory.interface.yaml
index 16c9d08..5f31c48 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory.interface.yaml
@@ -13,8 +13,8 @@
     - name: SubsystemVendorID
       type: uint16
       description: >
-          The manufacturer ID of the memory subsystem controller of this
-          memory module as defined by JEDEC in JEP-106.
+          The manufacturer ID of the memory subsystem controller of this memory
+          module as defined by JEDEC in JEP-106.
     - name: SubsystemDeviceID
       type: uint16
       description: >
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/PowerManagementPolicy.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/PowerManagementPolicy.interface.yaml
index 5d067ec..9b30844 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/PowerManagementPolicy.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/PowerManagementPolicy.interface.yaml
@@ -1,6 +1,5 @@
 description: >
-    Implement to provide the power management policy for the current
-    resource.
+    Implement to provide the power management policy for the current resource.
 properties:
     - name: PolicyEnabled
       type: boolean
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/SecurityCapabilities.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/SecurityCapabilities.interface.yaml
index 09a6856..727c5a0 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/SecurityCapabilities.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/PersistentMemory/SecurityCapabilities.interface.yaml
@@ -20,5 +20,5 @@
     - name: PassphraseLockLimit
       type: uint32
       description: >
-          The maximum number of incorrect passphrase attempts
-          allowed before memory is locked.
+          The maximum number of incorrect passphrase attempts allowed before
+          memory is locked.
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/README.md b/yaml/xyz/openbmc_project/Inventory/Item/README.md
index b81d553..086e285 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/README.md
+++ b/yaml/xyz/openbmc_project/Inventory/Item/README.md
@@ -6,19 +6,21 @@
 accessed, such as a board, a chassis and a drive. Some objects are embedded in
 other objects, such as a BMC embedded in a board, or a core in a CPU. The DBus
 interfaces in this directory describe the DBus representation of those physical
-objects. A graph consisting of Inventory objects as vertexes and Association
-as edges can be constructed that represents the relationship between different
+objects. A graph consisting of Inventory objects as vertexes and Association as
+edges can be constructed that represents the relationship between different
 parts (such as chassis, drive, sensors, etc) of the system.
 
-# Inventory Association
+## Inventory Association
 
-DBus objects with xyz.opebmc_project.Inventory.Item.${ItemType} interface might
-be associated with other inventory objects. Such association can be translated
-to Redfish schemas and then indicate the system topology.
+DBus objects with `xyz.opebmc_project.Inventory.Item.${ItemType}` interface
+might be associated with other inventory objects. Such association can be
+translated to Redfish schemas and then indicate the system topology.
 
 Document ObjectMapper association forward and reverse names as follows:
-* Item and Item: [containing, contained_by]
-* Sensor.Value and Bmc: [monitoring, monitored_by]
-* fan and item: [cooling, cooled_by]
-* led and item : [identifying, identified_by] [fault_identifying, fault_identified_by]
-* powerSupply and item : [powering, powered_by]
+
+- Item and Item: `{containing, contained_by}`
+- Sensor.Value and Bmc: `{monitoring, monitored_by}`
+- fan and item: `{cooling, cooled_by}`
+- led and item: `{identifying, identified_by}`
+  `{fault_identifying, fault_identified_by}`
+- powerSupply and item: `{powering, powered_by}`
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Rotor.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Rotor.interface.yaml
index c403032..d044832 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Rotor.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Rotor.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement to provide Rotor attributes.
-    This interface should be at the same object path as a Fan for single-rotor
-    fans or as a set of sub-path for multi-rotor fan design.
+    Implement to provide Rotor attributes. This interface should be at the same
+    object path as a Fan for single-rotor fans or as a set of sub-path for
+    multi-rotor fan design.
 
 properties:
     - name: NominalVoltage
diff --git a/yaml/xyz/openbmc_project/Inventory/Item/Vrm.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Item/Vrm.interface.yaml
index 749563b..4e3fca1 100644
--- a/yaml/xyz/openbmc_project/Inventory/Item/Vrm.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Item/Vrm.interface.yaml
@@ -1,3 +1,3 @@
 description: >
-    Implement to provide VRM FRU attributes. A VRM is
-    a volatge regulator module.
+    Implement to provide VRM FRU attributes. A VRM is a volatge regulator
+    module.
diff --git a/yaml/xyz/openbmc_project/Inventory/Manager.interface.yaml b/yaml/xyz/openbmc_project/Inventory/Manager.interface.yaml
index 5045507..84edaba 100644
--- a/yaml/xyz/openbmc_project/Inventory/Manager.interface.yaml
+++ b/yaml/xyz/openbmc_project/Inventory/Manager.interface.yaml
@@ -1,10 +1,10 @@
 description: >
     Implement to provide inventory management features.
 
-    An OpenBMC implementation providing inventory functions may provide zero
-    or one implementation on the inventory namespace root.  An implementing
-    service should additionally implement org.freedesktop.DBus.ObjectManager
-    on the inventory namespace root.
+    An OpenBMC implementation providing inventory functions may provide zero or
+    one implementation on the inventory namespace root.  An implementing service
+    should additionally implement org.freedesktop.DBus.ObjectManager on the
+    inventory namespace root.
 methods:
     - name: Notify
       description: >
diff --git a/yaml/xyz/openbmc_project/Ipmi/SESSION_README.md b/yaml/xyz/openbmc_project/Ipmi/SESSION_README.md
index 4ad60f2..a523e13 100644
--- a/yaml/xyz/openbmc_project/Ipmi/SESSION_README.md
+++ b/yaml/xyz/openbmc_project/Ipmi/SESSION_README.md
@@ -4,8 +4,8 @@
 
 IPMI RMCP+ sessions are created and maintained by phosphor-ipmi-net daemon,
 whereas we need to provide details about the same using phosphor-ipmi-host.
-Hence IPMI RMCP+ session details has to be exposed through D-Bus interface,
-so that both phosphor-ipmi-host & phosphr-ipmi-net will be in sync.
+Hence IPMI RMCP+ session details has to be exposed through D-Bus interface, so
+that both phosphor-ipmi-host & phosphr-ipmi-net will be in sync.
 
 ### xyz.openbmc_project.Ipmi.SessionInfo interface
 
diff --git a/yaml/xyz/openbmc_project/Ipmi/SOL.interface.yaml b/yaml/xyz/openbmc_project/Ipmi/SOL.interface.yaml
index 52dedbf..0ef087e 100644
--- a/yaml/xyz/openbmc_project/Ipmi/SOL.interface.yaml
+++ b/yaml/xyz/openbmc_project/Ipmi/SOL.interface.yaml
@@ -1,11 +1,10 @@
 description: >
     SOL properties use for Get/Set SOL config parameter command in host-ipmid
-    sending config to SOL process in net-ipmid.
-    Since some platforms need to access Get/Set SOL config parameter command
-    through KCS, and current SOL manager is implemented in net-ipmid and
-    cannot be accessed by host-ipmid, add a D-Bus interface for host-ipmid
-    command to transfer properties to net-ipmid.
-    This interface will be implemented in phosphor-settings.
+    sending config to SOL process in net-ipmid. Since some platforms need to
+    access Get/Set SOL config parameter command through KCS, and current SOL
+    manager is implemented in net-ipmid and cannot be accessed by host-ipmid,
+    add a D-Bus interface for host-ipmid command to transfer properties to
+    net-ipmid. This interface will be implemented in phosphor-settings.
 properties:
     - name: Progress
       type: byte
@@ -15,8 +14,8 @@
     - name: Enable
       type: boolean
       description: >
-          SOL Enable property, this controls whether the SOL payload type
-          can be activated.
+          SOL Enable property, this controls whether the SOL payload type can be
+          activated.
     - name: ForceEncryption
       type: boolean
       description: >
@@ -28,24 +27,23 @@
     - name: Privilege
       type: byte
       description: >
-          Sets the minimum operating privilege level that is required to
-          be able to activate SOL by Activate Payload command.
+          Sets the minimum operating privilege level that is required to be able
+          to activate SOL by Activate Payload command.
     - name: AccumulateIntervalMS
       type: byte
       description: >
-          Character Accumulate Interval in 5ms increments.
-          BMC will wait this time before transmitting a packet.
+          Character Accumulate Interval in 5ms increments. BMC will wait this
+          time before transmitting a packet.
     - name: Threshold
       type: byte
       description: >
           BMC will automatically send an SOL character data packet containing
-          this number of characters as soon as this number of characters
-          (or greater) has been accepted from the baseboard serial controller.
+          this number of characters as soon as this number of characters (or
+          greater) has been accepted from the baseboard serial controller.
     - name: RetryCount
       type: byte
       description: >
-          Packet will be dropped if no ACK/NACK received by time retries
-          expire.
+          Packet will be dropped if no ACK/NACK received by time retries expire.
     - name: RetryIntervalMS
       type: byte
       description: >
diff --git a/yaml/xyz/openbmc_project/Ipmi/SessionInfo.interface.yaml b/yaml/xyz/openbmc_project/Ipmi/SessionInfo.interface.yaml
index 6d8a899..027b9d6 100644
--- a/yaml/xyz/openbmc_project/Ipmi/SessionInfo.interface.yaml
+++ b/yaml/xyz/openbmc_project/Ipmi/SessionInfo.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Provides properties for IPMI RMCP+ session objects.
-    Provides RMCP+ session information as session objects
-    with sessionID_sessionHandle(unique identifier)as path suffix.
+    Provides properties for IPMI RMCP+ session objects. Provides RMCP+ session
+    information as session objects with sessionID_sessionHandle(unique
+    identifier)as path suffix.
 
 properties:
     - name: SessionHandle
diff --git a/yaml/xyz/openbmc_project/Led/Group.interface.yaml b/yaml/xyz/openbmc_project/Led/Group.interface.yaml
index daf4aa7..83a0728 100644
--- a/yaml/xyz/openbmc_project/Led/Group.interface.yaml
+++ b/yaml/xyz/openbmc_project/Led/Group.interface.yaml
@@ -4,8 +4,8 @@
     - name: Asserted
       type: boolean
       description: >
-          Whether or not the group is currently asserted.
-          To assert a group, set to True. To de-assert a group, set to False.
+          Whether or not the group is currently asserted. To assert a group, set
+          to True. To de-assert a group, set to False.
 
 associations:
     - name: identifying
diff --git a/yaml/xyz/openbmc_project/Led/README.md b/yaml/xyz/openbmc_project/Led/README.md
index b6d259a..7bc2df5 100644
--- a/yaml/xyz/openbmc_project/Led/README.md
+++ b/yaml/xyz/openbmc_project/Led/README.md
@@ -3,35 +3,34 @@
 ## Overview
 
 LEDs that are present in the system can be managed by:
-`BMC / Hardware controller / Operating system`. This document describes how
-to control the LEDs that are managed by BMC.
+`BMC / Hardware controller / Operating system`. This document describes how to
+control the LEDs that are managed by BMC.
 
 ## Understanding LED groups
 
-While it is entirely possible to act directly on a physical LED, it makes
-hard when more than one LED is to be acted on for a particular usecase.
+While it is entirely possible to act directly on a physical LED, it makes hard
+when more than one LED is to be acted on for a particular usecase.
 
 For example: Certain systems may have a requirement to **Blink** one particular
 LED upon reaching some state. However, some other systems may have a requirement
 to **Blink** set of LEDs in different frequencies. Few more systems may have a
-requirement to act on set of LEDs with different actions. Meaning, some LEDs
-to be solid [ON] while some LEDs to be Blinking etc.
+requirement to act on set of LEDs with different actions. Meaning, some LEDs to
+be solid [ON] while some LEDs to be Blinking etc.
 
-As described above, it is more of a system specific policy on what set
-of LEDs to be acted on in different usecases. Taking all that complexity into
-the code makes it impossible to extend across implementations and hence the need
-of a manager that works on the set of LEDs and policies and that is the Group.
+As described above, it is more of a system specific policy on what set of LEDs
+to be acted on in different usecases. Taking all that complexity into the code
+makes it impossible to extend across implementations and hence the need of a
+manager that works on the set of LEDs and policies and that is the Group.
 
-To make concept of Group more evident, here is another example:
-Consider a requirement of blinking system Enclosure LED indicating
-an internal problem:
+To make concept of Group more evident, here is another example: Consider a
+requirement of blinking system Enclosure LED indicating an internal problem:
 
 If the DIMM has some issues then the system admin needs a way of identifying
-that system before acting on it. In one case, the LED group may consist of
-DIMM LED + Enclosure Fault LED. However, if the DIMM is attached to a Raiser
-card, then the LED group may consist of DIMM LED + Raise card LED + Enclosure
-Fault LED. Defining this path will make it easier to locate the box and the
-exact part that needs servicing.
+that system before acting on it. In one case, the LED group may consist of DIMM
+LED + Enclosure Fault LED. However, if the DIMM is attached to a Raiser card,
+then the LED group may consist of DIMM LED + Raise card LED + Enclosure Fault
+LED. Defining this path will make it easier to locate the box and the exact part
+that needs servicing.
 
 Definition of LED groups could be static or generated from MRW and must be in
 YAML format. A group definition looks like this:
@@ -57,29 +56,30 @@
     DutyOn: 50
 ```
 
-This says that the group `bmc_booted` consists of 2 physical LEDs in it.
-When this group is acted on, led_1 will turn solid [ON], while led_2
-would be blinking at 50% duty cycle.
+This says that the group `bmc_booted` consists of 2 physical LEDs in it. When
+this group is acted on, led_1 will turn solid [ON], while led_2 would be
+blinking at 50% duty cycle.
 
 ## Dbus interfaces for LED groups
 
 Refer to the [specification][group_specification].
 
-[group_specification]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Group.interface.yaml
+[group_specification]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Group.interface.yaml
 
 There is only one property called **asserted** defined on groups and when set to
 boolean **true**, the actions listed for the LEDs in that group will get into
-effect as described above.
-When the property is set to **false**, the actions are un-done.
+effect as described above. When the property is set to **false**, the actions
+are un-done.
 
-- Henceforth, the term **asserted** would mean writing boolean **true**
-  onto `assert` property of the group. Term **de-assert** would mean
-  writing **false** to `assert` property.
+- Henceforth, the term **asserted** would mean writing boolean **true** onto
+  `assert` property of the group. Term **de-assert** would mean writing
+  **false** to `assert` property.
 
 ## Group Dbus information
 
-**Path: `/xyz/openbmc_project/led/groups/<name>`**
-**Interface: `xyz.openbmc_Project.Led.Group`**
+**Path: `/xyz/openbmc_project/led/groups/<name>`** **Interface:
+`xyz.openbmc_Project.Led.Group`**
 
 Using the yaml definition above, a user can just set the `asserted` property to
 boolean `true` on `/xyz/openbmc_project/led/groups/enclosure_identify` and that
@@ -105,23 +105,24 @@
 ## Understanding Physical LEDs
 
 It is always **recommended** that external users use **only** the LED groups.
-Describing the Physical LED here just for documenting it and strictly NOT to
-be used outside of the firmware code.
+Describing the Physical LED here just for documenting it and strictly NOT to be
+used outside of the firmware code.
 
 ## Dbus interfaces for physical LEDs
 
 Refer to the [specification][phys_specification].
 
-[phys_specification]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Physical.interface.yaml
+[phys_specification]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Led/Physical.interface.yaml
 
 ## Dbus information
 
-**Path: `/xyz/openbmc_project/led/physical/<name>`**
-**Interface: `xyz.openbmc_Project.Led.Physical`**
+**Path: `/xyz/openbmc_project/led/physical/<name>`** **Interface:
+`xyz.openbmc_Project.Led.Physical`**
 
-Using **/xyz/openbmc_project/led/groups/enclosure_identify** as example;
-setting the `asserted` property to `true` would result in these actions in
-`id_front` and `id_rear` physical LEDs.
+Using **/xyz/openbmc_project/led/groups/enclosure_identify** as example; setting
+the `asserted` property to `true` would result in these actions in `id_front`
+and `id_rear` physical LEDs.
 
 1. Property `DutyOn` is set to `50` in;
    `/xyz/openbmc/project/led/physical/id_front` and
diff --git a/yaml/xyz/openbmc_project/Logging/Create.interface.yaml b/yaml/xyz/openbmc_project/Logging/Create.interface.yaml
index 9798b76..0da55b5 100644
--- a/yaml/xyz/openbmc_project/Logging/Create.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/Create.interface.yaml
@@ -1,8 +1,7 @@
 description: >
-    This interface contains a Create method, which can be implemented
-    to allow creation of xyz.openbmc_project.Logging.Entry objects
-    directly over D-Bus, without needing the errors defined in
-    the *.Error/metadata.yaml files.
+    This interface contains a Create method, which can be implemented to allow
+    creation of xyz.openbmc_project.Logging.Entry objects directly over D-Bus,
+    without needing the errors defined in the *.Error/metadata.yaml files.
 
 methods:
     - name: Create
@@ -20,8 +19,7 @@
           - name: AdditionalData
             type: dict[string, string]
             description: >
-                The AdditionalData property of the event entry.
-                e.g.:
+                The AdditionalData property of the event entry. e.g.:
                   {
                     "key1": "value1",
                     "key2": "value2"
@@ -34,9 +32,9 @@
           Create an xyz.openbmc_project.Logging.Entry object and pass in an
           array of file descriptors for files that contain FFDC (first failure
           data capture) data which may be used by event log extensions that
-          support storing it with their event logs.  The other arguments are
-          the same as with Create().  The FFDC argument is ignored by the
-          base phosphor-logging event logs.
+          support storing it with their event logs.  The other arguments are the
+          same as with Create().  The FFDC argument is ignored by the base
+          phosphor-logging event logs.
 
           When the method call is complete the descriptors must be closed and
           the files can be deleted if desired.
@@ -52,8 +50,7 @@
           - name: AdditionalData
             type: dict[string, string]
             description: >
-                The AdditionalData property of the event entry.
-                e.g.:
+                The AdditionalData property of the event entry. e.g.:
                   {
                     "key1": "value1",
                     "key2": "value2"
@@ -63,20 +60,21 @@
           - name: FFDC
             type: array[struct[enum[self.FFDCFormat], byte, byte, unixfd]]
             description: >
-                File descriptors for any files containing FFDC, along with metadata
-                about the contents:
+                File descriptors for any files containing FFDC, along with
+                metadata about the contents:
 
                   FFDCFormat- The format type of the contained data.
                   subType - The format subtype, used for the 'Custom' type.
-                  version - The version of the data format, used for the 'Custom'
+                  version - The version of the data format, used for the
+                'Custom'
                             type.
                   unixfd - The file descriptor to the data file.
 
-                e.g.:
-                [
-                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.JSON", 0, 0, 5},
-                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.Custom", 1, 2, 6}
-                ]
+                e.g.: [
+                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.JSON", 0, 0,
+                5},
+                  {"xyz.openbmc_project.Logging.Create.FFDCFormat.Custom", 1, 2,
+                6} ]
 
 enumerations:
     - name: FFDCFormat
diff --git a/yaml/xyz/openbmc_project/Logging/Entry.interface.yaml b/yaml/xyz/openbmc_project/Logging/Entry.interface.yaml
index 8ba6617..739b6e6 100644
--- a/yaml/xyz/openbmc_project/Logging/Entry.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/Entry.interface.yaml
@@ -1,8 +1,8 @@
 description: >
-    Implement to provide event/error entry attributes.
-    This interface should be instantiated for the phosphor::logging namespace.
-    This interface is a collection of objects, therefore it is required to
-    implement org.freedesktop.DBus.ObjectManager on the logging namespace root.
+    Implement to provide event/error entry attributes. This interface should be
+    instantiated for the phosphor::logging namespace. This interface is a
+    collection of objects, therefore it is required to implement
+    org.freedesktop.DBus.ObjectManager on the logging namespace root.
     Optionally, implement org.openbmc.Object.Delete to allow the deletion of
     individual entries.
 properties:
@@ -58,10 +58,10 @@
       type: uint64
       description: >
           The timestamp when any property was last modified, in milliseconds
-          since the epoch (1 Jan 1970 00:00:00 UTC).  As only the
-          Resolved property has a reason to change, a value that doesn't
-          match the Timestamp property's value (which indicates when the
-          log was created) would indicate that Resolved was changed.
+          since the epoch (1 Jan 1970 00:00:00 UTC).  As only the Resolved
+          property has a reason to change, a value that doesn't match the
+          Timestamp property's value (which indicates when the log was created)
+          would indicate that Resolved was changed.
 
 enumerations:
     - name: Level
@@ -110,8 +110,8 @@
 methods:
     - name: GetEntry
       description: >
-          Returns the file descriptor to the raw Entry file, which is a binary blob.
-          The mode of the file descriptor is to be reaad-only.
+          Returns the file descriptor to the raw Entry file, which is a binary
+          blob. The mode of the file descriptor is to be reaad-only.
       returns:
           - name: fd
             type: unixfd
diff --git a/yaml/xyz/openbmc_project/Logging/ErrorBlocksTransition.interface.yaml b/yaml/xyz/openbmc_project/Logging/ErrorBlocksTransition.interface.yaml
index 656c75a..fdac519 100644
--- a/yaml/xyz/openbmc_project/Logging/ErrorBlocksTransition.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/ErrorBlocksTransition.interface.yaml
@@ -4,10 +4,9 @@
     `Logging.Entry` is not `Resolved` or been deleted.
 
     The specific state transition(s) to prevent are left to the implementation.
-    A typical use of this would be to prevent the power-on of a
-    managed host while a critical error is open.  The managed host, via
-    systemd transitions, might start the power-on sequence and then wait for
-    any object with this `ErrorBlocksTransition` interface to no longer be
-    instantiated.  Causal ordering of D-Bus operations can prove that
-    no critical error needs servicing and the power-on sequence may safely
-    continue.
+    A typical use of this would be to prevent the power-on of a managed host
+    while a critical error is open.  The managed host, via systemd transitions,
+    might start the power-on sequence and then wait for any object with this
+    `ErrorBlocksTransition` interface to no longer be instantiated.  Causal
+    ordering of D-Bus operations can prove that no critical error needs
+    servicing and the power-on sequence may safely continue.
diff --git a/yaml/xyz/openbmc_project/Logging/Event.interface.yaml b/yaml/xyz/openbmc_project/Logging/Event.interface.yaml
index c083fc9..0c79c36 100755
--- a/yaml/xyz/openbmc_project/Logging/Event.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/Event.interface.yaml
@@ -4,17 +4,15 @@
 #     for logging should go in (Logging/Entry).
 #     https://github.com/openbmc/openbmc/issues/2923
 description: >
-    Implement to provide event entry attributes.
-    This interface should be instantiated for the phosphor::events namespace.
-    This interface is a collection of objects, therefore it is required to
-    implement org.freedesktop.DBus.ObjectManager on the events namespace root.
-    Optionally, implement xyz.openbmc_project.Delete to allow the deletion of
-    individual entries.
-    The event D-Bus object path would look like
-    <PhosphorDbusRoot>/events/<type>/<id>
-    Here "type" is the type of event, Could be network/system state event etc.
-    Type would be given by the application configuration file which would
-    be implementing this interface.
+    Implement to provide event entry attributes. This interface should be
+    instantiated for the phosphor::events namespace. This interface is a
+    collection of objects, therefore it is required to implement
+    org.freedesktop.DBus.ObjectManager on the events namespace root. Optionally,
+    implement xyz.openbmc_project.Delete to allow the deletion of individual
+    entries. The event D-Bus object path would look like
+    <PhosphorDbusRoot>/events/<type>/<id> Here "type" is the type of event,
+    Could be network/system state event etc. Type would be given by the
+    application configuration file which would be implementing this interface.
     Here "id" is positive integer starts from 1 and it gets incremented by 1
     with any newly created object.
 properties:
diff --git a/yaml/xyz/openbmc_project/Logging/IPMI.interface.yaml b/yaml/xyz/openbmc_project/Logging/IPMI.interface.yaml
index e7c4a08..911555c 100644
--- a/yaml/xyz/openbmc_project/Logging/IPMI.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/IPMI.interface.yaml
@@ -1,18 +1,17 @@
 description: >
-    Implement to provide an IPMI System Event Log (SEL) logging interface
-    under the path /xyz/openbmc_project/Logging/IPMI.
+    Implement to provide an IPMI System Event Log (SEL) logging interface under
+    the path /xyz/openbmc_project/Logging/IPMI.
 
-    SEL records store system event information and will contain a record ID
-    and type followed by type-specific information.  The type-specific
-    information includes a timestamp, generator ID (used to identify the
-    component that is adding the SEL record), sensor number, event
-    direction and event-specific data for system type events; or timestamp
-    and OEM data for OEM type events.
+    SEL records store system event information and will contain a record ID and
+    type followed by type-specific information.  The type-specific information
+    includes a timestamp, generator ID (used to identify the component that is
+    adding the SEL record), sensor number, event direction and event-specific
+    data for system type events; or timestamp and OEM data for OEM type events.
 
     The interface allows adding system or OEM type events.  For system type
-    events it requires a generator ID (0x20 for BMC), sensor D-Bus path,
-    event direction (assertion or de-assertion), and event specific data.
-    For OEM type events, it requires the record type and OEM data.
+    events it requires a generator ID (0x20 for BMC), sensor D-Bus path, event
+    direction (assertion or de-assertion), and event specific data. For OEM type
+    events, it requires the record type and OEM data.
 
     It will assign a record ID and timestamp automatically and return the
     assigned record ID.
diff --git a/yaml/xyz/openbmc_project/Logging/README.md b/yaml/xyz/openbmc_project/Logging/README.md
index ecee30b..9f9c07f 100644
--- a/yaml/xyz/openbmc_project/Logging/README.md
+++ b/yaml/xyz/openbmc_project/Logging/README.md
@@ -21,41 +21,46 @@
   application. Such errors are defined in the application that uses the error.
 - Refer to [openpower-debug-collector][openpower-debug-collector].
 
-[openpower-debug-collector]: https://github.com/openbmc/openpower-debug-collector
+[openpower-debug-collector]:
+  https://github.com/openbmc/openpower-debug-collector
 
 ### Error YAML files
 
 - Every error defined will have an error YAML file and a corresponding error
   metadata YAML file.
 - The error YAML file contains the error name and a one-line description of the
-  error.
-  An example of an error YAML file can be found [here][error-example].
-- The error metadata YAML file captures required data. The format of the data
-  is defined in the error metadata file. An example of an error metadata YAML
-  file can be found [here][metadata-example].
+  error. An example of an error YAML file can be found [here][error-example].
+- The error metadata YAML file captures required data. The format of the data is
+  defined in the error metadata file. An example of an error metadata YAML file
+  can be found [here][metadata-example].
 
-[error-example]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Common/File.errors.yaml
-[metadata-example]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Common/File.metadata.yaml
+[error-example]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Common/File.errors.yaml
+[metadata-example]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Common/File.metadata.yaml
 
 ## Logging to journal
 
-- Applications can log debug/error information to the journal using
-  the **log** API
+- Applications can log debug/error information to the journal using the **log**
+  API
   - Refer to [log.hpp][log-header].
 - Applications can commit errors to the journal using the **report** or
   **commit** API
   - Refer to [elog.hpp][elog-header].
   - Logging entry D-Bus objects are created for the committed errors.
 
-[log-header]: https://github.com/openbmc/phosphor-logging/blob/master/lib/include/phosphor-logging/log.hpp
-[elog-header]: https://github.com/openbmc/phosphor-logging/blob/master/lib/include/phosphor-logging/elog.hpp
+[log-header]:
+  https://github.com/openbmc/phosphor-logging/blob/master/lib/include/phosphor-logging/log.hpp
+[elog-header]:
+  https://github.com/openbmc/phosphor-logging/blob/master/lib/include/phosphor-logging/elog.hpp
 
 ## Delete All interface
 
 - Use the [DeleteAll.interface.yaml][deleteall] for deleting all the logging
   entries.
 
-[deleteall]: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Collection/DeleteAll.interface.yaml
+[deleteall]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Collection/DeleteAll.interface.yaml
 
 ## REST commands
 
diff --git a/yaml/xyz/openbmc_project/Logging/Settings.interface.yaml b/yaml/xyz/openbmc_project/Logging/Settings.interface.yaml
index fb9f7c3..e89412f 100644
--- a/yaml/xyz/openbmc_project/Logging/Settings.interface.yaml
+++ b/yaml/xyz/openbmc_project/Logging/Settings.interface.yaml
@@ -6,5 +6,5 @@
       type: boolean
       default: false
       description: >
-          If true, a hardware failure within the system will result in a
-          Quiesce of the BMC state. If false, no action is taken.
+          If true, a hardware failure within the system will result in a Quiesce
+          of the BMC state. If false, no action is taken.
diff --git a/yaml/xyz/openbmc_project/MCTP/Endpoint.interface.yaml b/yaml/xyz/openbmc_project/MCTP/Endpoint.interface.yaml
index 8cb0f13..0d99995 100644
--- a/yaml/xyz/openbmc_project/MCTP/Endpoint.interface.yaml
+++ b/yaml/xyz/openbmc_project/MCTP/Endpoint.interface.yaml
@@ -20,12 +20,11 @@
           The logical address used to route MCTP messages to a specific MCTP
           endpoint. A numeric handle (logical address) that uniquely identifies
           a particular MCTP endpoint within a system for MCTP communication and
-          message routing purposes. Endpoint IDs are unique among MCTP
-          endpoints that comprise an MCTP communication network within a
-          system. MCTP EIDs are only unique within a particular MCTP network.
-          That is, they can be duplicated or overlap from one MCTP network to
-          the next. This is also referred to as "endpoint ID" and abbreviated
-          as "EID".
+          message routing purposes. Endpoint IDs are unique among MCTP endpoints
+          that comprise an MCTP communication network within a system. MCTP EIDs
+          are only unique within a particular MCTP network. That is, they can be
+          duplicated or overlap from one MCTP network to the next. This is also
+          referred to as "endpoint ID" and abbreviated as "EID".
 
     - name: SupportedMessageTypes
       type: array[byte]
@@ -37,6 +36,6 @@
           Ethernet over MCTP(0x03), NVM Express Management Messages over
           MCTP(0x04) and SPDM over MCTP(0x05). There are ranges for vendor
           defined message types. All the message types are specified in the
-          DSP0239 specification. A device that supports a given message type
-          may not support that message type equally across all buses that
-          connect to the device.
+          DSP0239 specification. A device that supports a given message type may
+          not support that message type equally across all buses that connect to
+          the device.
diff --git a/yaml/xyz/openbmc_project/MCTP/README.md b/yaml/xyz/openbmc_project/MCTP/README.md
index 57a5044..0d3f5cf 100644
--- a/yaml/xyz/openbmc_project/MCTP/README.md
+++ b/yaml/xyz/openbmc_project/MCTP/README.md
@@ -1,9 +1,9 @@
 # Overview
 
-MCTP D-Bus interfaces are implemented by the MCTP control process daemon
-alias mcptd and aids in the discovery of MCTP enabled devices by application
-layer protocols (like PLDM, SPDM) which are implemented in the userspace.
-Application layer protocols will rely on the discovery of
+MCTP D-Bus interfaces are implemented by the MCTP control process daemon alias
+mcptd and aids in the discovery of MCTP enabled devices by application layer
+protocols (like PLDM, SPDM) which are implemented in the userspace. Application
+layer protocols will rely on the discovery of
 `xyz.openbmc_project.MCTP.Endpoint` D-Bus interface to discover MCTP endpoints.
 The supported MCTP message types in an endpoint are exposed by the
 `SupportedMessageTypes` property in the `xyz.openbmc_project.MCTP.Endpoint`
@@ -15,8 +15,8 @@
 ## D-Bus object modelling
 
 The root D-Bus object path for the mctpd is `/xyz/openbmc_project/mctp`. There
-will be a D-Bus object for every endpoint that is discovered by the mctpd.
-The lifetime of the D-Bus object is the lifetime of the connected MCTP device.
+will be a D-Bus object for every endpoint that is discovered by the mctpd. The
+lifetime of the D-Bus object is the lifetime of the connected MCTP device.
 
 The D-Bus object path for MCTP endpoints are named
 `xyz/openbmc_project/mctp/<NetworkId>/<EID>` where NetworkId is the locally
@@ -34,9 +34,9 @@
 to tell whether the access points provide access to the same MCTP Network or to
 different MCTP Networks. If the implementation supports the optional MCTP
 network ID then it is exposed on the D-Bus. The D-Bus object path is
-`xyz/openbmc_project/mctp/<NetworkId>` where NetworkId is the locally
-defined [network identfier][1] and implements the
-`xyz.openbmc_project.Common.UUID` interface and the UUID property is the MCTP
-network ID.
+`xyz/openbmc_project/mctp/<NetworkId>` where NetworkId is the locally defined
+[network identfier][1] and implements the `xyz.openbmc_project.Common.UUID`
+interface and the UUID property is the MCTP network ID.
 
-[1]: https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md#addressing
+[1]:
+  https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md#addressing
diff --git a/yaml/xyz/openbmc_project/Network/Client.interface.yaml b/yaml/xyz/openbmc_project/Network/Client.interface.yaml
index 188bcd9..9789e47 100644
--- a/yaml/xyz/openbmc_project/Network/Client.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/Client.interface.yaml
@@ -1,8 +1,7 @@
 description: >
-    This defines the network endpoint.
-    Application which wants to keep the network endpoint info
-    can use this interface.
-    e.g: Network endpoint could be SNMP mangers or LDAP servers etc.
+    This defines the network endpoint. Application which wants to keep the
+    network endpoint info can use this interface. e.g: Network endpoint could be
+    SNMP mangers or LDAP servers etc.
 properties:
     - name: Address
       type: string
diff --git a/yaml/xyz/openbmc_project/Network/DHCPConfiguration.interface.yaml b/yaml/xyz/openbmc_project/Network/DHCPConfiguration.interface.yaml
index 74b7939..44dab9c 100644
--- a/yaml/xyz/openbmc_project/Network/DHCPConfiguration.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/DHCPConfiguration.interface.yaml
@@ -4,25 +4,25 @@
     - name: DNSEnabled
       type: boolean
       description: >
-          if true then the DNS servers received from the DHCP server
-          will be used and take precedence over any statically configured ones.
+          if true then the DNS servers received from the DHCP server will be
+          used and take precedence over any statically configured ones.
     - name: NTPEnabled
       type: boolean
       description: >
-          if true then the NTP servers received from the DHCP server
-          will be used by systemd-timesyncd and take precedence over any
-          statically configured ones.
+          if true then the NTP servers received from the DHCP server will be
+          used by systemd-timesyncd and take precedence over any statically
+          configured ones.
     - name: HostNameEnabled
       type: boolean
       description: >
-          if true then the hostname received from the DHCP server
-          will be set as the transient hostname of the system.
+          if true then the hostname received from the DHCP server will be set as
+          the transient hostname of the system.
     - name: DomainEnabled
       type: boolean
       description: >
-          if true then the domain names received from the DHCP server
-          will be used by systemd-resolved and take precedence over any
-          statically configured ones.
+          if true then the domain names received from the DHCP server will be
+          used by systemd-resolved and take precedence over any statically
+          configured ones.
     - name: SendHostNameEnabled
       type: boolean
       description: >
diff --git a/yaml/xyz/openbmc_project/Network/EthernetInterface.interface.yaml b/yaml/xyz/openbmc_project/Network/EthernetInterface.interface.yaml
index f45cac7..f39fd13 100644
--- a/yaml/xyz/openbmc_project/Network/EthernetInterface.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/EthernetInterface.interface.yaml
@@ -1,7 +1,6 @@
 description: >
-    This defines an ethernet interface.
-    An object implementing this interface must implement
-    xyz.openbmc_project.State.OperationalStatus.
+    This defines an ethernet interface. An object implementing this interface
+    must implement xyz.openbmc_project.State.OperationalStatus.
 
 properties:
     - name: InterfaceName
@@ -27,8 +26,8 @@
       type: size
       default: 0
       description: >
-          This indicates the size in bytes of largest protocol data unit,
-          which can be passed in an Ethernet frame on the interface.
+          This indicates the size in bytes of largest protocol data unit, which
+          can be passed in an Ethernet frame on the interface.
     - name: DomainName
       type: array[string]
       description: >
@@ -36,8 +35,8 @@
     - name: DHCPEnabled
       type: enum[self.DHCPConf]
       description: >
-          Address mode of the ethernet interface. Deprecated in favor of
-          split options to avoid combinatorics.
+          Address mode of the ethernet interface. Deprecated in favor of split
+          options to avoid combinatorics.
     - name: DHCP4
       type: boolean
       description: >
@@ -56,8 +55,8 @@
       type: array[string]
       description: >
           A statically defined set of DNS server IP addresses to be used when
-          DHCP provisioning is not enabled for name server configuration. As
-          an implementation option this may also be used in addition to DHCP
+          DHCP provisioning is not enabled for name server configuration. As an
+          implementation option this may also be used in addition to DHCP
           provided addresses, or in cases where the DHCP server provides no DNS
           assigments.
       errors:
@@ -65,14 +64,14 @@
     - name: NTPServers
       type: array[string]
       description: >
-          NTP servers that are currently in use on this interface.
-          This includes both DHCP and static NTP server addresses.
+          NTP servers that are currently in use on this interface. This includes
+          both DHCP and static NTP server addresses.
     - name: StaticNTPServers
       type: array[string]
       description: >
           This property describes statically defined NTPServers on the
-          interface. This property supports read/write operation.
-          Configure the NTP servers on the system during write operation.
+          interface. This property supports read/write operation. Configure the
+          NTP servers on the system during write operation.
     - name: LinkLocalAutoConf
       type: enum[self.LinkLocalConf]
       description: >
@@ -92,8 +91,8 @@
           - readonly
       description: >
           This property reports the link status for the NIC. The read-only
-          boolean value is TRUE when the network cable is inserted, or there
-          is a carrier signal. It is FALSE when the cable is unplugged, or the
+          boolean value is TRUE when the network cable is inserted, or there is
+          a carrier signal. It is FALSE when the cable is unplugged, or the
           carrier signal is missing.
     - name: DefaultGateway
       type: string
@@ -104,9 +103,9 @@
     - name: DefaultGateway6
       type: string
       description: >
-          Default IPv6 gateway of the ethernet interface.
-          For supported address formats refer RFC 2373.
-          Refer below man page for both v4 and v6 address format details
+          Default IPv6 gateway of the ethernet interface. For supported address
+          formats refer RFC 2373. Refer below man page for both v4 and v6
+          address format details
           https://man7.org/linux/man-pages/man3/inet_pton.3.html
       errors:
           - xyz.openbmc_project.Common.Error.InvalidArgument
@@ -124,15 +123,12 @@
 
     - name: DHCPConf
       description: >
-          High level definitions of available DHCP states.
-          These definitions do not have a 1:1 correlation to the
-          systemd.network configuration file contents.
-          both: Enable IPv4 DHCP and IPv6 Stateful DHCP
-          v4v6stateless: Enable IPv4 DHCP and IPv6 SLAAC
-          v6: Enable IPv6 Stateful DHCP
-          v6stateless: Enable IPv6 SLAAC
-          v4: Enable IPv4 DHCP
-          none: Disable DHCP for IPv4 and IPv6
+          High level definitions of available DHCP states. These definitions do
+          not have a 1:1 correlation to the systemd.network configuration file
+          contents. both: Enable IPv4 DHCP and IPv6 Stateful DHCP v4v6stateless:
+          Enable IPv4 DHCP and IPv6 SLAAC v6: Enable IPv6 Stateful DHCP
+          v6stateless: Enable IPv6 SLAAC v4: Enable IPv4 DHCP none: Disable DHCP
+          for IPv4 and IPv6
       values:
           - name: both
           - name: v4v6stateless
diff --git a/yaml/xyz/openbmc_project/Network/Experimental/Bond.interface.yaml b/yaml/xyz/openbmc_project/Network/Experimental/Bond.interface.yaml
index f0b3472..98d05c0 100644
--- a/yaml/xyz/openbmc_project/Network/Experimental/Bond.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/Experimental/Bond.interface.yaml
@@ -33,15 +33,16 @@
           - name: RoundRobin
             description: >
                 It is the default mode,in this mode system transmits packets in
-                sequential order from the first available slave through the last.
+                sequential order from the first available slave through the
+                last.
           - name: ActiveBackup
             description: >
-                In this mode, only one slave in the bond is active.
-                The other one will become active, only when the active slave fails.
+                In this mode, only one slave in the bond is active. The other
+                one will become active, only when the active slave fails.
           - name: XOR
             description: >
-                Transmit based on selectable hashing algorithm.
-                The default policy is a simple source+destination MAC address algorithm.
+                Transmit based on selectable hashing algorithm. The default
+                policy is a simple source+destination MAC address algorithm.
           - name: Broadcast
             description: >
                 Transmits everything on all slave interfaces.
@@ -50,10 +51,12 @@
                 IEEE 802.3ad Dynamic link aggregation.
           - name: TLB
             description: >
-                The outgoing traffic is distributed according to the current load on each slave.
+                The outgoing traffic is distributed according to the current
+                load on each slave.
           - name: ALB
             description: >
-                Incoming/outgoing traffic is distributed according to the current load on each slave.
+                Incoming/outgoing traffic is distributed according to the
+                current load on each slave.
 
     - name: HashPolicy
       description: >
@@ -61,25 +64,25 @@
       values:
           - name: Layer2
             description: >
-                This policy uses XOR of hardware MAC addresses and packet type ID
-                field to generate the hash.
+                This policy uses XOR of hardware MAC addresses and packet type
+                ID field to generate the hash.
           - name: Layer2Plus3
             description: >
-                This policy uses a combination of layer2 and layer3
-                protocol information to generate the hash.
+                This policy uses a combination of layer2 and layer3 protocol
+                information to generate the hash.
           - name: Layer3Plus4
             description: >
-                This policy uses upper layer protocol information,
-                when available, to generate the hash.
+                This policy uses upper layer protocol information, when
+                available, to generate the hash.
           - name: Encap2Plus3
             description: >
-                This policy uses the same formula as layer2+3 but it
-                relies on skb_flow_dissect to obtain the header fields
-                which might result in the use of inner headers if an
-                encapsulation protocol is used.
+                This policy uses the same formula as layer2+3 but it relies on
+                skb_flow_dissect to obtain the header fields which might result
+                in the use of inner headers if an encapsulation protocol is
+                used.
           - name: Encap3Plus4
             description: >
-                This policy uses the same formula as layer3+4 but it
-                relies on skb_flow_dissect to obtain the header fields
-                which might result in the use of inner headers if an
-                encapsulation protocol is used.
+                This policy uses the same formula as layer3+4 but it relies on
+                skb_flow_dissect to obtain the header fields which might result
+                in the use of inner headers if an encapsulation protocol is
+                used.
diff --git a/yaml/xyz/openbmc_project/Network/Experimental/Tunnel.interface.yaml b/yaml/xyz/openbmc_project/Network/Experimental/Tunnel.interface.yaml
index fe2bdae..a61be19 100644
--- a/yaml/xyz/openbmc_project/Network/Experimental/Tunnel.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/Experimental/Tunnel.interface.yaml
@@ -32,26 +32,25 @@
     - name: IPv6FlowLabel
       type: uint32
       description: >
-          Configures the 20-bit flow label. It can be configured to a value
-          in the range 0–0xFFFFF, or be set to "inherit", in which case the
+          Configures the 20-bit flow label. It can be configured to a value in
+          the range 0–0xFFFFF, or be set to "inherit", in which case the
           original flowlabel is used.
     - name: CopyDSCP
       type: boolean
       description: >
-          When true, the Differentiated Service Code Point
-          (DSCP) field will be copied to the inner header from outer header
-          during the decapsulation of an IPv6 tunnel packet.
+          When true, the Differentiated Service Code Point (DSCP) field will be
+          copied to the inner header from outer header during the decapsulation
+          of an IPv6 tunnel packet.
     - name: EncapsulationLimit
       type: uint32
       description: >
-          The Tunnel Encapsulation Limit option specifies how many
-          additional levels of encapsulation are permitted to be prepended
-          to the packet.
+          The Tunnel Encapsulation Limit option specifies how many additional
+          levels of encapsulation are permitted to be prepended to the packet.
     - name: Key
       type: string
       description: >
-          This parameter specifies the same key to use in both
-          directions (InputKey= and OutputKey=).
+          This parameter specifies the same key to use in both directions
+          (InputKey= and OutputKey=).
     - name: InputKey
       type: string
       description: >
diff --git a/yaml/xyz/openbmc_project/Network/IP.interface.yaml b/yaml/xyz/openbmc_project/Network/IP.interface.yaml
index 8a64533..eae2359 100644
--- a/yaml/xyz/openbmc_project/Network/IP.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/IP.interface.yaml
@@ -8,8 +8,8 @@
     - name: Address
       type: string
       description: >
-          The value of this property shall be an IP address assigned to
-          the ethernet interface.
+          The value of this property shall be an IP address assigned to the
+          ethernet interface.
       errors:
           - xyz.openbmc_project.Common.Error.NotAllowed
 
diff --git a/yaml/xyz/openbmc_project/Network/MACAddress.interface.yaml b/yaml/xyz/openbmc_project/Network/MACAddress.interface.yaml
index 5ec8cd9..2df4676 100644
--- a/yaml/xyz/openbmc_project/Network/MACAddress.interface.yaml
+++ b/yaml/xyz/openbmc_project/Network/MACAddress.interface.yaml
@@ -5,9 +5,8 @@
     - name: MACAddress
       type: string
       description: >
-          MAC address of the ethernet interface in six groups of
-          two hexadecimal digits separated by colons.
-          Example: 01:23:45:67:89:AB
+          MAC address of the ethernet interface in six groups of two hexadecimal
+          digits separated by colons. Example: 01:23:45:67:89:AB
       errors:
           - xyz.openbmc_project.Common.Error.InvalidArgument
           - xyz.openbmc_project.Common.Error.InternalFailure
diff --git a/yaml/xyz/openbmc_project/Network/README.md b/yaml/xyz/openbmc_project/Network/README.md
index 555bc49..eea7abf 100644
--- a/yaml/xyz/openbmc_project/Network/README.md
+++ b/yaml/xyz/openbmc_project/Network/README.md
@@ -2,18 +2,17 @@
 
 ## Overview
 
-A Network Manager is a daemon which handles network management operations.
-It must implement the
-`xyz.openbmc_project.Network.SystemConfiguration.interface` and
-`org.freedesktop.DBus.ObjectManager`.
+A Network Manager is a daemon which handles network management operations. It
+must implement the `xyz.openbmc_project.Network.SystemConfiguration.interface`
+and `org.freedesktop.DBus.ObjectManager`.
 
-When the network manager daemon comes up, it should create objects
-implementing physical link/virtual interfaces such as
+When the network manager daemon comes up, it should create objects implementing
+physical link/virtual interfaces such as
 `xyz.openbmc_project.Network.EthernetInterface` or
 `xyz.openbmc_project.Network.VLANInterface` on the system.
 
-IP address(v4 and v6) objects must be children objects of the
-physical/virtual interface object.
+IP address(v4 and v6) objects must be children objects of the physical/virtual
+interface object.
 
 ## Interfaces
 
@@ -30,15 +29,15 @@
 
 Interface objects can be physical as well as virtual.
 
-If the object is a physical interface, it can't be deleted,
-but if it is a virtual interface object it can be deleted.
+If the object is a physical interface, it can't be deleted, but if it is a
+virtual interface object it can be deleted.
 
 E.g. `/xyz/openbmc_project/network/<interfacename>`
 
 ### IP Address Objects
 
-There can be multiple IP address objects under an interface object.
-These objects can be deleted by the delete function.
+There can be multiple IP address objects under an interface object. These
+objects can be deleted by the delete function.
 
 IPv4 objects will have the following D-Bus object path:
 
@@ -312,8 +311,8 @@
 ipmitool -I dbus raw 0x06 0x40 // To the save settings
 ```
 
-NOTE: It takes 4-5 seconds to create the VLAN and configure the IP.
-If a VLAN interface is not desired don't set the VLAN id above.
+NOTE: It takes 4-5 seconds to create the VLAN and configure the IP. If a VLAN
+interface is not desired don't set the VLAN id above.
 
 #### Delete
 
diff --git a/yaml/xyz/openbmc_project/Nvme/Status.errors.yaml b/yaml/xyz/openbmc_project/Nvme/Status.errors.yaml
index 2314f4f..5e613c2 100644
--- a/yaml/xyz/openbmc_project/Nvme/Status.errors.yaml
+++ b/yaml/xyz/openbmc_project/Nvme/Status.errors.yaml
@@ -2,12 +2,15 @@
   description: The available spare capacity has fallen below the threshold
 
 - name: TemperatureFault
-  description: A temperature is above an over temperature threshold or below an under temperature threshold
+  description:
+      A temperature is above an over temperature threshold or below an under
+      temperature threshold
 
 - name: DegradesFault
-  description: The NVM subsystem reliability has been
-      degraded due to significant media related errors or any
-      internal error that degrades NVM subsystem reliability.
+  description:
+      The NVM subsystem reliability has been degraded due to significant media
+      related errors or any internal error that degrades NVM subsystem
+      reliability.
 
 - name: MediaFault
   description: The media has been placed in read only mode.
diff --git a/yaml/xyz/openbmc_project/Nvme/Status.interface.yaml b/yaml/xyz/openbmc_project/Nvme/Status.interface.yaml
index e424e6b..0846e70 100644
--- a/yaml/xyz/openbmc_project/Nvme/Status.interface.yaml
+++ b/yaml/xyz/openbmc_project/Nvme/Status.interface.yaml
@@ -22,14 +22,15 @@
       type: boolean
       default: false
       description: >
-          Represent a temperature is above an over temperature threshold or below an under temperature
-          threshold
+          Represent a temperature is above an over temperature threshold or
+          below an under temperature threshold
     - name: DegradesFault
       type: boolean
       default: false
       description: >
           Represent  the NVM subsystem reliability has been degraded due to
-          significant media related errors or any internal error that degrades NVM subsystem reliability
+          significant media related errors or any internal error that degrades
+          NVM subsystem reliability
     - name: MediaFault
       type: boolean
       default: false
diff --git a/yaml/xyz/openbmc_project/ObjectMapper.interface.yaml b/yaml/xyz/openbmc_project/ObjectMapper.interface.yaml
index 45faf75..9cde19a 100644
--- a/yaml/xyz/openbmc_project/ObjectMapper.interface.yaml
+++ b/yaml/xyz/openbmc_project/ObjectMapper.interface.yaml
@@ -6,8 +6,8 @@
 methods:
     - name: GetObject
       description: >
-          Obtain a dictionary of service -> implemented interface(s)
-          for the given path.
+          Obtain a dictionary of service -> implemented interface(s) for the
+          given path.
       parameters:
           - name: path
             type: object_path
@@ -27,8 +27,8 @@
     - name: GetAncestors
       description: >
           Obtain a dictionary of ancestor -> services where ancestor is an
-          ancestor of path and services is of the type returned by the
-          GetObject method.
+          ancestor of path and services is of the type returned by the GetObject
+          method.
       parameters:
           - name: path
             type: object_path
@@ -47,9 +47,8 @@
           - xyz.openbmc_project.Common.Error.ResourceNotFound
     - name: GetSubTree
       description: >
-          Obtain a dictionary of path -> services where path is in
-          sutbtree and services is of the type returned by the
-          GetObject method.
+          Obtain a dictionary of path -> services where path is in sutbtree and
+          services is of the type returned by the GetObject method.
       parameters:
           - name: subtree
             type: object_path
@@ -97,8 +96,8 @@
           - xyz.openbmc_project.Common.Error.ResourceNotFound
     - name: GetAssociatedSubTree
       description: >
-          Same as GetSubTree, but only return the dbus paths that are
-          an association endpoint on associatedPath
+          Same as GetSubTree, but only return the dbus paths that are an
+          association endpoint on associatedPath
       parameters:
           - name: associatedPath
             type: object_path
@@ -126,8 +125,8 @@
           - xyz.openbmc_project.Common.Error.ResourceNotFound
     - name: GetAssociatedSubTreePaths
       description: >
-          Same as GetSubTreePaths, but only return the dbus paths that are
-          an association endpoint on associatedPath
+          Same as GetSubTreePaths, but only return the dbus paths that are an
+          association endpoint on associatedPath
       parameters:
           - name: associatedPath
             type: object_path
@@ -153,4 +152,3 @@
                 An array of paths.
       errors:
           - xyz.openbmc_project.Common.Error.ResourceNotFound
-
diff --git a/yaml/xyz/openbmc_project/PFR/Attributes.interface.yaml b/yaml/xyz/openbmc_project/PFR/Attributes.interface.yaml
index 1482b4e..1b5cd41 100644
--- a/yaml/xyz/openbmc_project/PFR/Attributes.interface.yaml
+++ b/yaml/xyz/openbmc_project/PFR/Attributes.interface.yaml
@@ -1,20 +1,20 @@
 description: >
-    Provides the object attributes needed for resiliency of platform
-    firmware, recommended by NIST SP 800-193.
+    Provides the object attributes needed for resiliency of platform firmware,
+    recommended by NIST SP 800-193.
 
 properties:
     - name: Provisioned
       type: boolean
       description: >
-          Indicates platform firmware provisioned state. Provisioned
-          platform may provide resiliency features.
+          Indicates platform firmware provisioned state. Provisioned platform
+          may provide resiliency features.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
 
     - name: Locked
       type: boolean
       description: >
-          Indicates the platform firmware provisioning locked state.
-          Once the provisioning is locked, it can't be re-provisioned.
+          Indicates the platform firmware provisioning locked state. Once the
+          provisioning is locked, it can't be re-provisioned.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
diff --git a/yaml/xyz/openbmc_project/PLDM/Event.interface.yaml b/yaml/xyz/openbmc_project/PLDM/Event.interface.yaml
index 62fa083..9206782 100644
--- a/yaml/xyz/openbmc_project/PLDM/Event.interface.yaml
+++ b/yaml/xyz/openbmc_project/PLDM/Event.interface.yaml
@@ -1,24 +1,22 @@
 description: >
-    Implement to emit D-Bus signal for PLDM Event Messages. PLDM Event
-    Messages are PLDM monitoring and control messages that are used by
-    a PLDM terminus to synchronously or asynchronously report PLDM events
-    to a central party called the PLDM Event Receiver.
+    Implement to emit D-Bus signal for PLDM Event Messages. PLDM Event Messages
+    are PLDM monitoring and control messages that are used by a PLDM terminus to
+    synchronously or asynchronously report PLDM events to a central party called
+    the PLDM Event Receiver.
 
-    When the PLDM daemon receives a sensorEvent of type stateSensorState,
-    it emits the StateSensorEvent signal.
+    When the PLDM daemon receives a sensorEvent of type stateSensorState, it
+    emits the StateSensorEvent signal.
 
-    This signal would be used by PLDM Requester apps on the BMC, which
-    will rely on this signal to determine state changes on a connected
-    PLDM entity.
+    This signal would be used by PLDM Requester apps on the BMC, which will rely
+    on this signal to determine state changes on a connected PLDM entity.
 
-    More information about PLDM Event Messages can be found at DSP0248
-    version 1.2.0 section 13.
+    More information about PLDM Event Messages can be found at DSP0248 version
+    1.2.0 section 13.
 
 signals:
     - name: StateSensorEvent
       description: >
-          Signal indicating that a state sensor change EventMessage is
-          received.
+          Signal indicating that a state sensor change EventMessage is received.
           More information about properties can be found at DSP0248 version
           1.2.0 table 19.
       properties:
@@ -43,11 +41,11 @@
           - name: eventState
             type: byte
             description: >
-                The event state value from the state change that triggered
-                the event message.
+                The event state value from the state change that triggered the
+                event message.
 
           - name: previousEventState
             type: byte
             description: >
-                The event state value for the state from which the present
-                event state was entered.
+                The event state value for the state from which the present event
+                state was entered.
diff --git a/yaml/xyz/openbmc_project/PLDM/PDR.interface.yaml b/yaml/xyz/openbmc_project/PLDM/PDR.interface.yaml
index dcdec47..a366203 100644
--- a/yaml/xyz/openbmc_project/PLDM/PDR.interface.yaml
+++ b/yaml/xyz/openbmc_project/PLDM/PDR.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement to fetch the PDRs. PDRs are Platform Descriptor
-    Records which are the collection of information that includes semantic
-    and association information.
+    Implement to fetch the PDRs. PDRs are Platform Descriptor Records which are
+    the collection of information that includes semantic and association
+    information.
 
     This API would be used by PLDM Requester apps on the BMC.
 
@@ -35,8 +35,8 @@
           - name: EntityID
             type: uint16
             description: >
-                A numeric value that represents an entity that can be associated to
-                a PLDM state set.
+                A numeric value that represents an entity that can be associated
+                to a PLDM state set.
 
                 More information is found at
                 http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf
@@ -45,8 +45,8 @@
           - name: StateSetId
             type: uint16
             description: >
-                A numeric value that identifies the PLDM State Set that is used with
-                this sensor.
+                A numeric value that identifies the PLDM State Set that is used
+                with this sensor.
 
                 More information is found at
                 http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf
@@ -57,25 +57,25 @@
             type: array[array[byte]]
             description: >
                 Array of State Effecter PDRs, where a PDR is an array[byte].
-                Multiple PDRs of the format present in table 89 of DSP0248 version
-                1.2.0 are returned. Each of the PDRs returned has the common header
-                along with all the other fields in table 89 and 90 of
-                DSP0248 of version 1.2.0 .
+                Multiple PDRs of the format present in table 89 of DSP0248
+                version 1.2.0 are returned. Each of the PDRs returned has the
+                common header along with all the other fields in table 89 and 90
+                of DSP0248 of version 1.2.0 .
 
       errors:
           - xyz.openbmc_project.Common.Error.ResourceNotFound
 
     - name: FindStateSensorPDR
       description: >
-          Obtain the state sensor PDR, for the input TID,
-          entity ID and state set id. If multiple PLDM entity instances
-          (in state sensor PDRs) match the EntityId and StateSetId below,
-          all the corresponding state sensor PDRs are returned. More than one PDR
-          can be returned for the same state set id.
+          Obtain the state sensor PDR, for the input TID, entity ID and state
+          set id. If multiple PLDM entity instances (in state sensor PDRs) match
+          the EntityId and StateSetId below, all the corresponding state sensor
+          PDRs are returned. More than one PDR can be returned for the same
+          state set id.
 
-          When the PDR for the given input TID, entity id
-          and state set id is not found, then the
-          xyz.openbmc_project.Common.Error.ResourceNotFound exception will be thrown.
+          When the PDR for the given input TID, entity id and state set id is
+          not found, then the xyz.openbmc_project.Common.Error.ResourceNotFound
+          exception will be thrown.
 
       parameters:
           - name: TID
@@ -86,25 +86,28 @@
           - name: EntityID
             type: uint16
             description: >
-                A numeric value that represents an entity that can be associated to a PLDM state set.
-                More information is found at
-                http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf section 7.
+                A numeric value that represents an entity that can be associated
+                to a PLDM state set. More information is found at
+                http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf
+                section 7.
 
           - name: StateSetId
             type: uint16
             description: >
-                A numeric value that identifies the PLDM State Set that is used with this sensor.
-                More information is found at
-                http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf section 6.
+                A numeric value that identifies the PLDM State Set that is used
+                with this sensor. More information is found at
+                http://dmtf.org/sites/default/files/standards/documents/DSP0249_1.0.0.pdf
+                section 6.
 
       returns:
           - name: StateSensorPDR
             type: array[array[byte]]
             description: >
-                Array of State Sensor PDRs, where a PDR is an array[byte]. Multiple PDRs of the
-                format present in table 80 of DSP0248 version 1.2.0 are returned. Each of the PDRs
-                returned has the common header along with all the other fields in table 80 and 81 of
-                DSP0248 of version 1.2.0 .
+                Array of State Sensor PDRs, where a PDR is an array[byte].
+                Multiple PDRs of the format present in table 80 of DSP0248
+                version 1.2.0 are returned. Each of the PDRs returned has the
+                common header along with all the other fields in table 80 and 81
+                of DSP0248 of version 1.2.0 .
 
       errors:
           - xyz.openbmc_project.Common.Error.ResourceNotFound
diff --git a/yaml/xyz/openbmc_project/PLDM/Provider/Certs/Authority/CSR.interface.yaml b/yaml/xyz/openbmc_project/PLDM/Provider/Certs/Authority/CSR.interface.yaml
index efee306..72606a1 100644
--- a/yaml/xyz/openbmc_project/PLDM/Provider/Certs/Authority/CSR.interface.yaml
+++ b/yaml/xyz/openbmc_project/PLDM/Provider/Certs/Authority/CSR.interface.yaml
@@ -1,17 +1,16 @@
 description: >
-    Implement this interface to pass CSR string to PLDM
-    to get CSR signed by host.
+    Implement this interface to pass CSR string to PLDM to get CSR signed by
+    host.
 
-    xyz.openbmc_project.Certs.ca.authority.Manager object implements
-    this interface which is added in the below commit
+    xyz.openbmc_project.Certs.ca.authority.Manager object implements this
+    interface which is added in the below commit
     https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/31808
 
 properties:
     - name: CSR
       type: string
       description: >
-          Certificate signing request content.
-          Should be a valid PEM encoded CSR string.
-          It's a const property.
+          Certificate signing request content. Should be a valid PEM encoded CSR
+          string. It's a const property.
       flags:
           - const
diff --git a/yaml/xyz/openbmc_project/PLDM/Requester.interface.yaml b/yaml/xyz/openbmc_project/PLDM/Requester.interface.yaml
index 2585c82..928f7b8 100644
--- a/yaml/xyz/openbmc_project/PLDM/Requester.interface.yaml
+++ b/yaml/xyz/openbmc_project/PLDM/Requester.interface.yaml
@@ -31,17 +31,17 @@
           granted to the input eid, then the
           xyz.openbmc_project.Common.Error.TooManyResources exception will be
           thrown. The recommendation for the caller upon receiving this
-          exception is to retry calling this method, at least once, after a
-          time period equal to the maximum instance id expiration interval,
-          which is 6 seconds as per DSP0240 v1.0.0. If the exception persists
-          post this interval, the way of handling the same (further retries,
-          report an error, etc) is left to the user.
+          exception is to retry calling this method, at least once, after a time
+          period equal to the maximum instance id expiration interval, which is
+          6 seconds as per DSP0240 v1.0.0. If the exception persists post this
+          interval, the way of handling the same (further retries, report an
+          error, etc) is left to the user.
       parameters:
           - name: eid
             type: byte
             description: >
-                The MCTP endpoint, specified by 'eid' (endpoint id), for which the
-                new PLDM instance id needs to be generated.
+                The MCTP endpoint, specified by 'eid' (endpoint id), for which
+                the new PLDM instance id needs to be generated.
       returns:
           - name: instanceid
             type: byte
diff --git a/yaml/xyz/openbmc_project/Sensor/Accuracy.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Accuracy.interface.yaml
index 7d5fa54..cd454b1 100644
--- a/yaml/xyz/openbmc_project/Sensor/Accuracy.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Accuracy.interface.yaml
@@ -7,10 +7,9 @@
       default: NaN
       description: >
           The accuracy range (+/-) of the sensor Value as a percentage, with a
-          value between 0 and 100.
-          This is NOT a percentage of the sensor value ranges.
-          A value of 0.25 would be 0.25%, a value of 2 would represent 2%.
-          A value of 2 for 2% would mean that a reading of 10 would have an
+          value between 0 and 100. This is NOT a percentage of the sensor value
+          ranges. A value of 0.25 would be 0.25%, a value of 2 would represent
+          2%. A value of 2 for 2% would mean that a reading of 10 would have an
           actual value of 9.8 to 10.2.
       flags:
           - readonly
diff --git a/yaml/xyz/openbmc_project/Sensor/Threshold/Critical.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Threshold/Critical.interface.yaml
index dfd65b7..c2d548e 100644
--- a/yaml/xyz/openbmc_project/Sensor/Threshold/Critical.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Threshold/Critical.interface.yaml
@@ -1,7 +1,8 @@
 description: >
     Implement to provide critical class sensor thresholds.  Objects implementing
-    Sensor.Threshold.Critical must be instantiated in the correct hierarchy within
-    the sensors namespace.  The following sensor hierarchies are recognized:
+    Sensor.Threshold.Critical must be instantiated in the correct hierarchy
+    within the sensors namespace.  The following sensor hierarchies are
+    recognized:
       airflow
       altitude
       current
@@ -33,19 +34,19 @@
     - name: CriticalAlarmHigh
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
-          CriticalAlarmHigh may be set to False to clear an alarm condition.
-          The behavior of setting CriticalAlarmHigh to True is undefined.
+          CriticalAlarmHigh may be set to False to clear an alarm condition. The
+          behavior of setting CriticalAlarmHigh to True is undefined.
     - name: CriticalAlarmLow
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
-          CriticalAlarmLow may be set to False to clear an alarm condition.
-          The behavior of setting CriticalAlarmLow to True is undefined.
+          CriticalAlarmLow may be set to False to clear an alarm condition. The
+          behavior of setting CriticalAlarmLow to True is undefined.
 signals:
     - name: CriticalHighAlarmAsserted
       description: >
diff --git a/yaml/xyz/openbmc_project/Sensor/Threshold/HardShutdown.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Threshold/HardShutdown.interface.yaml
index dc8d855..0329c33 100644
--- a/yaml/xyz/openbmc_project/Sensor/Threshold/HardShutdown.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Threshold/HardShutdown.interface.yaml
@@ -35,16 +35,16 @@
     - name: HardShutdownAlarmHigh
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           HardShutdownAlarmHigh may be set to False to clear an alarm condition.
           The behavior of setting HardShutdownAlarmHigh to True is undefined.
     - name: HardShutdownAlarmLow
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           HardShutdownAlarmLow may be set to False to clear an alarm condition.
           The behavior of setting HardShutdownAlarmLow to True is undefined.
diff --git a/yaml/xyz/openbmc_project/Sensor/Threshold/PerformanceLoss.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Threshold/PerformanceLoss.interface.yaml
index 8303572..8ce09c1 100644
--- a/yaml/xyz/openbmc_project/Sensor/Threshold/PerformanceLoss.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Threshold/PerformanceLoss.interface.yaml
@@ -23,28 +23,28 @@
       type: double
       default: NaN
       description: >
-          The upper bound of the warning threshold.  A value of 'NaN' is used
-          to indicate there is no threshold of this type.
+          The upper bound of the warning threshold.  A value of 'NaN' is used to
+          indicate there is no threshold of this type.
     - name: PerformanceLossLow
       type: double
       default: NaN
       description: >
-          The lower bound of the warning threshold.  A value of 'NaN' is used
-          to indicate there is no threshold of this type.
+          The lower bound of the warning threshold.  A value of 'NaN' is used to
+          indicate there is no threshold of this type.
     - name: PerformanceLossAlarmHigh
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           PerformanceLossAlarmHigh may be set to False to clear an alarm
-          condition. The behavior of setting PerformanceLossAlarmHigh to True
-          is undefined.
+          condition. The behavior of setting PerformanceLossAlarmHigh to True is
+          undefined.
     - name: PerformanceLossAlarmLow
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           PerformanceLossAlarmLow may be set to False to clear an alarm
           condition. The behavior of setting PerformanceLossAlarmLow to True is
diff --git a/yaml/xyz/openbmc_project/Sensor/Threshold/SoftShutdown.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Threshold/SoftShutdown.interface.yaml
index ba175f6..6d7184b 100644
--- a/yaml/xyz/openbmc_project/Sensor/Threshold/SoftShutdown.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Threshold/SoftShutdown.interface.yaml
@@ -34,16 +34,16 @@
     - name: SoftShutdownAlarmHigh
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           SoftShutdownAlarmHigh may be set to False to clear an alarm condition.
           The behavior of setting SoftShutdownAlarmHigh to True is undefined.
     - name: SoftShutdownAlarmLow
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
           SoftShutdownAlarmLow may be set to False to clear an alarm condition.
           The behavior of setting SoftShutdownAlarmLow to True is undefined.
diff --git a/yaml/xyz/openbmc_project/Sensor/Threshold/Warning.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Threshold/Warning.interface.yaml
index a141da5..de128f0 100644
--- a/yaml/xyz/openbmc_project/Sensor/Threshold/Warning.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Threshold/Warning.interface.yaml
@@ -1,7 +1,8 @@
 description: >
     Implement to provide warning class sensor thresholds.  Objects implementing
-    Sensor.Threshold.Warning must be instantiated in the correct hierarchy within
-    the sensors namespace.  The following sensor hierarchies are recognized:
+    Sensor.Threshold.Warning must be instantiated in the correct hierarchy
+    within the sensors namespace.  The following sensor hierarchies are
+    recognized:
       airflow
       altitude
       current
@@ -22,30 +23,30 @@
       type: double
       default: NaN
       description: >
-          The upper bound of the warning threshold.  A value of 'NaN' is used
-          to indicate there is no threshold of this type.
+          The upper bound of the warning threshold.  A value of 'NaN' is used to
+          indicate there is no threshold of this type.
     - name: WarningLow
       type: double
       default: NaN
       description: >
-          The lower bound of the warning threshold.  A value of 'NaN' is used
-          to indicate there is no threshold of this type.
+          The lower bound of the warning threshold.  A value of 'NaN' is used to
+          indicate there is no threshold of this type.
     - name: WarningAlarmHigh
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
-          WarningAlarmHigh may be set to False to clear an alarm condition.
-          The behavior of setting WarningAlarmHigh to True is undefined.
+          WarningAlarmHigh may be set to False to clear an alarm condition. The
+          behavior of setting WarningAlarmHigh to True is undefined.
     - name: WarningAlarmLow
       type: boolean
       description: >
-          True if the sensor value has exceeded the defined bound.
-          False if the sensor value has not exceeded the defined bound.
+          True if the sensor value has exceeded the defined bound. False if the
+          sensor value has not exceeded the defined bound.
 
-          WarningAlarmLow may be set to False to clear an alarm condition.
-          The behavior of setting WarningAlarmLow to True is undefined.
+          WarningAlarmLow may be set to False to clear an alarm condition. The
+          behavior of setting WarningAlarmLow to True is undefined.
 signals:
     - name: WarningHighAlarmAsserted
       description: >
diff --git a/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml b/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml
index dd80468..f2139a7 100644
--- a/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml
@@ -1,8 +1,7 @@
 description: >
-    Implement to provide sensor readings.  Objects implementing
-    Sensor.Value must be instantiated in the correct
-    hierarchy within the sensors namespace.  The following sensor
-    hierarchies are recognized:
+    Implement to provide sensor readings.  Objects implementing Sensor.Value
+    must be instantiated in the correct hierarchy within the sensors
+    namespace.  The following sensor hierarchies are recognized:
       airflow
       altitude
       current
@@ -15,9 +14,8 @@
       utilization
       voltage
 
-    Any service implementing Sensor.Value on one or more objects must
-    implement org.freedesktop.DBus.ObjectManager on
-    /xyz/openbmc_project/sensors.
+    Any service implementing Sensor.Value on one or more objects must implement
+    org.freedesktop.DBus.ObjectManager on /xyz/openbmc_project/sensors.
 
     All Sensor.Value properties are read-only.
 
@@ -39,18 +37,17 @@
     - name: Unit
       type: enum[self.Unit]
       description: >
-          The unit of the reading.  Immutable once set for a sensor.
-          For objects in the airflow namespace, Unit must be "CFM"
-          For objects in the altitude namespace, Unit must be "Meters".
-          For objects in the current namespace, Unit must be "Amperes".
-          For objects in the energy namespace, Unit must be "Joules".
-          For objects in the fan_tach namespace, Unit must be "RPMS".
-          For objects in the humidity namespace, Unit must be "PercentRH"
-          For objects in the power namespace, Unit must be "Watts".
-          For objects in the pressure namespace, Unit must be "Pascals"
-          For objects in the temperature namespace, Unit must be "DegreesC".
-          For objects in the utilization namespace, Unit must be "Percent"
-          For objects in the voltage namespace, Unit must be "Volts".
+          The unit of the reading.  Immutable once set for a sensor. For objects
+          in the airflow namespace, Unit must be "CFM" For objects in the
+          altitude namespace, Unit must be "Meters". For objects in the current
+          namespace, Unit must be "Amperes". For objects in the energy
+          namespace, Unit must be "Joules". For objects in the fan_tach
+          namespace, Unit must be "RPMS". For objects in the humidity namespace,
+          Unit must be "PercentRH" For objects in the power namespace, Unit must
+          be "Watts". For objects in the pressure namespace, Unit must be
+          "Pascals" For objects in the temperature namespace, Unit must be
+          "DegreesC". For objects in the utilization namespace, Unit must be
+          "Percent" For objects in the voltage namespace, Unit must be "Volts".
 
 enumerations:
     - name: Unit
@@ -94,16 +91,16 @@
 associations:
     - name: inventory
       description: >
-          Sensors may implement an 'inventory' to 'sensors' association with
-          the inventory item related to it.
+          Sensors may implement an 'inventory' to 'sensors' association with the
+          inventory item related to it.
       reverse_names:
           - sensors
       required_endpoint_interfaces:
           - xyz.openbmc_project.Inventory.Item
     - name: monitoring
       description: >
-          Sensors may monitor the BMC's resource utilization and implement
-          an associatoin to the Bmc item.
+          Sensors may monitor the BMC's resource utilization and implement an
+          associatoin to the Bmc item.
       reverse_names:
           - monitored_by
       required_endpoint_interfaces:
diff --git a/yaml/xyz/openbmc_project/Sensor/ValueMutability.interface.yaml b/yaml/xyz/openbmc_project/Sensor/ValueMutability.interface.yaml
index 0ed8fe0..0428740 100644
--- a/yaml/xyz/openbmc_project/Sensor/ValueMutability.interface.yaml
+++ b/yaml/xyz/openbmc_project/Sensor/ValueMutability.interface.yaml
@@ -5,10 +5,8 @@
       type: boolean
       default: false
       description: >
-          A hint to a server that provides sensor access
-          to external users, such as an IPMI server,
-          as to whether or not to allow external users
-          to modify the value, via "set sensor value"
-          commands or similar. True to allow
-          modification (read-write). False to disallow
-          modification (read-only).
+          A hint to a server that provides sensor access to external users, such
+          as an IPMI server, as to whether or not to allow external users to
+          modify the value, via "set sensor value" commands or similar. True to
+          allow modification (read-write). False to disallow modification
+          (read-only).
diff --git a/yaml/xyz/openbmc_project/Software/Activation.interface.yaml b/yaml/xyz/openbmc_project/Software/Activation.interface.yaml
index 7153c41..aba2a62 100644
--- a/yaml/xyz/openbmc_project/Software/Activation.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/Activation.interface.yaml
@@ -36,12 +36,12 @@
                 The Software.Version failed during or after Activation.
           - name: Staged
             description: >
-                The Software.Version is currently in staged flash area.
-                This is moved from staged flash area to active upon reset.
+                The Software.Version is currently in staged flash area. This is
+                moved from staged flash area to active upon reset.
           - name: Staging
             description: >
-                The Software.Version is currently being staged into the
-                staging flash area.
+                The Software.Version is currently being staged into the staging
+                flash area.
     - name: RequestedActivations
       description: >
           The possible RequestedActivation states of a Software.Version.
diff --git a/yaml/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml b/yaml/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml
index 51fbc8e..f452819 100644
--- a/yaml/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml
@@ -4,10 +4,10 @@
     `Software.Version` is in `Activating` state.
 
     The specific state transition(s) to prevent are left to the implementation.
-    A typical use of this would be to prevent (delay) the power-on of a
-    managed host while the BIOS is being updated.  The managed host, via
-    systemd transitions, might start the power-on sequence and then wait for
-    any object with this `ActivationBlocksTransition` interface to no longer be
-    in `Activating` state.  Causal ordering of dbus operations can prove that
-    no update is currently being performed and the power-on sequence may safely
+    A typical use of this would be to prevent (delay) the power-on of a managed
+    host while the BIOS is being updated.  The managed host, via systemd
+    transitions, might start the power-on sequence and then wait for any object
+    with this `ActivationBlocksTransition` interface to no longer be in
+    `Activating` state.  Causal ordering of dbus operations can prove that no
+    update is currently being performed and the power-on sequence may safely
     continue.
diff --git a/yaml/xyz/openbmc_project/Software/ApplyOptions.interface.yaml b/yaml/xyz/openbmc_project/Software/ApplyOptions.interface.yaml
index 715af7c..4d5a447 100644
--- a/yaml/xyz/openbmc_project/Software/ApplyOptions.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/ApplyOptions.interface.yaml
@@ -1,11 +1,11 @@
 description: >
     To implement the Activation apply options for a newly uploaded firmware
-    image. The apply options property is specific to each firmware update
-    and is used during firmware activation. ApplyOptions usage during
-    firmware activation is implementation specific, not all firmware
-    targets need ApplyOptions. This property is removed after activation
-    of the firmware is done and when the firmware goes to Active state.
-    The default value of this property is false.
+    image. The apply options property is specific to each firmware update and is
+    used during firmware activation. ApplyOptions usage during firmware
+    activation is implementation specific, not all firmware targets need
+    ApplyOptions. This property is removed after activation of the firmware is
+    done and when the firmware goes to Active state. The default value of this
+    property is false.
 properties:
     - name: ClearConfig
       type: boolean
diff --git a/yaml/xyz/openbmc_project/Software/ApplyTime.interface.yaml b/yaml/xyz/openbmc_project/Software/ApplyTime.interface.yaml
index 6cdedcf..0162458 100644
--- a/yaml/xyz/openbmc_project/Software/ApplyTime.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/ApplyTime.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    To implement the apply time of a newly updated software image.
-    The apply time property is global to all firmware update packages
-    and the default value of the property is OnReset.
+    To implement the apply time of a newly updated software image. The apply
+    time property is global to all firmware update packages and the default
+    value of the property is OnReset.
 properties:
     - name: RequestedApplyTime
       type: enum[self.RequestedApplyTimes]
@@ -11,8 +11,8 @@
 enumerations:
     - name: RequestedApplyTimes
       description: >
-          The possible values of this property indicate when the newly
-          updated software image will be activated.
+          The possible values of this property indicate when the newly updated
+          software image will be activated.
       values:
           - name: Immediate
             description: >
diff --git a/yaml/xyz/openbmc_project/Software/README.md b/yaml/xyz/openbmc_project/Software/README.md
index 0c08036..ad18ea3 100644
--- a/yaml/xyz/openbmc_project/Software/README.md
+++ b/yaml/xyz/openbmc_project/Software/README.md
@@ -6,13 +6,12 @@
 code update:
 
 1. _ImageManager_ - This is a process which manages a collection of, likely
-   temporary, images located somewhere in a file system.
-   These are images which are available on the BMC for update.
+   temporary, images located somewhere in a file system. These are images which
+   are available on the BMC for update.
 2. _ItemUpdater_ - This is a process which manages specific storage elements,
-   likely for an inventory item, to determine which software
-   versions are installed onto that item. A specific example of
-   this would be a process that controls and updates the BIOS
-   flash module for a managed host.
+   likely for an inventory item, to determine which software versions are
+   installed onto that item. A specific example of this would be a process that
+   controls and updates the BIOS flash module for a managed host.
 
 A simple system design would be to include a single _ImageManager_ and two
 _ItemUpdater_(s): one for the BMC itself and one for the Host.
@@ -20,33 +19,33 @@
 ### ImageManager
 
 The _ImageManager_ would provide interfaces at `/xyz/openbmc_project/software`
-to allow additional images to be added to the BMC, such as Object.Add() for
-REST and DownloadViaTFTP() for TFTP. The standard Object.Delete() interface
-would also be provided to facilitate removing images which are no longer
-needed. Images maintained in the file system would be presented as a
-corresponding `/xyz/openbmc_project/software/<id>` object. In addition, the
-`xyz.openbmc_project.Common.FilePath` interface would be provided to specify
-the location of the image.
+to allow additional images to be added to the BMC, such as Object.Add() for REST
+and DownloadViaTFTP() for TFTP. The standard Object.Delete() interface would
+also be provided to facilitate removing images which are no longer needed.
+Images maintained in the file system would be presented as a corresponding
+`/xyz/openbmc_project/software/<id>` object. In addition, the
+`xyz.openbmc_project.Common.FilePath` interface would be provided to specify the
+location of the image.
 
 It is assumed that the _ImageManager_ has [at least] a bare minimum amount of
-parsing knowledge, perhaps due to a common image format, to allow it to
-populate all of the properties of `xyz.openbmc_project.Software.Version` and
+parsing knowledge, perhaps due to a common image format, to allow it to populate
+all of the properties of `xyz.openbmc_project.Software.Version` and
 `xyz.openbmc_project.Inventory.Decorator.Compatible`. _ItemUpdater_(s) will
 likely listen for standard D-Bus signals to identify new images being created.
 
 ### ItemUpdater
 
 The _ItemUpdater_ is responsible for monitoring for new `Software.Version`
-elements being created to identify versions that are applicable to the
-inventory element(s) it is managing. The _ItemUpdater_ should dynamically
-create an `xyz.openbmc_project.Software.Activation` interface under
+elements being created to identify versions that are applicable to the inventory
+element(s) it is managing. The _ItemUpdater_ should dynamically create an
+`xyz.openbmc_project.Software.Activation` interface under
 `/xyz/openbmc_project/software/`, an association of type
 `{active_image,software_version}` between the `Software.Version` and
-`Software.Activation` under `/xyz/openbmc_project/software/`, and an
-association of type `{activation,item}` between the `Inventory.Item` and
-`Software.Activation` under `/xyz/openbmc_project/software/<id>`. Application
-of the software image is then handled through the `RequestedActivation`
-property of the `Software.Activation` interface.
+`Software.Activation` under `/xyz/openbmc_project/software/`, and an association
+of type `{activation,item}` between the `Inventory.Item` and
+`Software.Activation` under `/xyz/openbmc_project/software/<id>`. Application of
+the software image is then handled through the `RequestedActivation` property of
+the `Software.Activation` interface.
 
 In many cases, the _ItemUpdater_'s creation of the `Software.Activation`
 interface will be at the exact same path as the _ImageManager_'s
@@ -59,10 +58,10 @@
 the corresponding image, such as `/xyz/openbmc_project/software/<id>/<device>`.
 
 The _ItemUpdater_ should, if possible, also create its own
-`xyz.openbmc_project.Software.Version` objects, and appropriate associations
-for software versions that are currently present on the managed inventory
-element(s). This provides a mechanism for interrogation of the
-software versions when the _ImageManager_ no longer contains a copy.
+`xyz.openbmc_project.Software.Version` objects, and appropriate associations for
+software versions that are currently present on the managed inventory
+element(s). This provides a mechanism for interrogation of the software versions
+when the _ImageManager_ no longer contains a copy.
 
 ## Details
 
@@ -124,97 +123,92 @@
   that element.
 
 If an image contains sub-sections which can be applied to multiple system
-elements, the image should contain `Compatible` strings for each sub-section.
-It is expected that the _ItemUpdater_ is aware of how to find the sub-section
+elements, the image should contain `Compatible` strings for each sub-section. It
+is expected that the _ItemUpdater_ is aware of how to find the sub-section
 appropriate for any element(s) being Activated.
 
 ### Activation States
 
-`xyz.openbmc_project.Software.Activation` has a property Activation that can
-be in the following states:
+`xyz.openbmc_project.Software.Activation` has a property Activation that can be
+in the following states:
 
 1. _NotReady_ - Indicating that the _ItemUpdater_ is still processing the
-   version and it is therefore not ready for activation. This
-   might be used on an image that has a security header while
-   verification is being performed.
+   version and it is therefore not ready for activation. This might be used on
+   an image that has a security header while verification is being performed.
 2. _Invalid_ - Indicating that, while the `Software.Version.Purpose` suggested
-   the image was valid for a managed element, a detailed analysis
-   by the _ItemUpdater_ showed that it was not. Reasons may
-   include image corruption detected via CRC or security
-   verification failure. An event may be recorded with additional
-   details.
+   the image was valid for a managed element, a detailed analysis by the
+   _ItemUpdater_ showed that it was not. Reasons may include image corruption
+   detected via CRC or security verification failure. An event may be recorded
+   with additional details.
 3. _Ready_ - Indicating that the `Software.Version` can be activated.
 4. _Activating_ - Indicating that the `Software.Version` is in the process of
    being activated.
-5. _Active_ - The `Software.Version` is active on the managed element. Note
-   that on systems with redundant storage devices a version might
-   be _Active_ but not the primary version.
+5. _Active_ - The `Software.Version` is active on the managed element. Note that
+   on systems with redundant storage devices a version might be _Active_ but not
+   the primary version.
 6. _Failed_ - The `Software.Version` or the storage medium on which it is stored
    has failed. An event may be recorded with additional details.
 7. _Staged_ - The `Software.Version` is in staged flash region. This will be
-   moved from staged flash region to active flash region upon reset.
-   Staged flash region is the designated flash area which is used to
-   store the integrity validated firmware image that comes in during
-   firmware update process. Note that the staged image is not
-   necessarily a functional firmware.
+   moved from staged flash region to active flash region upon reset. Staged
+   flash region is the designated flash area which is used to store the
+   integrity validated firmware image that comes in during firmware update
+   process. Note that the staged image is not necessarily a functional firmware.
 
 ### Image Apply Time
 
 `xyz.openbmc_project.Software.ApplyTime` has a property called
-RequestedApplyTime that indicates when the newly applied software image will
-be activated. RequestedApplyTime is a D-Bus property that maps to the
-"ApplyTime" property in the Redfish UpdateService schema. Below are the
-currently supported values and the value can be supplied through
-HttpPushUriApplyTime object:
+RequestedApplyTime that indicates when the newly applied software image will be
+activated. RequestedApplyTime is a D-Bus property that maps to the "ApplyTime"
+property in the Redfish UpdateService schema. Below are the currently supported
+values and the value can be supplied through HttpPushUriApplyTime object:
 
 1. _Immediate_ - Indicating that the `Software.Version` needs to be activated
    immediately.
-2. _OnReset_ - Indicating that the `Software.Version` needs to be activated
-   on the next reset.
+2. _OnReset_ - Indicating that the `Software.Version` needs to be activated on
+   the next reset.
 
 ### Blocking State Transitions
 
-It is sometimes useful to block a system state transition while activations
-are being performed. For example, we do not want to boot a managed host while
-its BIOS is being updated. In order to facilitate this, the interface
+It is sometimes useful to block a system state transition while activations are
+being performed. For example, we do not want to boot a managed host while its
+BIOS is being updated. In order to facilitate this, the interface
 `xyz.openbmc_project.Software.ActivationBlocksTransition` may be added to any
-object with `Software.Activation` to indicate this behavior. See that
-interface for more details.
+object with `Software.Activation` to indicate this behavior. See that interface
+for more details.
 
 It is strongly suggested that any activations are completed prior to a managed
 BMC reboot. This could be facilitated with systemd service specifiers.
 
 ### Software Versions
 
-All version identifiers are implementation specific strings. No format
-should be assumed.
+All version identifiers are implementation specific strings. No format should be
+assumed.
 
 Some software versions are a collection of images, each with their own version
-identifiers. The `xyz.openbmc_project.Software.ExtendedVersion` interface
-can be added to any `Software.Version` to express the versioning of the
-aggregation.
+identifiers. The `xyz.openbmc_project.Software.ExtendedVersion` interface can be
+added to any `Software.Version` to express the versioning of the aggregation.
 
 ### Activation Progress
 
-The `xyz.openbmc_project.Software.ActivationProgress` interface is provided
-to show current progress while a software version is _Activating_. It is
-expected that an _ItemUpdater_ will dynamically create this interface while
-the version is _Activating_ and dynamically remove it when the activation is
-complete (or failed).
+The `xyz.openbmc_project.Software.ActivationProgress` interface is provided to
+show current progress while a software version is _Activating_. It is expected
+that an _ItemUpdater_ will dynamically create this interface while the version
+is _Activating_ and dynamically remove it when the activation is complete (or
+failed).
 
 ### Handling Redundancy
 
 The `xyz.openbmc_project.Software.RedundancyPriority` interface is provided to
-express the relationship between two (or more) software versions activated for
-a single managed element. It is expected that all installed versions are listed
-as _Active_ and the `Priority` shows which version is the primary and which are
+express the relationship between two (or more) software versions activated for a
+single managed element. It is expected that all installed versions are listed as
+_Active_ and the `Priority` shows which version is the primary and which are
 available for redundancy.
 
 Prior to `Activation`, it can be useful to indicate a desired
 `RedundancyPriority`. This can be done by setting the `Priority` on the
-`RequestedRedundancyPriority` interface. Some _ItemUpdater_ implementations
-may not honor this field or be unable to comply with the request, in which
-case the resulting `Activation` may result in one of two conditions: a
+`RequestedRedundancyPriority` interface. Some _ItemUpdater_ implementations may
+not honor this field or be unable to comply with the request, in which case the
+resulting `Activation` may result in one of two conditions: a
 `ActivationState = Failed` or an `ActivateState = Active` with a
 `RedundancyPriority = 0 (High)`.
 
@@ -239,10 +233,9 @@
 
 ### Software Settings
 
-The `xyz.openbmc_project.Software.Settings` interface is provided
-to show the settings of the given software. The `Software.Settings`
-should be added to along side `Software.Version` to represent
-its state from the same service.
+The `xyz.openbmc_project.Software.Settings` interface is provided to show the
+settings of the given software. The `Software.Settings` should be added to along
+side `Software.Version` to represent its state from the same service.
 
 ```sh
 busctl introspect $SERVICE /xyz/openbmc_project/software/software_0
@@ -262,10 +255,10 @@
 
 ### Find all software versions on the system, either active or available
 
-List `/xyz/openbmc_project/software/`. This list can be filtered to just
-active listing `.../software/active/` and following the `software_version`
-association to retrieve version information. To list just "functional" or
-running versions list `/xyz/openbmc_project/software/functional/`.
+List `/xyz/openbmc_project/software/`. This list can be filtered to just active
+listing `.../software/active/` and following the `software_version` association
+to retrieve version information. To list just "functional" or running versions
+list `/xyz/openbmc_project/software/functional/`.
 
 ### Find all software versions on a managed element
 
diff --git a/yaml/xyz/openbmc_project/Software/RequestedRedundancyPriority.interface.yaml b/yaml/xyz/openbmc_project/Software/RequestedRedundancyPriority.interface.yaml
index 141b147..2491a86 100644
--- a/yaml/xyz/openbmc_project/Software/RequestedRedundancyPriority.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/RequestedRedundancyPriority.interface.yaml
@@ -6,9 +6,9 @@
       type: byte
       default: 0
       description: >
-          Upon Activation of the software Version, the *ItemUpdater*
-          should attempt to activate the software version such that
-          the resulting `Software.RedundancyPriority.Priority` is Priority.
+          Upon Activation of the software Version, the *ItemUpdater* should
+          attempt to activate the software version such that the resulting
+          `Software.RedundancyPriority.Priority` is Priority.
 
           See `Software.RedundancyPriority.Priority` for valid values and
           definitions.
@@ -16,5 +16,5 @@
           By default, any Activation should be done to the highest priority.
           Some *ItemUpdater* implementations may be unable to apply this
           `RequestedRedundancyPriority.Priority`, resulting in an
-          `ActivationState` which is either `Failed` or `Active` with
-          `Priority` of `0 (High)`.
+          `ActivationState` which is either `Failed` or `Active` with `Priority`
+          of `0 (High)`.
diff --git a/yaml/xyz/openbmc_project/Software/Settings.interface.yaml b/yaml/xyz/openbmc_project/Software/Settings.interface.yaml
index 0477cd8..14dc6f3 100644
--- a/yaml/xyz/openbmc_project/Software/Settings.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/Settings.interface.yaml
@@ -7,5 +7,5 @@
       default: false
       description: >
           This property shall indicate whether the software image can be
-          overwritten, where a value `true` shall indicate that the software cannot
-          be altered or overwritten.
+          overwritten, where a value `true` shall indicate that the software
+          cannot be altered or overwritten.
diff --git a/yaml/xyz/openbmc_project/Software/Version.errors.yaml b/yaml/xyz/openbmc_project/Software/Version.errors.yaml
index 8bb78cb..4f3a0c5 100644
--- a/yaml/xyz/openbmc_project/Software/Version.errors.yaml
+++ b/yaml/xyz/openbmc_project/Software/Version.errors.yaml
@@ -1,10 +1,10 @@
 - name: Incompatible
   description: >
-      A system component has a software version that is incompatible as determined
-      by the implementation and needs to be updated. Some usage examples for this
-      error include creating logging events and providing information on
-      implementation reactions such as when the system is prevented from powering
-      on if a minimum version level is not met.
+      A system component has a software version that is incompatible as
+      determined by the implementation and needs to be updated. Some usage
+      examples for this error include creating logging events and providing
+      information on implementation reactions such as when the system is
+      prevented from powering on if a minimum version level is not met.
 - name: AlreadyExists
   description: >
       This image version already exists on the device
diff --git a/yaml/xyz/openbmc_project/Software/Version.interface.yaml b/yaml/xyz/openbmc_project/Software/Version.interface.yaml
index 6176010..ee4d5ac 100644
--- a/yaml/xyz/openbmc_project/Software/Version.interface.yaml
+++ b/yaml/xyz/openbmc_project/Software/Version.interface.yaml
@@ -13,11 +13,12 @@
     - name: Purpose
       type: enum[self.VersionPurpose]
       description: >
-          The purpose of the version.  As in, what can it be used for or
-          applied to?
+          The purpose of the version.  As in, what can it be used for or applied
+          to?
 
-          This property is deprecated in favor of Compatible strings and inventory
-          associations.  The enumeration should not be expanded further.
+          This property is deprecated in favor of Compatible strings and
+          inventory associations.  The enumeration should not be expanded
+          further.
 enumerations:
     - name: VersionPurpose
       description: >
diff --git a/yaml/xyz/openbmc_project/State/BMC.interface.yaml b/yaml/xyz/openbmc_project/State/BMC.interface.yaml
index 03186c5..4a1d575 100644
--- a/yaml/xyz/openbmc_project/State/BMC.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/BMC.interface.yaml
@@ -1,8 +1,8 @@
 description: >
     Implementation of BMC state management.  When rebooting we are in
     transition.  When Ready all services required are running
-    successfully.  When we are Not Ready this implies not all services
-    have started that are required to be.
+    successfully.  When we are Not Ready this implies not all services have
+    started that are required to be.
 
 properties:
     - name: RequestedBMCTransition
@@ -19,8 +19,8 @@
     - name: LastRebootTime
       type: uint64
       description: >
-          The last time at which the BMC came out of a reboot as
-          determined by its uptime, in epoch time, in milliseconds.
+          The last time at which the BMC came out of a reboot as determined by
+          its uptime, in epoch time, in milliseconds.
 
     - name: LastRebootCause
       type: enum[self.RebootCause]
@@ -52,18 +52,20 @@
                 Ready implies all services started and are running successfully
           - name: "NotReady"
             description: >
-                Not ready implies not all services have started or are not running successfully
+                Not ready implies not all services have started or are not
+                running successfully
           - name: "UpdateInProgress"
             description: >
-                UpdateInProgress implies BMC is in firmware update mode. CurrentBMCState
-                will be set to "UpdateInProgress" while starting image download and
-                reset to Ready, once activation is done or error case during update process.
+                UpdateInProgress implies BMC is in firmware update mode.
+                CurrentBMCState will be set to "UpdateInProgress" while starting
+                image download and reset to Ready, once activation is done or
+                error case during update process.
           - name: "Quiesced"
             description: >
                 BMC firmware is quiesced. The BMC firmware is enabled but either
-                unresponsive or only processing a restricted set of commands. This
-                state may be the result of a service within the BMC going into a
-                failed state.
+                unresponsive or only processing a restricted set of commands.
+                This state may be the result of a service within the BMC going
+                into a failed state.
 
     - name: RebootCause
       description: >
diff --git a/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml b/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
index d72ef2b..cb57e29 100644
--- a/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Boot/PostCode.interface.yaml
@@ -1,31 +1,31 @@
 description: >
-    Monitor Post code coming and buffer all of them based on boot cycle
-    into file system.
+    Monitor Post code coming and buffer all of them based on boot cycle into
+    file system.
 
 properties:
     - name: CurrentBootCycleCount
       type: uint16
       description: >
-          It is used to indicate number of boot cycles that have
-          post codes archived. It starts from 1 and is limited to
-          MaxBootCycleNum.
+          It is used to indicate number of boot cycles that have post codes
+          archived. It starts from 1 and is limited to MaxBootCycleNum.
     - name: MaxBootCycleNum
       type: uint16
       description: >
-          The max cached boot cycles for post code.
-          It is used to indicate end user what's the max boot number,
-          and make sure get command parameter less than it.
+          The max cached boot cycles for post code. It is used to indicate end
+          user what's the max boot number, and make sure get command parameter
+          less than it.
 methods:
     - name: GetPostCodesWithTimeStamp
       description: >
-          Method to get the cached post codes of the indicated boot cycle with timestamp.
+          Method to get the cached post codes of the indicated boot cycle with
+          timestamp.
       parameters:
           - name: Index
             type: uint16
             description: >
-                Index indicates which boot cycle of post codes is requested.
-                1 is for the most recent boot cycle. CurrentBootCycleCount is for the
-                oldest boot cycle.
+                Index indicates which boot cycle of post codes is requested. 1
+                is for the most recent boot cycle. CurrentBootCycleCount is for
+                the oldest boot cycle.
       returns:
           - name: Codes
             type: dict[uint64, struct[uint64,array[byte]]]
@@ -38,9 +38,9 @@
           - name: Index
             type: uint16
             description: >
-                Index indicates which boot cycle of post codes is requested.
-                1 is for the most recent boot cycle. CurrentBootCycleCount is for the
-                oldest boot cycle.
+                Index indicates which boot cycle of post codes is requested. 1
+                is for the most recent boot cycle. CurrentBootCycleCount is for
+                the oldest boot cycle.
       returns:
           - name: Codes
             type: array[struct[uint64,array[byte]]]
diff --git a/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml b/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
index 07f2d82..f079640 100644
--- a/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
@@ -12,11 +12,11 @@
       type: uint64
       default: 0
       description: >
-          BootProgressLastUpdate is the last time the BootProgress
-          property was updated. The time is the Epoch time, number
-          of microseconds since 1 Jan 1970 00::00::00 UTC.
-          This can be compared with the current BootProgress value
-          to know how long the boot has been on the current boot step.
+          BootProgressLastUpdate is the last time the BootProgress property was
+          updated. The time is the Epoch time, number of microseconds since 1
+          Jan 1970 00::00::00 UTC. This can be compared with the current
+          BootProgress value to know how long the boot has been on the current
+          boot step.
 
 enumerations:
     - name: ProgressStages
diff --git a/yaml/xyz/openbmc_project/State/Chassis.interface.yaml b/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
index 0d1fb45..7c74a04 100644
--- a/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Chassis.interface.yaml
@@ -5,32 +5,31 @@
       type: enum[self.Transition]
       default: "Off"
       description: >
-          The desired power transition to start on this chassis.
-          This will be preserved across AC power cycles of the BMC.
+          The desired power transition to start on this chassis. This will be
+          preserved across AC power cycles of the BMC.
 
     - name: CurrentPowerState
       type: enum[self.PowerState]
       description: >
-          A read-only property describing the current chassis power state.
-          A user can determine if a chassis is in transition by comparing
-          the CurrentPowerState and RequestedPowerTransition properties.
+          A read-only property describing the current chassis power state. A
+          user can determine if a chassis is in transition by comparing the
+          CurrentPowerState and RequestedPowerTransition properties.
 
     - name: CurrentPowerStatus
       type: enum[self.PowerStatus]
       description: >
-          A read-only property describing the current chassis power status.
-          This property aggregates all available information about the status
-          of the power coming into the chassis. Note that this is different
-          then the CurrentPowerState in that it provides status of the power
-          coming into the chassis, not the actual state of the chassis power.
+          A read-only property describing the current chassis power status. This
+          property aggregates all available information about the status of the
+          power coming into the chassis. Note that this is different then the
+          CurrentPowerState in that it provides status of the power coming into
+          the chassis, not the actual state of the chassis power.
 
     - name: LastStateChangeTime
       type: uint64
       description: >
-          The last time at which the chassis power changed state, as
-          tracked by the CurrentPowerState property, in epoch time,
-          in milliseconds.  This can be used to tell when the chassis
-          was last powered on or off.
+          The last time at which the chassis power changed state, as tracked by
+          the CurrentPowerState property, in epoch time, in milliseconds.  This
+          can be used to tell when the chassis was last powered on or off.
 
 enumerations:
     - name: Transition
@@ -78,12 +77,13 @@
           - name: "UninterruptiblePowerSupply"
             description: >
                 Chassis power is being provided via an uninterruptible power
-                supply. Note that some systems may choose to continue to use this
-                status, even once power has returned to the system, to indicate the
-                uninterruptible power supply is charging or is below a certain
-                threshold of charged. This provides system owners the flexibility on
-                whether their system requires a certain level of charged
-                uninterruptible power supply to be in a 'Good' state or not.
+                supply. Note that some systems may choose to continue to use
+                this status, even once power has returned to the system, to
+                indicate the uninterruptible power supply is charging or is
+                below a certain threshold of charged. This provides system
+                owners the flexibility on whether their system requires a
+                certain level of charged uninterruptible power supply to be in a
+                'Good' state or not.
           - name: "Good"
             description: >
                 Chassis power status is in a good condition
diff --git a/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml b/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
index 0dfefdd..22d8dd1 100644
--- a/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Decorator/PowerSystemInputs.interface.yaml
@@ -18,10 +18,11 @@
       values:
           - name: Fault
             description: >
-                The power supply unit(s) are not providing enough power for normal
-                chassis operation, such as in a Brownout/Blackout condition where one
-                or more power supplies report AC loss VIN fault.
+                The power supply unit(s) are not providing enough power for
+                normal chassis operation, such as in a Brownout/Blackout
+                condition where one or more power supplies report AC loss VIN
+                fault.
           - name: Good
             description: >
-                The power supply unit(s) are providing enough power for normal chassis
-                operation.
+                The power supply unit(s) are providing enough power for normal
+                chassis operation.
diff --git a/yaml/xyz/openbmc_project/State/Drive.interface.yaml b/yaml/xyz/openbmc_project/State/Drive.interface.yaml
index b0500e8..8681a68 100644
--- a/yaml/xyz/openbmc_project/State/Drive.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Drive.interface.yaml
@@ -23,9 +23,9 @@
       type: uint64
       default: maxint
       description: >
-          Time when the Drive last rebooted represented in EpochTime.
-          The time reference should be based on the BMC's time.
-          If not supported, it will be represented as maxint.
+          Time when the Drive last rebooted represented in EpochTime. The time
+          reference should be based on the BMC's time. If not supported, it will
+          be represented as maxint.
       flags:
           - readonly
 
diff --git a/yaml/xyz/openbmc_project/State/Host.interface.yaml b/yaml/xyz/openbmc_project/State/Host.interface.yaml
index 02deb2d..6495134 100644
--- a/yaml/xyz/openbmc_project/State/Host.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Host.interface.yaml
@@ -6,8 +6,8 @@
       type: enum[self.Transition]
       default: "Off"
       description: >
-          The desired host transition.  This will be preserved across AC
-          power cycles of the BMC.
+          The desired host transition.  This will be preserved across AC power
+          cycles of the BMC.
 
     - name: CurrentHostState
       type: enum[self.HostState]
@@ -36,12 +36,12 @@
                 Host firmware should be on
           - name: "Reboot"
             description: >
-                Host firmware should be rebooted. Chassis power will be cycled from
-                off to on during this reboot
+                Host firmware should be rebooted. Chassis power will be cycled
+                from off to on during this reboot
           - name: "GracefulWarmReboot"
             description: >
-                Host firmware be will notified to shutdown and once complete, the
-                host firmware will be rebooted. Chassis power will remain on
+                Host firmware be will notified to shutdown and once complete,
+                the host firmware will be rebooted. Chassis power will remain on
                 throughout the reboot
           - name: "ForceWarmReboot"
             description: >
@@ -72,17 +72,17 @@
                 Host firmware is transitioning to a Running state
           - name: "Quiesced"
             description: >
-                Host firmware is quiesced. The host firmware is enabled but either
-                unresponsive or only processing a restricted set of commands. This
-                state can be a result of the host entering an error state or booting
-                into a BIOS setup environment. The BootProgress property will
-                provide details on which it is.
+                Host firmware is quiesced. The host firmware is enabled but
+                either unresponsive or only processing a restricted set of
+                commands. This state can be a result of the host entering an
+                error state or booting into a BIOS setup environment. The
+                BootProgress property will provide details on which it is.
           - name: "DiagnosticMode"
             description: >
                 Host firmware is capturing debug information. Powering off your
-                system while the host is in this state will prevent the debug data
-                from being properly collected. The host will move to one of the
-                other states once complete.
+                system while the host is in this state will prevent the debug
+                data from being properly collected. The host will move to one of
+                the other states once complete.
 
     - name: RestartCause
       description: >
@@ -118,5 +118,5 @@
                 xyz.openbmc_project.State.ScheduledHostTransition interface
           - name: "HostCrash"
             description: >
-                The host firmware crashed and the BMC has automatically initiated a
-                restart of the host firmware
+                The host firmware crashed and the BMC has automatically
+                initiated a restart of the host firmware
diff --git a/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml b/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
index 660b2ba..5cfc9ab 100644
--- a/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/PowerOnHours.interface.yaml
@@ -4,5 +4,6 @@
     - name: POHCounter
       type: uint32
       description: >
-          This counter shows how many hours the system has been running. The value
-          is a cumulative one and includes all working hours since production.
+          This counter shows how many hours the system has been running. The
+          value is a cumulative one and includes all working hours since
+          production.
diff --git a/yaml/xyz/openbmc_project/State/README.md b/yaml/xyz/openbmc_project/State/README.md
index 1ebe698..d661cdd 100644
--- a/yaml/xyz/openbmc_project/State/README.md
+++ b/yaml/xyz/openbmc_project/State/README.md
@@ -14,26 +14,25 @@
 There are three states to track and control on a BMC based server. The states
 below in () represent the actual parameter name as found in
 `/xyz/openbmc_project/state/`+`/bmcX,/hostY,/chassisZ` where X,Y,Z are the
-instances (in most cases 0). For all three states, the software tracks a
-current state, and a requested transition.
+instances (in most cases 0). For all three states, the software tracks a current
+state, and a requested transition.
 
 1. _BMC_ : The BMC has either started all required systemd services and reached
    it's required target (Ready) or it's on it's way there (NotReady). Users can
    request a (Reboot).
 
-2. _Host_ : The host is either (Off), (Running), or it's (Quiesced).
-   Running simply implies that the processors are executing instructions. Users
-   can request the host be in a (Off), (On), or (Reboot) state. More details on
-   different Reboot options below.
-   Quiesced means the host OS is in a quiesce state and the system should be
-   checked for errors. For more information refer to
-   [Error Handling of systemd][1].
+2. _Host_ : The host is either (Off), (Running), or it's (Quiesced). Running
+   simply implies that the processors are executing instructions. Users can
+   request the host be in a (Off), (On), or (Reboot) state. More details on
+   different Reboot options below. Quiesced means the host OS is in a quiesce
+   state and the system should be checked for errors. For more information refer
+   to [Error Handling of systemd][1].
 
-3. _Chassis_ : The chassis is either (Off) or (On)
-   This represents the state of power to the chassis. The Chassis being on
-   is a pre-req to the Host being running. Users can request for the chassis to
-   be (Off) or (On). A transition to one or the other is implied by the
-   transition not matching the current state.
+3. _Chassis_ : The chassis is either (Off) or (On) This represents the state of
+   power to the chassis. The Chassis being on is a pre-req to the Host being
+   running. Users can request for the chassis to be (Off) or (On). A transition
+   to one or the other is implied by the transition not matching the current
+   state.
 
 A simple system design would be to include a single _BMC_, _Host_, and
 _Chassis_.
@@ -43,8 +42,7 @@
 
 ### BMC
 
-The _BMC_ would provide interfaces at
-`/xyz/openbmc_project/state/bmc<instance>`
+The _BMC_ would provide interfaces at `/xyz/openbmc_project/state/bmc<instance>`
 
 ### _Host_
 
@@ -61,28 +59,28 @@
 This is an instance under _Chassis_ and provide interface at
 `/xyz/openbmc_project/state/chassis_system<instance>`
 
-Instance 0 (chassis_system0) will be treated as a complete chassis system
-which will include BMC, host and chassis. This will support hard power
-cycle of complete system.
+Instance 0 (chassis_system0) will be treated as a complete chassis system which
+will include BMC, host and chassis. This will support hard power cycle of
+complete system.
 
-In multi-host or multi-chassis system, instance number can be used from
-1-N, as 0 is reserved for complete system. In multi chassis system this
-can be named as chassis_system1 to chassis_systemN
+In multi-host or multi-chassis system, instance number can be used from 1-N, as
+0 is reserved for complete system. In multi chassis system this can be named as
+chassis_system1 to chassis_systemN
 
 ## BMC to Host to Chassis Mapping
 
-In the future, OpenBMC will provide an association API, which allows one
-to programmatically work out the mapping between BMCs, Chassis and Hosts.
+In the future, OpenBMC will provide an association API, which allows one to
+programmatically work out the mapping between BMCs, Chassis and Hosts.
 
 In order to not introduce subtle bugs with existing API users, `bmc0`,
 `chassis0` and `host0` are special. If they exist, they are guaranteed to talk
-to the system as a whole as if it was a system with one BMC, one chassis and
-one host. If there are multiple hosts, then bmc0/chassis0/host0
-will _not_ exist. In the event of multiple BMCs or Chassis, bmc0 and chassis0
-will act on all entities as if they are one (if at all possible).
+to the system as a whole as if it was a system with one BMC, one chassis and one
+host. If there are multiple hosts, then bmc0/chassis0/host0 will _not_ exist. In
+the event of multiple BMCs or Chassis, bmc0 and chassis0 will act on all
+entities as if they are one (if at all possible).
 
-This behaviour means that existing code will continue to work, or error out
-if the request would be ambiguous and probably not what the user wanted.
+This behaviour means that existing code will continue to work, or error out if
+the request would be ambiguous and probably not what the user wanted.
 
 For example, if a system has two chassis, only powering off the first chassis
 (while leaving the second chassis on) is certainly _not_ what the API user had
@@ -93,37 +91,40 @@
 to function on this multi-chassis system.
 
 For example, a system with multiple hosts would have BMCs, Chassis and Hosts
-_all_ start numbering from 1 rather than 0. This is because multiple hosts
-could be in the same chassis, or controlled by the same BMC, so taking action
-against them would _not_ be what the API user intended.
+_all_ start numbering from 1 rather than 0. This is because multiple hosts could
+be in the same chassis, or controlled by the same BMC, so taking action against
+them would _not_ be what the API user intended.
 
-It is safe to continue to write code referencing bmc0, host0 and
-chassis0 and that code will continue to function, or error out rather than
-doing something undesirable.
+It is safe to continue to write code referencing bmc0, host0 and chassis0 and
+that code will continue to function, or error out rather than doing something
+undesirable.
 
 ## Hard vs. Soft Power Off
 
-A hard power off is where you simply cut power to a chassis. You don't give
-the software running on that chassis any chance to cleanly shut down.
-A soft power off is where you send a notification to the host that is running
-on that chassis that a shutdown is requested, and wait for that host firmware
-to indicate it has shut itself down. Once complete, power is then removed
-from the chassis. By default, a host off or reboot request does the soft
-power off. If a user desires a cold reboot then they should simply issue a
-power off transition request to the chassis, and then issue an on transition
-request to the host.
+A hard power off is where you simply cut power to a chassis. You don't give the
+software running on that chassis any chance to cleanly shut down. A soft power
+off is where you send a notification to the host that is running on that chassis
+that a shutdown is requested, and wait for that host firmware to indicate it has
+shut itself down. Once complete, power is then removed from the chassis. By
+default, a host off or reboot request does the soft power off. If a user desires
+a cold reboot then they should simply issue a power off transition request to
+the chassis, and then issue an on transition request to the host.
 
 ## Operating System State and Boot Progress Properties
 
-[OperatingSystemState][3] property is used to track different progress states
-of the OS or the hypervisor boot, while the [BootProgress][4] property is used
+[OperatingSystemState][3] property is used to track different progress states of
+the OS or the hypervisor boot, while the [BootProgress][4] property is used
 mainly for indicating system firmware boot progress. The enumerations used in
 both the cases are influenced by standard interfaces like IPMI 2.0 (Section
 42.2, Sensor Type Codes and Data, Table 42, Base OS boot status) and PLDM state
 spec (DSP0249, Section 6.3, State Sets Tables, Table 7 – Boot-Related State
 Sets, Set ID - 196 Boot Progress).
 
-[1]: https://github.com/openbmc/docs/blob/master/architecture/openbmc-systemd.md#error-handling-of-systemd
-[2]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/
-[3]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml
-[4]: https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
+[1]:
+  https://github.com/openbmc/docs/blob/master/architecture/openbmc-systemd.md#error-handling-of-systemd
+[2]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/
+[3]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/OperatingSystem/Status.interface.yaml
+[4]:
+  https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State/Boot/Progress.interface.yaml
diff --git a/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml b/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
index 74f1fd9..e364ca7 100644
--- a/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/ScheduledHostTransition.interface.yaml
@@ -5,25 +5,21 @@
       type: uint64
       default: 0
       description: >
-          ScheduledTime is a date time when the host will be
-          powered on/off. The time is the Epoch time, number
-          of seconds since 1 Jan 1970 00::00::00 UTC.
+          ScheduledTime is a date time when the host will be powered on/off. The
+          time is the Epoch time, number of seconds since 1 Jan 1970 00::00::00
+          UTC.
 
-          When ScheduledTime is 0, it means the functionality
-          is disabled.
-          When ScheduledTime is smaller than current time,
-          error InvalidTime will be thrown.
-          When the controller detects the ScheduledTime has passed,
-          it will execute the ScheduledTransition and reset the
-          value to 0. Once the transition starts, there won't be
-          any retries.
-          When the real time changes, the controller shall check if
-          the time is still in the future. If so, it will stop the
-          existing timer and restart it with new wait time. Otherwise,
-          stop the existing timer and execute the ScheduledTransition.
-          When ScheduledTime is reached, but the host is not ready
-          to power on/off, e.g. when BMC is rebooting, BMC shall
-          set the host ScheduledTransition after it is ready.
+          When ScheduledTime is 0, it means the functionality is disabled. When
+          ScheduledTime is smaller than current time, error InvalidTime will be
+          thrown. When the controller detects the ScheduledTime has passed, it
+          will execute the ScheduledTransition and reset the value to 0. Once
+          the transition starts, there won't be any retries. When the real time
+          changes, the controller shall check if the time is still in the
+          future. If so, it will stop the existing timer and restart it with new
+          wait time. Otherwise, stop the existing timer and execute the
+          ScheduledTransition. When ScheduledTime is reached, but the host is
+          not ready to power on/off, e.g. when BMC is rebooting, BMC shall set
+          the host ScheduledTransition after it is ready.
       errors:
           - xyz.openbmc_project.ScheduledTime.Error.InvalidTime
 
@@ -31,5 +27,5 @@
       type: enum[xyz.openbmc_project.State.Host.Transition]
       default: "On"
       description: >
-          The desired power transition to support scheduled power on/off.
-          The default operation supports scheduled power on.
+          The desired power transition to support scheduled power on/off. The
+          default operation supports scheduled power on.
diff --git a/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml b/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
index ac71e61..8c7dee1 100644
--- a/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
+++ b/yaml/xyz/openbmc_project/State/Watchdog.interface.yaml
@@ -4,16 +4,16 @@
 methods:
     - name: ResetTimeRemaining
       description: >
-          Resets the time remaining to the configured interval.
-          This is equivalent to reading the Interval and writing it
-          into the TimeRemaining. Optionally the watchdog can be enabled
-          during the reset process.
+          Resets the time remaining to the configured interval. This is
+          equivalent to reading the Interval and writing it into the
+          TimeRemaining. Optionally the watchdog can be enabled during the reset
+          process.
       parameters:
           - name: EnableWatchdog
             type: boolean
             description: >
-                If true the watchdog will be enabled when the reset
-                is performed.
+                If true the watchdog will be enabled when the reset is
+                performed.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
 
@@ -41,8 +41,8 @@
     - name: TimeRemaining
       type: uint64
       description: >
-          Time remaining before timeout, in milli-second.
-          Setting this property can re-arm the watchdog.
+          Time remaining before timeout, in milli-second. Setting this property
+          can re-arm the watchdog.
       default: 0
     - name: CurrentTimerUse
       type: enum[self.TimerUse]
diff --git a/yaml/xyz/openbmc_project/Telemetry/Report.interface.yaml b/yaml/xyz/openbmc_project/Telemetry/Report.interface.yaml
index e074da6..552200d 100644
--- a/yaml/xyz/openbmc_project/Telemetry/Report.interface.yaml
+++ b/yaml/xyz/openbmc_project/Telemetry/Report.interface.yaml
@@ -19,16 +19,15 @@
     - name: ReadingParameters
       type: array[struct[array[struct[object_path,string]],enum[self.OperationType],string,enum[self.CollectionTimescope],uint64]]
       description: >
-          Collection of metric parameters. Single entry consists of:
-          array of [sensor path, metadata] tuples, operation type, metric ID,
-          collection timescope and collection duration. Sensor paths point to
-          sensors providing readings. Metadata contains client information; in
-          case of Redfish it shall be metric's URI. Operation type provides
-          knowledge of action executed on readings. Metric ID contains name that
-          can be mapped to metadata (like Redfish Metric ID). Collection
-          timescope specifies type of time scope applied to specific metric.
-          Collection duration stores timestamp related with timescope type in
-          milliseconds.
+          Collection of metric parameters. Single entry consists of: array of
+          [sensor path, metadata] tuples, operation type, metric ID, collection
+          timescope and collection duration. Sensor paths point to sensors
+          providing readings. Metadata contains client information; in case of
+          Redfish it shall be metric's URI. Operation type provides knowledge of
+          action executed on readings. Metric ID contains name that can be
+          mapped to metadata (like Redfish Metric ID). Collection timescope
+          specifies type of time scope applied to specific metric. Collection
+          duration stores timestamp related with timescope type in milliseconds.
     - name: Readings
       type: struct[uint64,array[struct[string,string,double,uint64]]]
       description: >
diff --git a/yaml/xyz/openbmc_project/Telemetry/ReportManager.interface.yaml b/yaml/xyz/openbmc_project/Telemetry/ReportManager.interface.yaml
index 6f596e2..78a1fd7 100644
--- a/yaml/xyz/openbmc_project/Telemetry/ReportManager.interface.yaml
+++ b/yaml/xyz/openbmc_project/Telemetry/ReportManager.interface.yaml
@@ -78,8 +78,8 @@
       type: uint64
       description: >
           Minimal allowed time between readings property updates. It limits
-          Interval property in xyz.openbmc_project.Telemetry.Report and
-          interval parameter in AddReport method.
+          Interval property in xyz.openbmc_project.Telemetry.Report and interval
+          parameter in AddReport method.
       flags:
           - const
     - name: SupportedOperationTypes
diff --git a/yaml/xyz/openbmc_project/Telemetry/Trigger.interface.yaml b/yaml/xyz/openbmc_project/Telemetry/Trigger.interface.yaml
index 747c349..5b6515f 100644
--- a/yaml/xyz/openbmc_project/Telemetry/Trigger.interface.yaml
+++ b/yaml/xyz/openbmc_project/Telemetry/Trigger.interface.yaml
@@ -30,9 +30,9 @@
       type: array[dict[object_path,string]]
       description: >
           Map of sensors that is monitored within trigger. D-Bus sensor path is
-          used as map's key. Its value is a metadata that is used
-          to store user data about sensor. In Redfish, metadata will be set to
-          endpoint corresponding to that sensor.
+          used as map's key. Its value is a metadata that is used to store user
+          data about sensor. In Redfish, metadata will be set to endpoint
+          corresponding to that sensor.
     - name: Thresholds
       type: variant[array[struct[enum[self.Type],uint64,enum[self.Direction],double]],array[struct[string,enum[self.Severity],uint64,string]]]
       description: >
diff --git a/yaml/xyz/openbmc_project/Time/EpochTime.interface.yaml b/yaml/xyz/openbmc_project/Time/EpochTime.interface.yaml
index 5bbe043..c272322 100644
--- a/yaml/xyz/openbmc_project/Time/EpochTime.interface.yaml
+++ b/yaml/xyz/openbmc_project/Time/EpochTime.interface.yaml
@@ -4,13 +4,12 @@
     - name: Elapsed
       type: uint64
       description: >
-          Time elpased since the
-          Epoch(1 Jan 1970 00:00:00 UTC), in microseconds.
+          Time elpased since the Epoch(1 Jan 1970 00:00:00 UTC), in
+          microseconds.
 
-          On setting this property, errors may be thrown.
-          InternalFailure means BMC fails to set the time.
-          InsufficientPermission means it is not allowed to set time depend
-          on the time settings.
+          On setting this property, errors may be thrown. InternalFailure means
+          BMC fails to set the time. InsufficientPermission means it is not
+          allowed to set time depend on the time settings.
       errors:
           - xyz.openbmc_project.Time.Error.NotAllowed
           - xyz.openbmc_project.Time.Error.Failed
diff --git a/yaml/xyz/openbmc_project/User/AccountPolicy.interface.yaml b/yaml/xyz/openbmc_project/User/AccountPolicy.interface.yaml
index b55b288..1cfc4bf 100644
--- a/yaml/xyz/openbmc_project/User/AccountPolicy.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/AccountPolicy.interface.yaml
@@ -5,18 +5,16 @@
     - name: MaxLoginAttemptBeforeLockout
       type: uint16
       description: >
-          Configures the maximum permissible attempt before locking
-          out the user. Value of 0 indicates that account lockout
-          feature is disabled.
+          Configures the maximum permissible attempt before locking out the
+          user. Value of 0 indicates that account lockout feature is disabled.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
 
     - name: AccountUnlockTimeout
       type: uint32
       description: >
-          Configures timeout needed (in seconds) to unlock the account
-          after a lockout. Value of 0 indicates that account must be
-          unlocked manually.
+          Configures timeout needed (in seconds) to unlock the account after a
+          lockout. Value of 0 indicates that account must be unlocked manually.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
 
@@ -25,8 +23,8 @@
       description: >
           Configures the minimum password length. Minimum password length
           specified in build time is marked as default value. This property
-          cannot be configured below the build time default value but can be
-          set to higher one for security reasons.
+          cannot be configured below the build time default value but can be set
+          to higher one for security reasons.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
           - xyz.openbmc_project.Common.Error.InvalidArgument
@@ -34,8 +32,8 @@
     - name: RememberOldPasswordTimes
       type: byte
       description: >
-          Configures the number of times old password shouldn't be allowed
-          when trying to update new password. Value of 0 (by default) indicates
-          this feature is not enforced.
+          Configures the number of times old password shouldn't be allowed when
+          trying to update new password. Value of 0 (by default) indicates this
+          feature is not enforced.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
diff --git a/yaml/xyz/openbmc_project/User/Attributes.interface.yaml b/yaml/xyz/openbmc_project/User/Attributes.interface.yaml
index 50d1816..70ef629 100644
--- a/yaml/xyz/openbmc_project/User/Attributes.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/Attributes.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Provides user objects, their properties.
-    As communication to this service is done through authenticated
-    & authorized session, there won't be any validation for the both.
+    Provides user objects, their properties. As communication to this service is
+    done through authenticated & authorized session, there won't be any
+    validation for the both.
 
 properties:
     - name: UserGroups
@@ -30,12 +30,12 @@
     - name: UserLockedForFailedAttempt
       type: boolean
       description: >
-          Locked or unlocked state of the user. After repeated failed
-          login attempt (configured through MaxLoginAttemptBeforeLockout),
-          locked out user can be unlocked manually by setting false to
-          this property. This property will return true if user is locked
-          out user. AccountUnlockTimeout property can be configured to unlock
-          the user after a timeout.
+          Locked or unlocked state of the user. After repeated failed login
+          attempt (configured through MaxLoginAttemptBeforeLockout), locked out
+          user can be unlocked manually by setting false to this property. This
+          property will return true if user is locked out user.
+          AccountUnlockTimeout property can be configured to unlock the user
+          after a timeout.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
 
@@ -53,7 +53,7 @@
       flags:
           - const
       description: >
-          True when the user's password must be changed before access should
-          be granted.
+          True when the user's password must be changed before access should be
+          granted.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
diff --git a/yaml/xyz/openbmc_project/User/Ldap/Config.interface.yaml b/yaml/xyz/openbmc_project/User/Ldap/Config.interface.yaml
index 75a7695..d0fc5ee 100644
--- a/yaml/xyz/openbmc_project/User/Ldap/Config.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/Ldap/Config.interface.yaml
@@ -1,7 +1,7 @@
 description: >
-    Implement to update LDAP mandatory properties.
-    Any service implementing User.Ldap.Config interface on one or more
-    objects must implement Object.Enable interface on the object.
+    Implement to update LDAP mandatory properties. Any service implementing
+    User.Ldap.Config interface on one or more objects must implement
+    Object.Enable interface on the object.
 
 properties:
     - name: LDAPServerURI
@@ -24,15 +24,14 @@
       type: string
       description: >
           Specifies the credentials with which to bind,Implementation should
-          consider changing the permissions of the underlying file to
-          only grant access to the root user.
-          This property value should not be reflected on the D-bus object itself.
-          Implementation can use the given value and update the service
-          implementing the LDAP client.This is just to facilitate the support
-          for changing the bin dn password if needed.
-          Currently this property is over D-bus, There are security concerns
-          for the same, but once we find better way to update the ldap password
-          we would fix it.
+          consider changing the permissions of the underlying file to only grant
+          access to the root user. This property value should not be reflected
+          on the D-bus object itself. Implementation can use the given value and
+          update the service implementing the LDAP client.This is just to
+          facilitate the support for changing the bin dn password if needed.
+          Currently this property is over D-bus, There are security concerns for
+          the same, but once we find better way to update the ldap password we
+          would fix it.
     - name: LDAPBaseDN
       type: string
       description: >
@@ -51,24 +50,23 @@
       type: enum[self.Type]
       description: >
           Specifies the the configured server is ActiveDirectory(AD) or
-          OpenLdap. It's just an indication for the LDAP stack running on
-          the BMC, in case the app is implemented in such a way that it has
-          to react differently for AD vs openldap.
-          This property is readonly, Once the D-Bus object gets created then
-          this property should not be modifiable.
+          OpenLdap. It's just an indication for the LDAP stack running on the
+          BMC, in case the app is implemented in such a way that it has to react
+          differently for AD vs openldap. This property is readonly, Once the
+          D-Bus object gets created then this property should not be modifiable.
       errors:
           - xyz.openbmc_project.Common.Error.InternalFailure
           - xyz.openbmc_project.Common.Error.NotAllowed
     - name: GroupNameAttribute
       type: string
       description: >
-          The value of this property shall be the attribute name
-          that contains the name of the Group in the LDAP server.
+          The value of this property shall be the attribute name that contains
+          the name of the Group in the LDAP server.
     - name: UserNameAttribute
       type: string
       description: >
-          The value of this property shall be the attribute name
-          that contains the username in the LDAP server.
+          The value of this property shall be the attribute name that contains
+          the username in the LDAP server.
 enumerations:
     - name: SearchScope
       description: >
diff --git a/yaml/xyz/openbmc_project/User/Ldap/Create.interface.yaml b/yaml/xyz/openbmc_project/User/Ldap/Create.interface.yaml
index 452bd9e..fae5b8b 100644
--- a/yaml/xyz/openbmc_project/User/Ldap/Create.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/Ldap/Create.interface.yaml
@@ -4,10 +4,10 @@
 methods:
     - name: CreateConfig
       description: >
-          This method always creates a new config file as well as a D-Bus 
-          object to represent the config, it will destroy an existing one,
-          if found. In other words, this is not an update API. Individual
-          properties can be updated as per the
+          This method always creates a new config file as well as a D-Bus object
+          to represent the config, it will destroy an existing one, if found. In
+          other words, this is not an update API. Individual properties can be
+          updated as per the
           xyz/openbmc_project/User/Ldap/Config.interface.yaml.
       parameters:
           - name: LDAPServerURI
@@ -37,18 +37,18 @@
             description: >
                 Specifies the the configured server is ActiveDirectory(AD) or
                 OpenLdap. It's just an indication for the LDAP stack running on
-                the BMC, in case the app is implemented in such a way that it has
-                to react differently for AD vs openldap.
+                the BMC, in case the app is implemented in such a way that it
+                has to react differently for AD vs openldap.
           - name: GroupNameAttribute
             type: string
             description: >
-                Specifies the attribute name that contains the name
-                of the Group in the LDAP server.
+                Specifies the attribute name that contains the name of the Group
+                in the LDAP server.
           - name: UsernameAttribute
             type: string
             description: >
-                Specifies the attribute name that contains
-                the username in the LDAP server.
+                Specifies the attribute name that contains the username in the
+                LDAP server.
       returns:
           - name: path
             type: string
diff --git a/yaml/xyz/openbmc_project/User/Manager.interface.yaml b/yaml/xyz/openbmc_project/User/Manager.interface.yaml
index 14774c0..4cc0ab0 100644
--- a/yaml/xyz/openbmc_project/User/Manager.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/Manager.interface.yaml
@@ -1,13 +1,13 @@
 description: >
-    Provides user management functionality.
-    As communication to this service is done through authenticated
-    & authorized session, there won't be any validation for both.
+    Provides user management functionality. As communication to this service is
+    done through authenticated & authorized session, there won't be any
+    validation for both.
 
 methods:
     - name: CreateUser
       description: >
-          Creates a new user. If the user already exists, then it will throw
-          an error.
+          Creates a new user. If the user already exists, then it will throw an
+          error.
       parameters:
           - name: UserName
             type: string
@@ -36,8 +36,8 @@
 
     - name: RenameUser
       description: >
-          Rename's existing user to new one. All other properties of the
-          user will remain same.
+          Rename's existing user to new one. All other properties of the user
+          will remain same.
       parameters:
           - name: UserName
             type: string
@@ -59,8 +59,7 @@
 
     - name: GetUserInfo
       description: >
-          Get user properites.
-          If its local user, method returns
+          Get user properites. If its local user, method returns
              -user privilege
              -user groups
              -user enabled state
@@ -79,9 +78,8 @@
           - name: UserInfo
             type: dict[string,variant[string,array[string],boolean]]
             description: >
-                Dictionary of user properties.
-                List of key name and data type of properties below.
-                UserPrivilege -> privilege of the user(string)
+                Dictionary of user properties. List of key name and data type of
+                properties below. UserPrivilege -> privilege of the user(string)
                 UserGroups    -> list of groups user belongs to(array[string])
                 UserEnabled   -> user enabled state(boolean)
                 UserLockedForFailedAttempt -> user locked state(boolean)
@@ -89,8 +87,7 @@
                 RemoteUser    ->  remote or local user(boolean)
 
                 For detailed documentation of user properties refer
-                Attributes.interface.yaml
-                examples:
+                Attributes.interface.yaml examples:
                     1.UserInfo["RemoteUser"] returns true for ldap user
                     and false for local user.
                     2.UserInfo["UserGroups"] gets list of groups of user.
@@ -102,8 +99,8 @@
 
     - name: CreateGroup
       description: >
-          Creates a new groups. If the group already exists, or the
-          group name is not allowed to be created, it throws an error.
+          Creates a new groups. If the group already exists, or the group name
+          is not allowed to be created, it throws an error.
       parameters:
           - name: GroupName
             type: string
@@ -116,8 +113,8 @@
 
     - name: DeleteGroup
       description: >
-          Deletes an existing groups. If the group doesn't exists, or the
-          group name is not allowed to be deleted, it throws an error.
+          Deletes an existing groups. If the group doesn't exists, or the group
+          name is not allowed to be deleted, it throws an error.
       parameters:
           - name: GroupName
             type: string
diff --git a/yaml/xyz/openbmc_project/User/PrivilegeMapper.interface.yaml b/yaml/xyz/openbmc_project/User/PrivilegeMapper.interface.yaml
index 3e84ecd..ce87dec 100644
--- a/yaml/xyz/openbmc_project/User/PrivilegeMapper.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/PrivilegeMapper.interface.yaml
@@ -1,17 +1,17 @@
 description: >
-    Implement this interface to set the privilege of the user based on the
-    group name. The users in the group will inherit the privilege mapping of
-    the group. The Create method on success creates the object which implements
+    Implement this interface to set the privilege of the user based on the group
+    name. The users in the group will inherit the privilege mapping of the
+    group. The Create method on success creates the object which implements
     xyz.openbmc_project.User.PrivilegeMapperEntry. For example in the case of
     LDAP, the object path will be
-    /xyz/openbmc_project/user/ldap/privilege_mapper/<id>. The <id> will be
-    a unique number generated by the application. If the privilege mapping
-    already exists then it throws the exception
+    /xyz/openbmc_project/user/ldap/privilege_mapper/<id>. The <id> will be a
+    unique number generated by the application. If the privilege mapping already
+    exists then it throws the exception
     xyz.openbmc_project.User.Common.Error.PrivilegeMappingExists. To modify the
     privilege for a mapping which already exists, the Privilege property in the
-    xyz.openbmc_project.User.PrivilegeMapperEntry interface needs to be set.
-    Any application consuming the privilege mapping should not cache the object
-    path and use the GetManagedObjects method on the
+    xyz.openbmc_project.User.PrivilegeMapperEntry interface needs to be set. Any
+    application consuming the privilege mapping should not cache the object path
+    and use the GetManagedObjects method on the
     org.freedesktop.DBus.ObjectManager interface to figure out the D-Bus object
     path associated with the group name.
 
@@ -24,7 +24,8 @@
             type: string
             description: >
                 Group Name to which the privilege is to be assigned. In the case
-                of LDAP, the GroupName will be the LDAP group the user is part of.
+                of LDAP, the GroupName will be the LDAP group the user is part
+                of.
           - name: Privilege
             type: string
             description: >
diff --git a/yaml/xyz/openbmc_project/User/PrivilegeMapperEntry.interface.yaml b/yaml/xyz/openbmc_project/User/PrivilegeMapperEntry.interface.yaml
index 4217b91..5e3da0f 100644
--- a/yaml/xyz/openbmc_project/User/PrivilegeMapperEntry.interface.yaml
+++ b/yaml/xyz/openbmc_project/User/PrivilegeMapperEntry.interface.yaml
@@ -17,8 +17,8 @@
           One of the privilege as defined by
           xyz.openbmc_project.User.Manager.AllPrivileges.
           xyz.openbmc_project.Common.Error.InvalidArgument exception will be
-          thrown if the privilege is invalid. Additional documentation
-          on privilege is available here.
+          thrown if the privilege is invalid. Additional documentation on
+          privilege is available here.
           https://github.com/openbmc/docs/blob/master/architecture/user-management.md
 
       errors:
diff --git a/yaml/xyz/openbmc_project/User/README.md b/yaml/xyz/openbmc_project/User/README.md
index 16a0911..00de6c4 100644
--- a/yaml/xyz/openbmc_project/User/README.md
+++ b/yaml/xyz/openbmc_project/User/README.md
@@ -29,8 +29,8 @@
 
 ##### properties
 
-- MaxLoginAttemptBeforeLockout - Permissible attempt before locking out the
-  user for failed login attempts.
+- MaxLoginAttemptBeforeLockout - Permissible attempt before locking out the user
+  for failed login attempts.
 - AccountUnlockTimeout - Timeout (in seconds) to unlock the account after a
   lockout.
 - MinPasswordLength - Minimum password length, which can be set.
@@ -39,10 +39,10 @@
 
 ### Users Interface
 
-User manager daemon, will create user objects for every user existing
-in the system under object path `/xyz/openbmc_project/user/<user name>`.
-Each user object can be handled through 'org.freedesktop.DBus.ObjectManager'.
-User object will expose following properties and methods.
+User manager daemon, will create user objects for every user existing in the
+system under object path `/xyz/openbmc_project/user/<user name>`. Each user
+object can be handled through 'org.freedesktop.DBus.ObjectManager'. User object
+will expose following properties and methods.
 
 #### xyz.openbmc_project.User.Attributes interface
 
@@ -61,6 +61,6 @@
 
 ## Note
 
-This interface doesn't provide ways to set / update password. The same must
-be set / updated through pam_chauthtok() (PAM modules). This is to avoid
-sending out password through D-Bus.
+This interface doesn't provide ways to set / update password. The same must be
+set / updated through pam_chauthtok() (PAM modules). This is to avoid sending
+out password through D-Bus.
diff --git a/yaml/xyz/openbmc_project/VirtualMedia/Legacy.interface.yaml b/yaml/xyz/openbmc_project/VirtualMedia/Legacy.interface.yaml
index 611c426..6f74643 100644
--- a/yaml/xyz/openbmc_project/VirtualMedia/Legacy.interface.yaml
+++ b/yaml/xyz/openbmc_project/VirtualMedia/Legacy.interface.yaml
@@ -1,16 +1,17 @@
 description: >
-   This interface provides methods for mounting and unmounting images
-    using the legacy mode.
+    This interface provides methods for mounting and unmounting images
+     using the legacy mode.
 
 methods:
     - name: Mount
-      description: Perform an asynchronous operation of mounting to HOST on given object.
+      description:
+          Perform an asynchronous operation of mounting to HOST on given object.
       parameters:
           - name: ImageURL
             type: string
             description: >
-                Url to image. It should start with either `smb://` or
-                `https://` prefix
+                Url to image. It should start with either `smb://` or `https://`
+                prefix
           - name: ReadWrite
             type: boolean
             description: False if the image should be read-only.
@@ -28,7 +29,9 @@
           - xyz.openbmc_project.Common.Error.InternalFailure
 
     - name: Unmount
-      description: Perform an asynchronous operation of unmounting from HOST on given object.
+      description:
+          Perform an asynchronous operation of unmounting from HOST on given
+          object.
       returns:
           - name: Status
             type: boolean
@@ -39,10 +42,10 @@
 signals:
     - name: Completion
       description: >
-        Signal indicating completion of mount or unmount action.
+          Signal indicating completion of mount or unmount action.
       properties:
-        - name: Result
-          type: int32
-          description: >
-            Returns 0 for success or errno on failure after background
-            operation completes.
+          - name: Result
+            type: int32
+            description: >
+                Returns 0 for success or errno on failure after background
+                operation completes.
diff --git a/yaml/xyz/openbmc_project/VirtualMedia/MountPoint.interface.yaml b/yaml/xyz/openbmc_project/VirtualMedia/MountPoint.interface.yaml
index a9f7ffb..34e3efa 100644
--- a/yaml/xyz/openbmc_project/VirtualMedia/MountPoint.interface.yaml
+++ b/yaml/xyz/openbmc_project/VirtualMedia/MountPoint.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    Defines the object configuration like mounting mode, image paths,
-    timouts etc.
+    Defines the object configuration like mounting mode, image paths, timouts
+    etc.
 
 properties:
     - name: EndPointId
@@ -38,9 +38,9 @@
     - name: Timeout
       type: uint16
       description: >
-          Client connection timeout in seconds.
-          If VirtualMedia cannot connect successfully with served
-          image the connection is dropped after that timeout.
+          Client connection timeout in seconds. If VirtualMedia cannot connect
+          successfully with served image the connection is dropped after that
+          timeout.
       flags:
           - const
       errors:
@@ -57,8 +57,8 @@
     - name: RemainingInactivityTimeout
       type: uint16
       description: >
-          Seconds to drop connection by server, for activated endpoint,
-          0 otherwise.
+          Seconds to drop connection by server, for activated endpoint, 0
+          otherwise.
       flags:
           - const
       errors:
@@ -75,8 +75,7 @@
     - name: WriteProtected
       type: boolean
       description: >
-          Mounting mode, 'True' if the image is read only,
-          'False' otherwise.
+          Mounting mode, 'True' if the image is read only, 'False' otherwise.
       flags:
           - const
       errors:
diff --git a/yaml/xyz/openbmc_project/VirtualMedia/Proxy.interface.yaml b/yaml/xyz/openbmc_project/VirtualMedia/Proxy.interface.yaml
index 6b08c69..20b5a74 100644
--- a/yaml/xyz/openbmc_project/VirtualMedia/Proxy.interface.yaml
+++ b/yaml/xyz/openbmc_project/VirtualMedia/Proxy.interface.yaml
@@ -4,7 +4,7 @@
 methods:
     - name: Mount
       description: >
-        Perform an asynchronous operation of mounting to HOST on given object.
+          Perform an asynchronous operation of mounting to HOST on given object.
       returns:
           - name: Status
             type: boolean
@@ -14,8 +14,8 @@
 
     - name: Unmount
       description: >
-        Perform an asynchronous operation of unmount from HOST on given
-        object.
+          Perform an asynchronous operation of unmount from HOST on given
+          object.
       returns:
           - name: Status
             type: boolean
@@ -26,10 +26,10 @@
 signals:
     - name: Completion
       description: >
-        Signal indicating completion of mount or unmount action.
+          Signal indicating completion of mount or unmount action.
       properties:
-        - name: Result
-          type: int32
-          description: >
-            Returns 0 for success or errno on failure after background
-            operation completes.
+          - name: Result
+            type: int32
+            description: >
+                Returns 0 for success or errno on failure after background
+                operation completes.
diff --git a/yaml/xyz/openbmc_project/VirtualMedia/README.md b/yaml/xyz/openbmc_project/VirtualMedia/README.md
index 267e3ee..bc94417 100644
--- a/yaml/xyz/openbmc_project/VirtualMedia/README.md
+++ b/yaml/xyz/openbmc_project/VirtualMedia/README.md
@@ -1,6 +1,6 @@
 # Virtual Media
 
-All exposed objects, their paths and interfaces are described
-in [openbmc/docs/designs/VirtualMedia.md][design].
+All exposed objects, their paths and interfaces are described in
+[openbmc/docs/designs/VirtualMedia.md][design].
 
 [design]: https://github.com/openbmc/docs/blob/master/designs/VirtualMedia.md