summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGunnar Mills <gmills@us.ibm.com>2017-08-07 15:33:42 -0500
committerGunnar Mills <gmills@us.ibm.com>2017-08-07 15:37:01 -0500
commit959ba0afbfaf1b6711f24456e9098068526dc998 (patch)
tree5d0bf775530ede17ef0191e43c6e5cbc3af02b66
parent43c037ba6bc848e9e95d74e425e5058e86c28b82 (diff)
downloadphosphor-dbus-interfaces-959ba0afbfaf1b6711f24456e9098068526dc998.zip
phosphor-dbus-interfaces-959ba0afbfaf1b6711f24456e9098068526dc998.tar.gz
Grammar fixes in callout README
Change-Id: I409066f2bc1232e48e5693a177d39859ba6ec84d Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
-rw-r--r--xyz/openbmc_project/Common/Callout/README.md16
1 files changed, 8 insertions, 8 deletions
diff --git a/xyz/openbmc_project/Common/Callout/README.md b/xyz/openbmc_project/Common/Callout/README.md
index 0636e81..9ba0ef7 100644
--- a/xyz/openbmc_project/Common/Callout/README.md
+++ b/xyz/openbmc_project/Common/Callout/README.md
@@ -1,17 +1,17 @@
## Introduction
A callout is typically an indication of a faulty hardware component in a system.
-In openbmc, a callout is defined as any other error, via a YAML file. An example
+In OpenBMC, a callout is defined as any other error, via a YAML file. An example
would be `xyz.openbmc_project.Error.Callout.IIC`, to indicate an IIC callout.
The goal is to have applications post callouts using hardware terminology which
is familiar to them, such as a sysfs entry, or an IIC address. It would be up to
-the openbmc error handling component to map such a callout to actual field
-replacable units (FRUs) on the system.
+the OpenBMC error handling component to map such a callout to actual field
+replaceable units (FRUs) on the system.
## Architecture and usage
-An openbmc error has associated metadata, the same is true for a callout. Such
+An OpenBMC error has associated metadata, the same is true for a callout. Such
metadata would be defined in the callout YAML interface. Here is an example (for
xyz.openbmc_project.Error.Callout.IIC) :
```
@@ -41,7 +41,7 @@ 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
+Currently, defined callout interfaces in turn inherit
`xyz.openbmc_project.Error.Callout.Device`, which has metadata common to
callouts :
```
@@ -77,12 +77,12 @@ in general :
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
+ 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
+ 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.
OpenPOWER on IntegriCloud