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