clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I7b90380845efee6bf6a1fe342a793d71aa9ff181
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Promote getPath() to PMBusBase

Promote the getPath() method from the PMBus class to the PMBusBase
parent class. This allows the method to be called from automated tests
using mock subclasses of PMB

Promote getPath() to PMBusBase

Promote the getPath() method from the PMBus class to the PMBusBase
parent class. This allows the method to be called from automated tests
using mock subclasses of PMBusBase.

Change-Id: I01dc6c314294e0de8919f78c79cbdc395020728f
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

psu-ng: Disable Communication, Logic, and Memory (CML) fault

Turn off CML fault logging as some of the power supplies don't support
all PMBus commands that could be sent from device driver or applic

psu-ng: Disable Communication, Logic, and Memory (CML) fault

Turn off CML fault logging as some of the power supplies don't support
all PMBus commands that could be sent from device driver or application.
The PSU sets the CML fault bit on when it receives unsupported PMBus
command.

Testing:
- Tested the change on simulation by setting the CML status bit on and
verified no error log reported.
- Tested the change on BMC System as follow and verified no error log
reported
* Powered on the chassis
* i2cget -f -y 3 0x68 0x6c w # causes information error log for
tracing purpose.

Change-Id: Ie1b52e5350a29f65bd517ad11293c6dc522ac83e
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Signed-off-by: Faisal Awada <faisal@us.ibm.com>

show more ...

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer retur

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer return true for auto features. Instead, the
expectation is to use `allowed()` which is true for both enabled and auto.

Switch all uses of `enabled` to `allowed`.

Change-Id: I37fcb391dcb215a86a60c26f7512f6ccb8312dc4
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

psu-ng: Remove previous input history code

As mentioned in a previous commit, the org.open_power D-Bus interfaces
that host the 30 second maximum and average input power values are no
longer necessa

psu-ng: Remove previous input history code

As mentioned in a previous commit, the org.open_power D-Bus interfaces
that host the 30 second maximum and average input power values are no
longer necessary, and have been replaced by a single peak input power
sensor object.

Remove all of the code that dealt with them.

For now, the code remains that toggles the GPIO to sync up the input
history values between the power supplies on boots and plugs. As the
input history is used to populate the new peak sensor, its values across
power supplies will then be using the same time intervals.

Change-Id: Ide5b40e67bf3938606a75bcc0291bc57232ce8bc
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

psu-ng: Add peak input power sensor for some PSs

Some models of the ibm-cffps power supplies support an 'input history'
command that reports 30 second maximum and average input power values.
The cod

psu-ng: Add peak input power sensor for some PSs

Some models of the ibm-cffps power supplies support an 'input history'
command that reports 30 second maximum and average input power values.
The code was currently putting those on an 'org.open_power' D-Bus
interface so that the history of those values could be captured in a
single D-Bus call.

Now that there is a real telemetry feature in Redfish that can capture
the history of a single sensor value, we can drop the custom D-Bus
interface and just use the normal Sensor.Value interface that contains
the most recent maximum value from the input history command, The sensor
name will be 'psX_input_power_peak' where X is the PS instance number.

The average input power telemetry will now just be obtained from the
psX_input_power sensor provided by phosphor-hwmon so an equivalent
sensor to the peak isn't needed here.

This commit will add support for putting the new sensor on D-Bus, and a
future one will remove the previous input history support.

Like sensors in other daemons, it will be set to not available when a PS
is removed, and not functional when it has an access problem. There
will be associations to the parent chassis and to the power supply so it
will show up in Redfish output with the other sensors.

This commit did remove one of the input history testcases, as trying to
get the right sequence of EXPECT_CALLs would get tricky when both the
old and new are running together.

Tested:
- New sensor shows up when PS is present and supports it.
- All interfaces on the object path are correct.
- Sensor value matches what org.open_power Max property had.
- Works correctly when:
- PS is missing on startup
- PS is removed
- Previously present PS is replaced.

Change-Id: Id9c33aa753c9af32880a0cc874b39c113222568f
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

meson: add necessary subprojects

Add subprojects for all the direct dependencies of the project such
that the project can be built outside of a Yocto SDK on a typical
Linux development system.

-

meson: add necessary subprojects

Add subprojects for all the direct dependencies of the project such
that the project can be built outside of a Yocto SDK on a typical
Linux development system.

- Update the .gitignore to ignore the subproject source directories.
- Update the .gitignore to ignore alternative build subdirectory
names as is typical with most projects in the openbmc organization.
- Add wrap files for direct dependencies, copied from other
repositories that already have the same dependencies.
- Modify the meson.build dependency for libgpiod so that the C++
bindings are included.
- Add many missing dependencies throughout.
- Sort all dependencies alphabetically for consistency.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I0feb6f0f175e6dba0b00a2c2b666eb0801575734

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: If66f68c96df4baf8dc07abf8729a3cb7657e932d
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Fix PSU status when BMC is in standby

Without this patch:
Plug in the power supplies in any order, the power supply that is
plugged in first will report a `PSU_KILL_Fault` in standby, but the
proble

Fix PSU status when BMC is in standby

Without this patch:
Plug in the power supplies in any order, the power supply that is
plugged in first will report a `PSU_KILL_Fault` in standby, but the
problem will be restored after the host is powered on.

With this patch:
Regardless of whether it is in standby or host powered on, this
problem disappears and it works fine.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I18e0e26a4922dd710e042048625da1cc8b08dd3c

show more ...

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ief05bd757cffb1453e058a719ee4b060861752e7

show more ...

psu-ng: PGOOD_DEGLITCH_LIMIT of five

Turns out that the (IBM) power supplies take up to around 3 seconds to
get the PGOOD# bit in STATUS_WORD set to the good (0) state after the
input power is withi

psu-ng: PGOOD_DEGLITCH_LIMIT of five

Turns out that the (IBM) power supplies take up to around 3 seconds to
get the PGOOD# bit in STATUS_WORD set to the good (0) state after the
input power is within range. Adjust the de-glitch value to avoid logging
PGOOD errors for the power supplies, as they mostly ride through the
momentary drops in the input power.

Use PGOOD_DEGLITCH_LIMIT instead of DEGLITCH_LIMIT for the pgoodFault.

Tested:
Rainier 2S4U
1. Drop outlet power for 0.5 seconds, verify no 110015F1.
2. Drop outlet power for 1 second, verify no 110015F1.
3. Drop outlet power for 1.5 seconds, verify no 110015F1.
Rainier 2S2U
1. Drop outlet power for 1 second, verify no 110015F1.
2. Drop outlet power for 5 seconds, verify 110015F0 (VIN_UV) IS logged.
3. Drop outlet power for 1.5 seconds, verify no 110015F1.
Everest (powersupply0 unplugged, powersupply3 missing)
1. Drop outlet power for 0.5 seconds, verify no 110015F1.
2. Drop outlet power for 1 second, verify no 110015F1.
3. Drop outlet power for 1.5 seconds, verify no 110015F1.
4. Drop outlet power for 3 seconds, verify 110015F0 IS logged.
5. Drop all outlet power for 5 seconds, verify 110000AC.

Change-Id: I6ba12209e6c84548fec036101ca02d857ed900f6
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Disable INPUT_HISTORY for 1400W IBM PSU

If the device driver is ibm-cpffps, read the MFR_POUT_MAX value
(max_power_out). Only enable INPUT_HISTORY data collection if it is not
the 1400W IBM

psu-ng: Disable INPUT_HISTORY for 1400W IBM PSU

If the device driver is ibm-cpffps, read the MFR_POUT_MAX value
(max_power_out). Only enable INPUT_HISTORY data collection if it is not
the 1400W IBM power supply (MSB/LSB results in 30725 for 1400). The
1400W IBM power supply appears to cause problems on the bus when
an INPUT_HISTORY PMBus command read occurs.

Tested:
Simulated Rainier 2S4U
Fake 2nd and 3rd PSUs to return 1400W value
Verify 1st and 4th collecting INPUT_HISTORY
Verify 2nd and 3rd PSUs not getting INPUT_HISTORY collected
-----
Verify real Rainier 2S4U with 1600W working as expected.

Change-Id: Ia37cea9b0273ac5926e4bc581a2ea8a4079afa23
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: INPUT_HISTORY syncHistory

Add in the function that syncs the power supply input history data
between all the installed power supplies.

Use the GPIO line name instead of gpiochip and number.

psu-ng: INPUT_HISTORY syncHistory

Add in the function that syncs the power supply input history data
between all the installed power supplies.

Use the GPIO line name instead of gpiochip and number. Use libgpiod via
helper utility. Create a toggleLowHigh() to use for synchronizing the
input history.

Add in indicator and helper functions to indicate a syncHistory is
needed if a power supply goes from missing to present.

Trace when syncHistory is called. This should be infrequent enough that
I do not think it would be a problem.

Initial testing on Rainier 2S2U did not need a lengthy delay between
lowering and raising the power-ffs-sync-history GPIO, but testing on
Rainier 2S4u required a longer delay.

Depends-On: Ib1ac2456f7f715360d089dfa4b6b379b516439ab

Change-Id: I022806155139d70fb4a42cc27eb9f279f6a3aedc
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Power supply class updates for input history

Update the meson files to include the record_manager with the
phosphor-psu-monitor application.

Since we do not want to blindly enable input his

psu-ng: Power supply class updates for input history

Update the meson files to include the record_manager with the
phosphor-psu-monitor application.

Since we do not want to blindly enable input history for all power
supplies, base the enablement of the feature off of the driver name.
Change the PowerSupply class to require the driver name be passed in,
and pass that down via the PSUManager during the configuration
determination.

Add a server manager to the PSUManager to handle the INPUT HISTORY data
that will be under /org/open_power/sensors.

The INPUT_HISTORY command is handled via a sysfs file in binary format,
so add in a readBinary() base function to allow for mock testing.

Change-Id: Iea163892d5482e6f2dacacfbfa746f605af52ed5
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Add a clearVinUVFault function

Create a clearVinUVFault() function specifically for clearing the VIN_UV
and unit is off fault bits.

Use this function when see a vinUVFault with good voltage

psu-ng: Add a clearVinUVFault function

Create a clearVinUVFault() function specifically for clearing the VIN_UV
and unit is off fault bits.

Use this function when see a vinUVFault with good voltage read back from
READ_VIN. This should clear the latched fault if the fault is no longer
active. If the fault is still active, the next read will show the fault
again.

Also call clearVinUVFault() from the clearFaults() function.

Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Change-Id: Ic26029fe64e3cd3e232c615b223cafb774bf77f9

show more ...

psu-ng: Clear faults if VIN_UV and READ_VIN good

If we see that we have set the VIN_UV fault indicator, but the READ_VIN
value is returning a non-zero voltage for input, attempt to clear the
faults.

psu-ng: Clear faults if VIN_UV and READ_VIN good

If we see that we have set the VIN_UV fault indicator, but the READ_VIN
value is returning a non-zero voltage for input, attempt to clear the
faults. This could be a latched input voltage under-voltage condition
that has now cleared.

Save off actualVoltage in PowerSupply member variable. This allows for
comparing the previous actual voltage with the new reading, to trace out
the actual voltage instead of the calculated 0/110/220 voltage.

Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Change-Id: Ibf1642a081ccf4d4a9c4202ce2536799806af017

show more ...

psu-ng: Handle health rollup based on availability

When a PSU is set to not available, create an association between the
power supply and its chassis as a way to 'roll up' the health status to
that

psu-ng: Handle health rollup based on availability

When a PSU is set to not available, create an association between the
power supply and its chassis as a way to 'roll up' the health status to
that chassis. It looks like:

<chassis>/critical
endpoints: <power supply>
<power supply>/health_rollup
endpoints: <chassis>

There is Redfish code that look at the endpoints in that chassis
association object to determine if the chassis health is OK or not.

Note that some systems, such as IBM's, have other code that will fill
in that association when it is called out in an event log, which is why
this code doesn't have to do it for every single fault.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I262dd738ebadb72aa207011941066fc282bfe4df

show more ...

psu-ng: Add Availability support to power supplies

Add support for determining if a power supply is considered 'available'
or not, and set the Available D-Bus property on the
xyz.openbmc_project.Sta

psu-ng: Add Availability support to power supplies

Add support for determining if a power supply is considered 'available'
or not, and set the Available D-Bus property on the
xyz.openbmc_project.State.Decorator.Availability interface with the
result.

A power supply is considered unavailable if any of the following are
true:
- it isn't present
- there is a input fault active
- there is a Vin UV fault active
- there is a PS KILL fault active
- there is a Iout OC fault active

The latter four faults are the faults where it can't provide good
output power, hence the PS is unavailable. These faults also don't
call out the power supply directly, so the Functional property won't
get set to false, unlike other faults.

The Available D-Bus property is then able to be used in Redfish
responses for the heath and state properties in the power supply
schema.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I349eddb8c052cf238276c832af0dde9e49f6d3f0

show more ...

psu-ng: Continue reading after readFail

Update the PMBus::read() function to allow for not creating journal
trace and elog, but default to continuing to trace and elog, the
previous behavior.

If we

psu-ng: Continue reading after readFail

Update the PMBus::read() function to allow for not creating journal
trace and elog, but default to continuing to trace and elog, the
previous behavior.

If we reach the limit of read failures that results in a communication
error log, continue to read, but stop logging failures.

If communication restores, we may be able to detect what caused the read
failure, or otherwise detect or clear new faults.

Change-Id: If59b86211ab54c31248ede78f8f117b607298923
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: De-glitch all faults

Use DEGLITCH_LIMIT to determine all the faults. If a fault bit is on, do
not consider that a fault until it is seen at least DEGLITCH_LIMIT
times. With DEGLITCH_LIMIT se

psu-ng: De-glitch all faults

Use DEGLITCH_LIMIT to determine all the faults. If a fault bit is on, do
not consider that a fault until it is seen at least DEGLITCH_LIMIT
times. With DEGLITCH_LIMIT set to 3, the monitor would need to see a
fault bit on 3 times in a row before indicating that the power supply
has that fault.

This was done earlier for the PGOOD fault detection.

Change-Id: I918c2fcdd1d90ae253ab268bd04aa7a0da0208b8
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Clear faults when voltage back in range

If the last read voltage (via READ_VIN) was below the minimum and
now it is back in a valid range (100 or 200 volt range valid), clear all
the faults

psu-ng: Clear faults when voltage back in range

If the last read voltage (via READ_VIN) was below the minimum and
now it is back in a valid range (100 or 200 volt range valid), clear all
the faults to allow for re-detection of faults and logging of new errors.

Trace if INPUT_FAULT_WARN or VIN_UV clear. We should not expect to see
that without sending a CLEAR_FAULTS command (or a power cycle).

Tested:
Rainier 2S2U real hardware.
ePDU outlet off/on allows re-detection of injected CML fault.
- input fault, vin_uv fault, pgood/off fault.
- repeat shows faults cleared, and new faults logged.
Simulator pgood fault, then low voltage followed by good voltage.
Verify simulator can re-detect faults after voltage back in range.
Simulator fake input fault/warn on, then off and other fault on.
- verified tracing input going off without clear faults sent.
Simulator fake input fault/warn on, then no faults.
- verified tracing input going off without clear faults sent.

Change-Id: Ic8022cf137978ff660680e9680f778853cbecf0d
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: gtest cleanup expectation warnings

A number of the tests are missing various EXPECT_CALL statements that
result in very verbose testlog.txt output. This becomes especially
problematic when a

psu-ng: gtest cleanup expectation warnings

A number of the tests are missing various EXPECT_CALL statements that
result in very verbose testlog.txt output. This becomes especially
problematic when a test fails, as there are pages of output to look for
to narrow down what failed where and why.

Adding in the EXPECT_CALL statements that should be there, such as
findHwmonDir, the reading of "in1_input" as part of the fault clearing,
etc.

Change-Id: I9f2f88622ad7b682461069df980a50b0b13c44a6
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Add in handling of specific MFR faults

Add in a function to determine what the various bits in statusMFR may be
indicating for a fault, based on the type of power supply (device driver
bound

psu-ng: Add in handling of specific MFR faults

Add in a function to determine what the various bits in statusMFR may be
indicating for a fault, based on the type of power supply (device driver
bound).

Add in PS_Kill, 12Vcs, and 12V CS faults for IBM power supply types.

Add in creating error logs for PS_Kill, 12Vcs, and 12V CS faults. The
12Vcs and 12V CS faults can essentially be treated the same as VOUT_UV
faults (same error type, same call out).

Tested:
Verified no PS_Kill, 12Vcs, or 12V CS fault on normal Rainier 2S4U

Simulated PS_Kill fault:
MFR fault: STATUS_WORD = 0x1840 STATUS_MFR_SPECIFIC = 0x10

Simulated 12Vcs fault:
PGOOD fault: STATUS_WORD = 0x1840, STATUS_MFR_SPECIFIC = 0x40
MFR fault: STATUS_WORD = 0x1840 STATUS_MFR_SPECIFIC = 0x40

Simulated 12V CS fault/warning:
MFR fault: STATUS_WORD = 0x1000 STATUS_MFR_SPECIFIC = 0x80

Change-Id: Ie89a58836ecec86dfa2e124eb6ab03e9dccce929
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Add DEGLITCH_LIMIT, deglitch pgoodFault

While the power supply should not arbitrarily report a PGOOD fault, and
then turn it back off, there is a perception that this is indeed
possible, a g

psu-ng: Add DEGLITCH_LIMIT, deglitch pgoodFault

While the power supply should not arbitrarily report a PGOOD fault, and
then turn it back off, there is a perception that this is indeed
possible, a glitch of some sort.

To avoid possibly logging an error for an erroneous fault reporting,
make sure the fault is reported more than once before considering it to
be a true fault (deglitch the signal).

Tested:
Real Rainier 2S2U:
Verify tracing PGOOD faults seen and cleared, no error logged
Verify PGOOD/OFF error logged when manually set ON_OFF_CONFIG & OPERATION.
Verify deglitched PGOOD again on restart service (ON_OFF_CONFIG reset).

Change-Id: I54f775004d2e363cff21ff0512bd9283408f1f72
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

psu-ng: Add in detection of fan faults

If the FANS bit in the STATUS_WORD turns on (A fan or airflow fault or
warning has occurred), set a fan fault indicator in the power supply
object. During anal

psu-ng: Add in detection of fan faults

If the FANS bit in the STATUS_WORD turns on (A fan or airflow fault or
warning has occurred), set a fan fault indicator in the power supply
object. During analysis of the power supplies, if a fan fault has
occurred, prioritize that over a temperature fault, include the
STATUS_TEMPERATURE and STATUS_FANS_1_2 command responses in the error
created. Call out the power supply with the fault.

Tested:
Verify no faults detected or logged on real hardware (Rainier 2S4U).
Simulate fan 1 fault on Rainier 2S2U, 110015FF PEL created.

Change-Id: Ifff5b4d96efe44b081a33caa01d70fdb578e57e3
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...