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