PSU monitoring design: Remove trailing spaces
Change-Id: Ie45f38dc430103cff085308c7f13acf9ccb146f1
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
diff --git a/designs/psu-monitoring.md b/designs/psu-monitoring.md
index 60ec659..7337427 100644
--- a/designs/psu-monitoring.md
+++ b/designs/psu-monitoring.md
@@ -60,34 +60,34 @@
maintenance (CM).
8. The power supply application should create and update average and maximum
power consumption metric interfaces for telemetry data.
-9. The power supply application must be able to detect how many power supplies
+9. The power supply application must be able to detect how many power supplies
are present in the system, what type of power supply is present (maximum output
power such as 900W, 1400W, 2200W, etc.), and what type of input power is being
supplied (AC input, DC input, input voltage, etc.).
10. The application must be able to recognize if the power supplies present
consist of a valid configuration. Certain invalid combinations may result in the
application updating properties for a Minimum Ship Level ([MSL][3]) check.
-11. The application must create error logs for invalid configurations, or for
+11. The application must create error logs for invalid configurations, or for
power supplies experiencing some other faulted condition (no input power, output
over voltage, output over current, etc.).
-12. The application would periodically communicate with the power supplies via
-the sysfs file system files updated via a PMBus device driver (currently only
-known to be created and updated by the [ibm-cffps][4] device driver). Certain
+12. The application would periodically communicate with the power supplies via
+the sysfs file system files updated via a PMBus device driver (currently only
+known to be created and updated by the [ibm-cffps][4] device driver). Certain
device driver updates may be necessary to support some power supplies or power
-supply features. Any power supply that communicates using the PMBus
+supply features. Any power supply that communicates using the PMBus
specification should be able to be supported, some manufacturing specific code
-paths may be required for commands in the "User Data and Configuration"
+paths may be required for commands in the "User Data and Configuration"
(USER_DATA_00 through USER_DATA_15) and the "Manufacturer Specific Commands"
(MFR_SPECIFIC_00 through MFR_SPECIFIC_45), as well as bit definitions for
STATUS_MFR_SPECIFIC and any other "MFR" command.
## Proposed Design
-The proposal is to create a single new power supply application in the OpenBMC
+The proposal is to create a single new power supply application in the OpenBMC
[phosphor-power][6] repository. The application would be written in C++17.
Upon startup, the power supply application would be passed a parameter
consisting of the location of some kind of configuration file, some JSON format
-file. This file would contain information such as the D-Bus object name(s),
+file. This file would contain information such as the D-Bus object name(s),
possible power supply types, possible system types that the various power
supplies are valid to be used in, I2C/PMBus file location data, read retries,
deglitch counts, etc.