prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

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

show more ...

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

monitor: Add JSON configuration example

Create an example configuration that includes a description of each
configuration section. Details of the JSON keys and values will be
handled within the conf

monitor: Add JSON configuration example

Create an example configuration that includes a description of each
configuration section. Details of the JSON keys and values will be
handled within the configuration README

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

show more ...

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

Add generation of propertiesMatch condition

Update the mako template to generate conditions within the FanDefinition
sections when a condition is defined for a fan. Each supported condition
function

Add generation of propertiesMatch condition

Update the mako template to generate conditions within the FanDefinition
sections when a condition is defined for a fan. Each supported condition
function's parameters are generated within a `getCondParams` mako
method, allowing easy support of additional conditions with differing
parameters.

Tested:
A given condition's function and parameters generate correctly
No condition function is generated on a fan where not defined

Resolves: openbmc/openbmc#2976

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

show more ...

Add tach sensor functional delay

Add ability to define a delay to marking a tach sensor as functional
when it transitions from a nonfunctional state. Essentially this gives
the option to wait a give

Add tach sensor functional delay

Add ability to define a delay to marking a tach sensor as functional
when it transitions from a nonfunctional state. Essentially this gives
the option to wait a given amount of time that a tach sensor must be
within the allowed deviation before being updated to functional.

Default functional delay = 0 seconds

Tested: Current fan definition values function the same

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

show more ...

NonzeroSpeed: Check trust determination sensors

Only include defined trust determination sensors in checking the group
trust.

Tested:
Current trust group associations & reactions are unchanged

NonzeroSpeed: Check trust determination sensors

Only include defined trust determination sensors in checking the group
trust.

Tested:
Current trust group associations & reactions are unchanged
Combination of sensors included and excluded in trust determination

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

show more ...

Add target interface for fan monitor

Current fan monitor assumes the use of the FanSpeed interface for fan
targets.
For fans controlled by pwm, FanPwm interface is added.

This commit adds a "target

Add target interface for fan monitor

Current fan monitor assumes the use of the FanSpeed interface for fan
targets.
For fans controlled by pwm, FanPwm interface is added.

This commit adds a "target_interface" config parameter, so that user
can specify the interface for the fan targets.

E.g.

- name: fan0
has_target: true
target_interface: xyz.openbmc_project.Control.FanPwm

This config is optional and defaults to FanSpeed, so the current code
will not be affected.

Tested: Use this config on Romulus, ensures fan monitor gets fan
target from FanPwm interface and works OK.

Change-Id: I262a486c335b2b43a46af7abdd0e71e95a133b98
Signed-off-by: Lei YU <mine260309@gmail.com>

show more ...

Add factor and offset for fan monitor

For fans controlled via pwm, the fan target and speed are different,
where the fan target is pwm and the speed is rpm.

Usually it is a linear mapping from pwm

Add factor and offset for fan monitor

For fans controlled via pwm, the fan target and speed are different,
where the fan target is pwm and the speed is rpm.

Usually it is a linear mapping from pwm to rpm.
So this commit defines the optional configs, factor and offset for
calculating the expected fan speed from target, e.g.

- name: fan0
has_target: true
factor: 21
offset: 1600

The fan monitor service will calculate expected fan speed as:
target * factor + offset

The default value is 1 for factor and 0 for offset if they are not
defined.

Tested: Use this config together with the following commit's changes,
test on Romulus and ensures the fan monitor works OK;
Without this config, fan monitor always mark fans as
non-functional due to the fan speed does not match the pwm
value.

Change-Id: If5e25368b4530df7a7face9377efb58804db21df
Signed-off-by: Lei YU <mine260309@gmail.com>

show more ...

monitor: Update example YAML

Update the YAML documentation with sensor
trust information.

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

Generate data from yaml during build

Run the python script to generate fan_zone_defs.cpp

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