| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a single timer on the tach sensors for delaying both nonfunctional
and functional state changes by declaring what mode the timer is in.
Since a fan is either transitioning from a functional state to a
nonfunctional state or vice-versa, enabling the timer in the mode
requested allows the user to define a delay for both of these transition
states.
Tested: Current nonfunctional timer delay operates the same
Change-Id: I0c165355d41d27e1906918953e5226968062ee16
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
To simplify sensor and trust access, utilize a struct in place of a
tuple for storing the trust group sensors and their inclusion in the
trust determination.
Tested: Current trust group associations & reactions are unchanged
Change-Id: Ifd5cf5d0540a3b2028ccf74e725d8ddd11982aee
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The fan and trust group objects should utilize shared pointers to the
tach sensor objects. This allows optimizing the storage of additional
attributes associated with the tach sensors.
e.g. An attribute to declare which sensors should be included in the
trust determination.
Tested: Current trust group associations & reactions are unchanged
Change-Id: I249cc7debf467e8275fae7fa157ce97078b40802
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trust group sensors' timers should only start when the sensor is
currently functional and its target and input do not match.
This handles the case where a sensor within a trust group does not get a
target set resulting in both the target and input to be zero.
At anytime a sensor's target and input are equal, the timer to mark them
as nonfunctional should not start.
Change-Id: I8e4fd33a5bcbd25854e5954b41646127982eedd3
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
|
|
The trust::Group class is an abstract base class that
introduces the concept of knowing if a tach sensor
reading can be trusted or not. If it isn't trusted,
then it shouldn't be used when calculating if the fan
is considered functional or not.
It's a group because it supports groups of sensors
all having the same trusted status. For example the
first use case is a group of sensors cannot be trusted
when all of their readings are zero. A group may of
course just have 1 sensor in it if required.
The class also provides the functionality to start and
stop the timers that are used to consider a sensor faulted.
The timers would be stopped when a group moves to untrusted,
and started when it goes back to the trusted state.
Derived classes provide the functionality that actually
determines the trust value.
The constructor takes the list of sensor names that should
be in the group. After the TachSensor classes have been
constructed, the registerSensor(sensor) function must be
called to add the sensor objects to the group.
The checkTrust() function is used to calculate the trust
status of the group.
Change-Id: Ib4b871c6a186105028d1cc186c49611fb0608325
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
