8c232456 | 05-May-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Complete PMBusReadSensorAction class
Complete implementation of the PMBusReadSensorAction class. Publish the sensor value on D-Bus using the Sensors service.
Update gtests for this cla
regulators: Complete PMBusReadSensorAction class
Complete implementation of the PMBusReadSensorAction class. Publish the sensor value on D-Bus using the Sensors service.
Update gtests for this class to expect calls to the Sensors service. Fix some constructor parameter combinations that did not make sense, such as linear_16 format for non-voltage sensors.
Also refactor the TestSDBusError exception class into a separate file. This allows it to be shared by multiple test cases. This class is a concrete implementation of the abstract sdbusplus::exception_t class used for D-Bus errors.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I5a77616b2ae5b17224c296aeee88019512649589
show more ...
|
6d5470d0 | 30-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Update sensor monitoring documentation
Update the documentation for the pmbus_read_sensor action: * Improve description of the D-Bus sensor object paths. * Document how peak/valley senso
regulators: Update sensor monitoring documentation
Update the documentation for the pmbus_read_sensor action: * Improve description of the D-Bus sensor object paths. * Document how peak/valley sensors are set and when they are cleared. * Use the simpler term 'Sensor Type' instead of 'Sensor Value Type' to match the same change in the code.
Update the internal design documentation: * Update list of interfaces implemented by D-Bus sensors. * Describe what the D-Bus Value, Functional, and Available properties will be set to in various scenarios. * Add brief description of Services class hierarchy.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I895bf980300a81bcfbaef975edd41aa7d1d81331
show more ...
|
cb3f6a63 | 30-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add inventory path to Chassis class
A previous commit added the "inventory_path" property to the "chassis" object in the JSON configuration file.
This commit adds that new property to t
regulators: Add inventory path to Chassis class
A previous commit added the "inventory_path" property to the "chassis" object in the JSON configuration file.
This commit adds that new property to the C++ implementation: * Chassis class and associated gtests * JSON configuration file parser functions and associated gtests * Other gtests affected by the change to the Chassis constructor
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I7406f874263d01e6faa2b8c333cb1baf915cf2ac
show more ...
|
ecbeeea7 | 29-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add inventory_path to JSON chassis obj
Add the property "inventory_path" to the "chassis" object in the JSON configuration file.
This property will be used to create the required D-Bus
regulators: Add inventory_path to JSON chassis obj
Add the property "inventory_path" to the "chassis" object in the JSON configuration file.
This property will be used to create the required D-Bus association between a voltage regulator sensor and the chassis that contains it. This association is required by the Redfish support.
Long term, this new property will be required. That is how it is documented in the updated version of chassis.md.
However, it will be temporarily optional in the JSON schema and the C++ configuration file parser. This temporary measure will be removed once all known JSON configuration files have been updated to specify the new property.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I45f5e8ec86be7672a33099c94c35328862ffe11b
show more ...
|
2f9e14f6 | 29-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Convert to new SensorType enumeration
There are several types of voltage regulator sensors, such as vout, iout, and temperature.
The sensor types were previously defined by the enumerat
regulators: Convert to new SensorType enumeration
There are several types of voltage regulator sensors, such as vout, iout, and temperature.
The sensor types were previously defined by the enumeration pmbus_utils::SensorValueType. This enumeration should not have been placed in the pmbus_utils namespace because it is not specific to PMBus.
A new enumeration with the simpler name SensorType was created in sensors.hpp in a previous commit.
Remove the old enumeration from pmbus_utils. Convert affected files to use the new enumeration.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I4136b392b104edd3eee41ec29c779ad084c7c4de
show more ...
|
5135df63 | 28-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Remove SensorReading data type
Remove the SensorReading data type defined in pmbus_utils.hpp and used in several locations. This data type is no longer needed.
The original design was
regulators: Remove SensorReading data type
Remove the SensorReading data type defined in pmbus_utils.hpp and used in several locations. This data type is no longer needed.
The original design was for sensor readings to be accumulated in the ActionEnvironment while the PMBus actions were being executed. Then all the sensor readings for a voltage rail would be published on D-Bus at the same time.
The current design is for sensor readings to be immediately published on D-Bus as they are read using the new Sensors service. They no longer need to be accumulated in the ActionEnvironment.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Ib61a07b5a7f58be3e2dae540ffb4d5128636b7c0
show more ...
|
8279a11d | 27-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add Sensors to Services hierarchy
Add the Sensors service to the Services hierarchy: * Add Sensors class to Services * Add DBusSensors class to BMCServices * Add MockSensors class to Moc
regulators: Add Sensors to Services hierarchy
Add the Sensors service to the Services hierarchy: * Add Sensors class to Services * Add DBusSensors class to BMCServices * Add MockSensors class to MockServices
Tested: * DBusSensors * Acquired DBusSensors reference from BMCServices object * Successfully executed a sensor monitoring cycle using the reference * MockSensors * Acquired MockSensors reference from MockServices object
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Ida06baed47c0d8711ab3acba71f67df3646ea122
show more ...
|
c9c69518 | 27-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Remove Services& from Sensors methods
Remove the Services& parameter from the Sensors methods. This parameter introduces a circular include dependency, and the parameter was only being
regulators: Remove Services& from Sensors methods
Remove the Services& parameter from the Sensors methods. This parameter introduces a circular include dependency, and the parameter was only being lightly used in two Sensors methods.
Tested: * Verified that all DBusSensors methods work as expected.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I3b2c3ec0bec7ea51b24100531f3314e9f87cebee
show more ...
|
03a25f1b | 24-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Create DBusSensors class
Create the DBusSensors class. This is a concrete implementation of the Sensors abstract base class. This class manages all the voltage regulator sensors in the
regulators: Create DBusSensors class
Create the DBusSensors class. This is a concrete implementation of the Sensors abstract base class. This class manages all the voltage regulator sensors in the system.
Also add a lastUpdateTime data member to the DBusSensor class. This data member is set whenever the sensor is updated. This enables the DBusSensors class to detect sensors that were not updated during the current monitoring cycle.
Sensors that were not updated during the current monitoring cycle are deleted. These sensors were likely produced by a hardware device that was removed or replaced with a different version.
Tested: * Ran through entire monitoring cycle multiple times * Tested that lastUpdateTime is set correctly when a sensor is modified * Sensor value updated * Sensor disabled * Sensor put in error state * Tested where new sensor was created * Tested where existing sensor was updated * Tested where all sensors disabled * Tested where all sensors for a rail put in error state * Tested where sensors removed due to not being updated this cycle * Tested where D-Bus exception occurs when trying to create a sensor * See complete test plan at https://gist.github.com/smccarney/69efb813c0005571aee687f67e489278
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Ib1fc399f100188cc048ac3ab5892117b74f844e9
show more ...
|
837ece7c | 22-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Create DBusSensor class
Create the DBusSensor class that represents a voltage regulator sensor on D-Bus.
Each voltage rail in the system may provide multiple types of sensor data, such
regulators: Create DBusSensor class
Create the DBusSensor class that represents a voltage regulator sensor on D-Bus.
Each voltage rail in the system may provide multiple types of sensor data, such as temperature, output voltage, and output current. A DBusSensor tracks one of these data types for a voltage rail.
Class supports the following sensor operations: * Create sensor * Set sensor value * Disable sensor (when system is powered off) * Set sensor to error state (when unable to read value due to I2C error) * Delete sensor
Note: A different class will implement the ObjectManager interface for all voltage regulator sensors. That will be in a future commit.
Tested: * Created a sensor of each supported type (vout, iout, etc.) * Set the value of a sensor * Tested update policies: hysteresis, highest, lowest * Disabled a sensor * Set a sensor to the error state * Verified all D-Bus signals emitted * InterfacesAdded signal emitted with all info when sensor created * PropertiesChanged signal emitted when sensor properties change * InterfacesRemoved signal emitted when sensor deleted * See https://gist.github.com/smccarney/5ae989da1977162ae1a21c208d5302fc for complete test plan.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I655277e6bf0a31a8778a54e87d5864f9951b045e
show more ...
|
0a450197 | 12-Apr-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add Sensors service
Define the abstract base class Sensors. This class represents a service that maintains a list of voltage regulator sensors.
This service makes the voltage regulator
regulators: Add Sensors service
Define the abstract base class Sensors. This class represents a service that maintains a list of voltage regulator sensors.
This service makes the voltage regulator sensors available to other BMC applications. For example, the Redfish support obtains sensor data from this service.
Each voltage rail in the system may provide multiple types of sensor data, such as temperature, output voltage, and output current. A sensor tracks one of these data types for a voltage rail.
Also define a concrete subclass MockSensors used for test cases.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I0b1c28161bad899c6dd75f87b7ee8e891c8781af
show more ...
|
8acaf547 | 30-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Wait for compatible system types
There are two options for naming the JSON configuration file: 1. Default name 2. Name based on compatible system types provided by EntityManager
If opti
regulators: Wait for compatible system types
There are two options for naming the JSON configuration file: 1. Default name 2. Name based on compatible system types provided by EntityManager
If option #2 is used, there is no guarantee that EntityManager will have published the compatible systems types on D-Bus before a boot is attempted. This is not common, but the problem has occurred.
When the boot begins, the regulators application configures the voltage regulators. If the config file has not been found and loaded, this configuration cannot occur.
This commit enhances the regulators application to wait for EntityManager to publish the compatible systems information during the boot so that the regulators can be configured.
A maximum wait time is enforced to prevent the boot from being blocked indefinitely. If this maximum wait time is reached, a critical error is logged indicating that the voltage regulators could not be configured.
Tested: * System types available before boot * Have to wait for system types during boot * System types found within 5 minutes * System types not found within 5 minutes * For complete test plan details, see https://gist.github.com/smccarney/b059a5f4da1a9138af770217cbafaea3
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I700a376b94603f36defd1fe266c0a2d7e2a9d30b
show more ...
|
81a2f90b | 23-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Create error log entries
Create error log entries when the following regulator operations fail: * configuration * presence detection * sensor monitoring * closing I2C devices
Use the re
regulators: Create error log entries
Create error log entries when the following regulator operations fail: * configuration * presence detection * sensor monitoring * closing I2C devices
Use the recently created error_logging_utils namespace to create error logs based on caught exceptions.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I25824ecfdaa270abbce92b52bdea0602271d926d
show more ...
|
aaa4fddb | 18-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Create error_logging_utils
Create the error_logging_utils namespace for utility functions that make it easier to log errors. Create two initial functions within the namespace.
The firs
regulators: Create error_logging_utils
Create the error_logging_utils namespace for utility functions that make it easier to log errors. Create two initial functions within the namespace.
The first function logs an error based on an exception. The exception may have one or more nested inner exceptions. The function finds the highest priority exception and logs a corresponding error.
The second function provides the same basic behavior as the first, but it adds an ErrorHistory parameter. An error will only be logged if it was not previously logged. The ErrorHistory object is used to determine whether an error has been previously logged. This avoids logging duplicate errors if a regulator operation is occurring repeatedly, such as reading sensor values.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: If246cde9a0f60c5bba34ae4a0d68fb511c0024fc
show more ...
|
0414f0ec | 17-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Enhance exception utilities
Implement function that finds all exceptions within a nested exception and returns them in a vector.
This function makes it easier to handle nested exception
regulators: Enhance exception utilities
Implement function that finds all exceptions within a nested exception and returns them in a vector.
This function makes it easier to handle nested exceptions. You can iterate over them in a simple loop instead of writing recursive code.
The new function exists in the exception_utils namespace.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I36b135584ec6024625a572bbe0522643406245cd
show more ...
|
2f1b7ba6 | 17-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Enhance ErrorHistory
Enhance the ErrorHistory class to track all error types logged by the regulators application. Previously the ErrorHistory class only tracked a single error type.
T
regulators: Enhance ErrorHistory
Enhance the ErrorHistory class to track all error types logged by the regulators application. Previously the ErrorHistory class only tracked a single error type.
This class is used to avoid logging duplicate errors. Some regulator operations occur repeatedly, such as reading sensors/telemetry.
The first time an error occurs, it should be logged. But if the same error occurs again on the same regulator, it should not be logged again.
Error history will be cleared at the beginning of each boot.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Iba2225e635eb9b7a8fe633f117346c1fb5c9884b
show more ...
|
36fc261b | 16-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add info to WriteVerificationError
Add more information to the WriteVerificationError exception: * Unique ID of the device where the error occurred * Inventory path of the device where t
regulators: Add info to WriteVerificationError
Add more information to the WriteVerificationError exception: * Unique ID of the device where the error occurred * Inventory path of the device where the error occurred
This information is required in order to create an error log entry based on the exception.
Modify files that currently use WriteVerificationError to adapt to the new constructor and get methods.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I1e7fb321efe86b54dcd32a9752ec7465be90ad48
show more ...
|
5b819f44 | 16-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add more info to PMBusError
Add more information to the PMBusError exception: * Unique ID of the device where the error occurred * Inventory path of the device where the error occurred
regulators: Add more info to PMBusError
Add more information to the PMBusError exception: * Unique ID of the device where the error occurred * Inventory path of the device where the error occurred
This information is required in order to create an error log entry based on the exception.
Modify files that currently use PMBusError to adapt to the new constructor and get methods.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Iadae82468df3ee46bdd5445f130c43502d454e96
show more ...
|
0635df21 | 02-Mar-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Temporarily allow boot w/missing cfg
Temporarily allow the boot to continue if the regulators JSON configuration file is missing or invalid.
The EntityManager application publishes the
regulators: Temporarily allow boot w/missing cfg
Temporarily allow the boot to continue if the regulators JSON configuration file is missing or invalid.
The EntityManager application publishes the system type information on D-Bus using a "compatible" interface. This information is used to find the correct regulator config file.
A problem was discovered where a boot can be attempted before EntityManager has published the system type information. This was resulting in the regulators application stopping the boot since it didn't have a valid configuration file yet.
The long-term direction is to enhance the regulators application to wait for the EntityManager information during the boot if necessary.
However, a short-term fix is required right now. The current behavior of logging a critical error and stopping the boot is being temporarily commented out.
Tested: * Verified that boot is not longer stopped if config file is missing/invalid.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I2e60f9892d3f72143a0e3c28bce19c55b4659f47
show more ...
|
415094c1 | 15-Feb-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Stop boot if cfg file not found/valid
Stop the boot during a BMC chassison/poweron if the regulators JSON configuration file cannot be found or is invalid.
During the boot, the regulato
regulators: Stop boot if cfg file not found/valid
Stop the boot during a BMC chassison/poweron if the regulators JSON configuration file cannot be found or is invalid.
During the boot, the regulators application configures the voltage regulators in the system. One of the most important voltage regulator settings that can be changed is the output voltage.
The rules on how to configure the voltage regulators are defined in the JSON config file. If this file cannot be found or is invalid, the voltage regulators cannot be configured.
That would mean that the voltage regulators would be turned on during the boot using their hardware default settings. It is common for some of the hardware defaults to be incorrect, occasionally by a significant amount.
If the hardware defaults are significantly off, it is possible that hardware damage could occur. For example, if the output voltage is too high, downstream hardware components could be damaged.
For this reason, the boot needs to be stopped. A critical error is logged, and the executable run by the systemd service file exits with a non-zero return code indicating failure.
Note that this behavior will only occur if the phosphor-regulators application is being used. The application must be explicitly enabled using a meson build option.
Tested: * Verified that boot is stopped if JSON config file not found/valid * Verified critical error logged * Verified regsctl exits with non-zero value causing config service to fail * Verified that boot continues if JSON config file valid * Tested with both 'obmcutil chassison' and 'obmcutil poweron' * For complete test plan see https://gist.github.com/smccarney/8801cad1fe1c4ae8913e57d9474bfaac
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I211f19cd9b98daea86645611633f8943c44b0f75
show more ...
|
a528a281 | 15-Feb-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Enhance SystemdJournal::getMessages()
Enhance the SystemdJournal::getMessages() method that obtains systemd journal entries with a specified field value: * Handle journal entries that do
regulators: Enhance SystemdJournal::getMessages()
Enhance the SystemdJournal::getMessages() method that obtains systemd journal entries with a specified field value: * Handle journal entries that do not have expected fields. All journal fields are optional, so if a field is missing this is not an error condition. * Use built-in filtering support provided by the systemd journal API. This will likely provide better performance. * Use C++ std::string methods to perform field data parsing. * Add short sleep before acquiring journal messages. Otherwise recently added messages are sometimes not available.
Tested: * Tested where journal entry is missing expected fields. * Tested that built-in filtering support results in the desired set of journal entries. * Tested field data parsing. Tested where value has expected format and when it does not. * Verified all journal entries, including the most recently added ones, are obtained. * Tested error handling when each sd_journal_*() function fails. * For complete test plan, see https://gist.github.com/smccarney/bd4e546a76ee05e4df939eb69e23daee
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I066492edc05691b240d768c5b99cfa6f07d83ddf
show more ...
|
de0fd44f | 10-Feb-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Improve docs for compare_vpd
Improve the documentation for the compare_vpd JSON action: * Explain what "VPD" is * Provide an example use case
Signed-off-by: Shawn McCarney <shawnmm@us.i
regulators: Improve docs for compare_vpd
Improve the documentation for the compare_vpd JSON action: * Explain what "VPD" is * Provide an example use case
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Iafb3e47293c678a2ea6923438253e2c60f35e8e2
show more ...
|
45907cc7 | 05-Feb-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Complete compare_vpd action
Complete implementation of the compare_vpd action in the JSON configuration file. For more information about this action see https://github.com/openbmc/phosp
regulators: Complete compare_vpd action
Complete implementation of the compare_vpd action in the JSON configuration file. For more information about this action see https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/compare_vpd.md
Implement the execute() method of the CompareVPDAction class. Obtain the actual VPD keyword value from the VPD service and compare it with the expected value.
Also improve doxygen for the execute() method of the ComparePresenceAction class.
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Ieb93806245babe6782fef95209bed8eed5b32578
show more ...
|
4e0402cb | 05-Feb-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Add VPD service
The regulators application needs to obtain VPD (Vital Product Data) keyword values.
Sometimes regulator configuration and monitoring varies depending on hardware type or
regulators: Add VPD service
The regulators application needs to obtain VPD (Vital Product Data) keyword values.
Sometimes regulator configuration and monitoring varies depending on hardware type or version. VPD keyword values can provide this information about the hardware.
Add a new class to obtain hardware VPD from the D-Bus xyz.openbmc_project.Inventory.Decorator.Asset interface.
Also define an abstract base class and a mock implementation to enable use of gmock in test cases related to VPD.
Tested: * Verified VPD values were successfully obtained from D-Bus. * Verified VPD values were cached. * Tested where object path was invalid. * Tested where keyword was invalid. * Verified cached VPD values were cleared when machine powered on. * For the complete test plan, see https://gist.github.com/smccarney/519a54353361e28b1d25f5783c15f471
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: Id08e8bca8db6421d46669c495e8a9432e45a1fd6
show more ...
|
3cd2b407 | 30-Jan-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Handle expected D-Bus exceptions
When hardware is not present, it can appear multiple ways on D-Bus: * Object path does not exist * Object path exists, but Inventory.Item interface not i
regulators: Handle expected D-Bus exceptions
When hardware is not present, it can appear multiple ways on D-Bus: * Object path does not exist * Object path exists, but Inventory.Item interface not implemented * Inventory.Item interface implemented with Present value of false
The first two cases result in a D-Bus exception being thrown when trying to obtain the value of the Present property.
Enhance the DBusPresenceService class to catch these exceptions and treat them as a false Presence value.
Tested: * Tested where hardware present * Tested where hardware not present * Object path and interface/property exist * Object path exists * Object path does not exist * For full test plan, see https://gist.github.com/smccarney/d3d7384700abcc5abf436e2b859d98e5
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I543a4c16984dea3657b8024dedd1060dda4319e2
show more ...
|