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/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.