History log of /openbmc/phosphor-power/phosphor-regulators/ (Results 76 – 100 of 301)
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
8c23245605-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 ...

6d5470d030-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 ...

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

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

2f9e14f629-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 ...

5135df6328-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 ...

8279a11d27-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 ...

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

03a25f1b24-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 ...

837ece7c22-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 ...

0a45019712-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 ...

8acaf54730-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 ...

81a2f90b23-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 ...

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

0414f0ec17-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 ...

2f1b7ba617-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 ...

36fc261b16-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 ...

5b819f4416-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 ...

0635df2102-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 ...

415094c115-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 ...

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

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

45907cc705-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 ...

4e0402cb05-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 ...

3cd2b40730-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 ...

12345678910>>...13