History log of /openbmc/phosphor-fan-presence/monitor/json_parser.cpp (Results 1 – 25 of 26)
Revision Date Author Comments
# 4fa67aa1 03-Feb-2025 Patrick Williams <patrick@stwcx.xyz>

clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

Change-Id: If152304b21dd2daaa2f79255a4f98218615efb05
Signed-off-by: Patrick Williams <p

clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

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

show more ...


# dfddd648 16-Aug-2024 Patrick Williams <patrick@stwcx.xyz>

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: Ica590f8613f1fb89ab1ca676ac51c1cc7e38d67f
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...


# 4c62fc77 14-Feb-2024 Matt Spinler <spinler@us.ibm.com>

monitor: Add fan_frus_with_nonfunc_rotors cause

Create a new power off rule to power off when a specific number of fan
FRUs have nonfunctional rotors. With this rule failing rotors can be
treated d

monitor: Add fan_frus_with_nonfunc_rotors cause

Create a new power off rule to power off when a specific number of fan
FRUs have nonfunctional rotors. With this rule failing rotors can be
treated differently when they are spread across fans FRUS than when they
are within the same fan FRU.

For example, if both rotors of a 2 rotor fan fail the system can stay
up, but if 2 rotors in separate fans fail then the system could be made
to power off.

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

show more ...


# 5e15c3ba 20-Oct-2023 Patrick Williams <patrick@stwcx.xyz>

clang-format: copy latest and re-format

clang-format-17 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-17 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: I3e9e6350864ac267819a4b8d670bef7d3746976e
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...


# fbf4703f 17-Jul-2023 Patrick Williams <patrick@stwcx.xyz>

use std::format instead of fmt::format

The std::format is sufficient for the uses in this repository except
for in one file (override_fan_target.cpp, since P2286 isn't supported
by GCC yet). Switch

use std::format instead of fmt::format

The std::format is sufficient for the uses in this repository except
for in one file (override_fan_target.cpp, since P2286 isn't supported
by GCC yet). Switch to std::format whenever possible.

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

show more ...


# f724c16b 10-May-2023 Matt Spinler <spinler@us.ibm.com>

monitor: Support a separate upper deviation

Add an optional 'upper_deviation' field to the fan monitor config and if
supplied it will be used for the allowed deviation when the fan value is
over the

monitor: Support a separate upper deviation

Add an optional 'upper_deviation' field to the fan monitor config and if
supplied it will be used for the allowed deviation when the fan value is
over the target. If not supplied it will work as today and the single
deviation value will be used for both the upper and lower bounds.

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

show more ...


# 18fb12b8 09-May-2023 Matt Spinler <spinler@us.ibm.com>

monitor: Change Fan/Sensor def tuples to structs

The tuples were big and hard to read/use. Change them to structs so the
members are always named.

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

monitor: Change Fan/Sensor def tuples to structs

The tuples were big and hard to read/use. Change them to structs so the
members are always named.

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

show more ...


# 61b73296 10-May-2023 Patrick Williams <patrick@stwcx.xyz>

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: I152f141a5e8343b92b5ce81d3ca16eec77b5606b
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...


# 27cc39f1 20-Sep-2022 Chau Ly <chaul@amperecomputing.com>

monitor: Support target_path option in configuration file

The target path containing the interface
xyz.openbmc_project.control.FanPwm or
xyz.openbmc_project.control.FanSpeed can be different between

monitor: Support target_path option in configuration file

The target path containing the interface
xyz.openbmc_project.control.FanPwm or
xyz.openbmc_project.control.FanSpeed can be different between
phosphor-hwmon and dbus-sensor.

In phosphor-hwmon, it is "/xyz/openbmc_project/sensors/fan_tach/".
In dbus-sensor, it is "/xyz/openbmc_project/control/fanpwm/".

This commit supports making this path configurable via "target_path"
as a full object path.
By default, it is the same as the fan tach object path.

Signed-off-by: Chau Ly <chaul@amperecomputing.com>
Change-Id: I2658a462dd49a98ad77d684f2927e6ccae21cd15

show more ...


# 808d7fe8 13-Jun-2022 Mike Capps <mikepcapps@gmail.com>

meson support: remove code warnings 1

This commit contains code changes necessary to support the increased
warning level from Meson builds. Most changes are for unused variables.

To keep the review

meson support: remove code warnings 1

This commit contains code changes necessary to support the increased
warning level from Meson builds. Most changes are for unused variables.

To keep the review size manageable, this commit contains only monitor
and presence changes (and top-level json_config.hpp).

Signed-off-by: Mike Capps <mikepcapps@gmail.com>
Change-Id: I7280b512c54e8d5aeba3300764a239f3dcbab14d

show more ...


# 78182482 23-Jun-2022 Mike Capps <mikepcapps@gmail.com>

monitor: fix undefined behavior

A recent static analysis check revealed a use-after-free condition in
json_parser.cpp. This fixes the undefined behavior.

Signed-off-by: Mike Capps <mikepcapps@gmail

monitor: fix undefined behavior

A recent static analysis check revealed a use-after-free condition in
json_parser.cpp. This fixes the undefined behavior.

Signed-off-by: Mike Capps <mikepcapps@gmail.com>
Change-Id: I62b82b4982386d14e6ee7225b3ab6f3628e2a416

show more ...


# 8a8aa442 19-Nov-2021 Matthew Barth <msbarth@us.ibm.com>

monitor: Add ignoring feedback sensors above allowed max

There may be situations where fan rotor feedback speeds above the
allowed range could be ignored, essentially ignoring any overspeed
detectio

monitor: Add ignoring feedback sensors above allowed max

There may be situations where fan rotor feedback speeds above the
allowed range could be ignored, essentially ignoring any overspeed
detections. This adds an optional `ignore_above_max` attribute to the
fan sensors that can be added, set to 'true', to ignore marking that fan
sensor as nonfunctional when its above the allowed max. Without this
attribute, the fan sensor must remain within the allowed min/max range
to be deemed functional. This is the default behavior.

Change-Id: I4876b4c1963a8a1becd55732ca19496f5df6b003
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...


# a3584bd2 29-Mar-2021 Matt Spinler <spinler@us.ibm.com>

monitor: Support set_func_on_present

The set_func_on_present JSON field determines if the fan FRU and rotors
should be set to functional immediately when a fan plug is detected. It
is optional in t

monitor: Support set_func_on_present

The set_func_on_present JSON field determines if the fan FRU and rotors
should be set to functional immediately when a fan plug is detected. It
is optional in the JSON file, and defaults to false if not present.

When this is false, a fan will have to spin back up again before it is
set back to functional, meaning that if the new fan is faulty and never
spins up there may not be another error created. If a faulty fan is
plugged when this setting is true, then an error will be created as soon
as the configuration allows.

In some system configurations, the functional status on the fan FRU may
also control LED status, so setting the FRU to functional on the plug
would also turn off a fault LED, which is a desired behavior in the
systems that do this.

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

show more ...


# 623635c6 29-Mar-2021 Matt Spinler <spinler@us.ibm.com>

monitor: Create count timer

When the method for monitoring fan speeds is set to 'count', which is
when an up/down counter is used determine when a fan should be
considered faulted/nonfunctional, the

monitor: Create count timer

When the method for monitoring fan speeds is set to 'count', which is
when an up/down counter is used determine when a fan should be
considered faulted/nonfunctional, there needs to be some interval at
which the speeds are checked and the count is changed if necessary.
Otherwise, if the checks just happened in the tach changed callback as
they do today, then a fan with a non-changing rotor speed would never
trigger a check.

This commit creates a new timer in the Fan class that is constantly
running when the monitor is active if any of the fan's sensors use this
mode. In the expiration function, the sensors' tach targets will be
compared to their input values and the error count will be
incremented/decremented as was previously happening in the tach changed
callback.

The interval to use is read from a new 'count_interval' property in the
JSON, which defaults to 1 if not present and the count method is
enabled.

The timer is started in the startMonitor function, and stopped when a
power off is detected.

This commit also added some DEBUG journal traces when the counter on a
sensor changes values to help with debugging the new code, and so it can
be enabled on a system if desired by enabling debug level tracing.

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

show more ...


# 4c4de263 17-Feb-2021 Matthew Barth <msbarth@us.ibm.com>

monitor: Deviation attribute details(docs) & enforce range

The `deviation` attribute contains the +/- percentage allowed for the
sensors to deviate from any requested target.

Also enforcing the `de

monitor: Deviation attribute details(docs) & enforce range

The `deviation` attribute contains the +/- percentage allowed for the
sensors to deviate from any requested target.

Also enforcing the `deviation` value provided in the JSON configuration
is between 0 and 100.

Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
Change-Id: I3064e9b407c2edec7fb0fd36a2d1cd3f53d3e397

show more ...


# 69f2f48e 20-Oct-2020 Jolie Ku <jolie_ku@wistron.com>

monitor: Add up/down count fault detection

Create an up/down count fault determination algorithm that
could be used in place of the current timer based outOfRange()
function.
The up/down count is a

monitor: Add up/down count fault detection

Create an up/down count fault determination algorithm that
could be used in place of the current timer based outOfRange()
function.
The up/down count is a different method for determining when
a fan is faulted by counting up each iteration a rotor is
out of spec and removing those counts when the rotor
returns within spec.

Tested:
1. Remove a fan and run Mihawk, the counter add 1 when sensor
is out of spec, and replaced the fan back before hit the
threshold, the counter decrement back to 0.
2. Remove a fan, counter add 1 and mark the removed fan as
nonfunctional when counter reaches the threshold, and
Replaced the fan back, counter will decrement back to 0
and fan back to functional.

Change-Id: I632dd2c7553b007beb7ae6bb694a590d2cfc2a1c
Signed-off-by: Jolie Ku <jolie_ku@wistron.com>
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...


# ac1efc11 27-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Re-log fan error on a power off

In the case where a power off rule runs to completion and powers off the
system due to either missing or faulted fans, at the point of power off
re-post the

monitor: Re-log fan error on a power off

In the case where a power off rule runs to completion and powers off the
system due to either missing or faulted fans, at the point of power off
re-post the event log for the previous fan error.

This way, there can be an error associated with the power off, because
depending on the power off rule delays the original error could have
happened several minutes or more in the past.

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

show more ...


# 27f6b686 27-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Event logs for missing fans

This commit adds the code to create event logs calling out the fan when
it has been missing for a certain amount of time.

This is basically identical to the fun

monitor: Event logs for missing fans

This commit adds the code to create event logs calling out the fan when
it has been missing for a certain amount of time.

This is basically identical to the functionality that the fan presence
application in this repo provides, but with it in this application all
fan errors are created from the same place. This will become important
when there is a power off due to a fan missing and the error for that
needs to be re-committed at power off time so it can be shown as the
cause of the power off.

The functionality is configured in the JSON:

fan_missing_error_delay:
Defines the number of seconds a fan must be missing with power on before
an error will be created. If this isn't present in the JSON, then
errors will not be created at all.

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

show more ...


# f13b42e2 26-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Event logs for nonfunc fan sensors

This commit adds the code to create event logs calling out the fan when
fan sensors have been nonfunctional for a certain amount of time.

This functional

monitor: Event logs for nonfunc fan sensors

This commit adds the code to create event logs calling out the fan when
fan sensors have been nonfunctional for a certain amount of time.

This functionality is configured in the JSON, and will only be enabled
if the 'fault_handling' JSON section is present. It uses the following
new JSON parameters:

nonfunc_rotor_error_delay (per fan):
This says how many seconds a fan sensor must be nonfunctional before the
event log will be created.

num_nonfunc_rotors_before_error (under fault_handling):
This specifies how many nonfunctional fan rotors there must be at the
same time before an event log with an error severity is created for the
rotor. When there are fewer than this many nonfunctional rotors, then
event logs with an informational severity will be created.

A new FanError class is used to create the event logs. It adds the
Logger output as FFDC, plus any JSON data that is passed in with the
commit() API. It uses CALLOUT_INVENTORY_PATH in the AdditionalData
property to specify the faulted fan FRU.

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

show more ...


# ae1f8efe 14-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Allowing ignoring fan FRU func status

Make the 'num_sensors_nonfunc_for_fan_nonfunc' JSON entry be optional,
and if it isn't present then don't set the parent fan FRU inventory
object funct

monitor: Allowing ignoring fan FRU func status

Make the 'num_sensors_nonfunc_for_fan_nonfunc' JSON entry be optional,
and if it isn't present then don't set the parent fan FRU inventory
object functional state when the tach sensor functional states change.

This is necessary because on some systems some other entity will be
managing the FRU level functional state.

This also adds a trace when the tach sensor functional state changes,
since if the FRU functional state updating is turned off then the
existing traces won't appear.

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

show more ...


# f06ab07c 14-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Create PowerOffRules class

This class contains a PowerOffCause and a PowerOffAction. It provides a
check() method that takes the FanHealth map which it then checks against
the cause. If t

monitor: Create PowerOffRules class

This class contains a PowerOffCause and a PowerOffAction. It provides a
check() method that takes the FanHealth map which it then checks against
the cause. If the cause is satisfied, it then starts the power off
action. It provides a cancel method that will force cancel a running
action in the case that the object owner detects a system power off and
so doesn't need to run this power off anymore.

The class's configuration data is read from the JSON config file.

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

show more ...


# b0412d07 12-Oct-2020 Matt Spinler <spinler@us.ibm.com>

monitor: Use only init mode when using JSON

Fan monitor is currently split into 2 modes - 'init' which is used
right after a power on, and 'monitor', which is used later after the
fans-ready target

monitor: Use only init mode when using JSON

Fan monitor is currently split into 2 modes - 'init' which is used
right after a power on, and 'monitor', which is used later after the
fans-ready target is started. Normally, the 'init' mode just sets the
fans to functional and then exits, and the real monitoring work is done
in the 'monitor' mode.

In the future this application will need to be able to check for fan
problems as soon as it starts up after power on so that it can handle
shutting down due to missing fans. To prepare for this, move all
functionality into the init mode, and just exit immediately when called
to run in the monitor mode. Only do this when compiled to use the JSON
configuration, as this is new and I don't want to change how the
existing YAML setups work.

This also creates a new 'monitor_start_delay' entry in the JSON to say
how long to wait after startup before actually doing any sensor
monitoring, which then gives the same behavior as how the monitor mode
would delay by waiting for the fan control ready target, which itself is
started by fan control --init after a hardcoded delay. This field is
optional to preserve backwards compatibility and defaults to 0s.

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

show more ...


# 8a0c2327 17-Jun-2020 Matthew Barth <msbarth@us.ibm.com>

monitor: `optional` no longer experimental

Change-Id: I29e4fa5cfdf5cefe1af548fd5af2a54d08682a11
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>


# 3ad14346 08-Jun-2020 Matthew Barth <msbarth@us.ibm.com>

monitor:JSON: Parse fan monitoring conditions

Optional conditions can be used to include monitoring a fan or not based
on the results of the condition function configured. These condition
functions

monitor:JSON: Parse fan monitoring conditions

Optional conditions can be used to include monitoring a fan or not based
on the results of the condition function configured. These condition
functions have their own required set of parameters, so parsing the JSON
for these conditions are done per supported condition function. This
adds the JSON parsing support for the current condition functions.

Tested:
`propertiesMatch` JSON parameters parsed into condition function
Any required parameters missing throws an exception
The `propertiesMatch` condition functions the same using JSON

Change-Id: I0f843951f4e83f2a5d44068820694010538788c1
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...


# 22ab93b4 08-Jun-2020 Matthew Barth <msbarth@us.ibm.com>

monitor:JSON: Parse fan definitions

Parse and create the list of fan definitions for monitoring from a JSON
configuration file.

Tested:
Fan definition list created same as from YAML
Any req

monitor:JSON: Parse fan definitions

Parse and create the list of fan definitions for monitoring from a JSON
configuration file.

Tested:
Fan definition list created same as from YAML
Any required parameters missing cause a runtime exception

Change-Id: Iafa194f01a48ed3445c5da6187db62cb4d2672d7
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...


12