reformat with latest settings

Reformat with the latest settings from openbmc-build-scripts (and
copy latest config files where appropriate).  Fix a few minor
markdownlint issues.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I55205817c29dc3f182a165ddf9cd5d4e07b90063
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: >