Grammar fixes in callout README
Change-Id: I409066f2bc1232e48e5693a177d39859ba6ec84d
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
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 @@
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 @@
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.