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 <[email protected]>
Change-Id: I55205817c29dc3f182a165ddf9cd5d4e07b90063

Author: williamspatrick

.editorconfig

@@ -1,5 +1,3 @@
 default: true
 MD024:
     siblings_only: true
-MD013:
-    stern: true

.markdownlint.yaml

@@ -1,3 +1,7 @@
-tabWidth: 2
+tabWidth: 4
+printWidth: 80
+proseWrap: "always"
 overrides:
-    - { "files": "*.yaml", "options": { "tabWidth": 4 } }
+    - files: "*.md"
+      options:
+          tabWidth: 2

.prettierrc.yaml

@@ -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 @@ through the documented set of the common [requirements and expectations][].
 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 @@ Example: `meson builddir -Ddata_com_ibm=true && ninja -C builddir`
 
 ## 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

README.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 @@ unless there is a strong basis for it (usually driven by hardware or another
 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 @@ required to be represented in different dbus path hierarchies due to some
 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 @@ The primary relationship should be a verb with a Present Participle tense
 (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

requirements.md

@@ -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

yaml/com/google/gbmc/Hoth.errors.yaml

@@ -4,10 +4,10 @@ description: >
 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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 @@ methods:
 
     - 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

yaml/com/google/gbmc/Hoth.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 @@ enumerations:
       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.

yaml/com/ibm/Dump/Create.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.

yaml/com/ibm/Dump/Entry/Hardware.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.

yaml/com/ibm/Dump/Entry/Hostboot.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: >

yaml/com/ibm/Dump/Entry/Resource.interface.yaml

@@ -4,8 +4,8 @@ properties:
     - 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: >

yaml/com/ibm/Logging/Policy.interface.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