| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Using an exit status of -1 everywhere leads to the status being
converted to 255 when output to a calling application. While this does
signify an error it has a reserved meaning for exit status out of range.
Lets use a valid general exit status of 1 instead.
Change-Id: I326701c78985e34c430c258fe31d9e910da10405
Signed-off-by: William A. Kennington III <wak@google.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each sensor listed to be associated with a trust group is defined to
either be part of the trust group or just affected by the results of the
trust group. This is denoted by defining an "in_trust" boolean attribute
that will include the sensor in the trust group for determination of
trust when true, otherwise only be included in the resulting trust
affect when defined as false.
When no "in_trust" attribute is given, the sensor is defaulted to be
included in the trust group determining trust.
Tested: Current trust group associations & reactions are unchanged
Change-Id: I717074bc1a32a07dc59f172a4c823c7e2bb84f8c
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It creates a list of group creator lambdas based on
the information in the monitor YAML file.
These lambdas are called by the manager class to create
the trust group instances.
A real life example is:
const std::vector<CreateGroupFunction> trustGroups
{
{
[]()
{
std::vector<std::string> names{
"fan0_1",
"fan1_1",
"fan2_1",
"fan3_1",
};
return std::make_unique<NonzeroSpeed>(names);
}
},
};
Change-Id: Ia883df35efb86242aae2f8ed7d1714e94e65a6e6
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
|
|
Generate the data structures from yaml data.
Change-Id: I8e21fa099f9365b8c8c7d2227c4debc263601b72
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
