History log of /openbmc/phosphor-fan-presence/monitor/trust_group.hpp (Results 1 – 11 of 11)
Revision Date Author Comments
# 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 ...


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


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


# fcb0dbcb 10-Feb-2021 Matthew Barth <msbarth@us.ibm.com>

monitor: Trust group cancel/start monitoring

Any fan monitoring trust groups configured should cancel the monitoring
of all fan sensors configured in the trust group for all monitoring
methods(timer

monitor: Trust group cancel/start monitoring

Any fan monitoring trust groups configured should cancel the monitoring
of all fan sensors configured in the trust group for all monitoring
methods(timer based or count based) when the group is determined not to
be trusted.

Also, the trust manager should restart monitoring all the sensors in the
group by processing each sensor against the configured monitoring
method. This matches how each sensor is processed on each tach changed
signal where only when a tach changed signal is received does the trust
state of the sensor get checked prior to processing the state of the
sensor.

Tested:
Verify fan sensors in trust group's functional state is correct

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

show more ...


# 177fe986 26-May-2020 Matthew Barth <msbarth@us.ibm.com>

monitor: Clang format updates

Used `format-code.sh` build script to make changes to conform to clang
format.

Tested: Compiled

Change-Id: Ieead1449cfd4b61333a135740dce03789218f92b
Signed-off-by: Ma

monitor: Clang format updates

Used `format-code.sh` build script to make changes to conform to clang
format.

Tested: Compiled

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

show more ...


# 3800ae71 19-Feb-2018 Matthew Barth <msbarth@us.ibm.com>

Define a mode for tach sensor timer

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

Define a mode for tach sensor timer

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>

show more ...


# a1c88322 16-Feb-2018 Matthew Barth <msbarth@us.ibm.com>

Replace tuple with struct for trust sensor group

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 determ

Replace tuple with struct for trust sensor group

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>

show more ...


# 6f31d19b 30-Jan-2018 Matthew Barth <msbarth@us.ibm.com>

Generate sensor to trust association

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 i

Generate sensor to trust association

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>

show more ...


# 32affb98 16-Feb-2018 Matthew Barth <msbarth@us.ibm.com>

optimize: Tach sensors as shared pointers

The fan and trust group objects should utilize shared pointers to the
tach sensor objects. This allows optimizing the storage of additional
attributes assoc

optimize: Tach sensors as shared pointers

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>

show more ...


# 5856023d 22-Nov-2017 Matthew Barth <msbarth@us.ibm.com>

Update trust group sensor timer start

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 sens

Update trust group sensor timer start

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>

show more ...


# 78689dd7 28-Sep-2017 Matt Spinler <spinler@us.ibm.com>

monitor: Add tach sensor trust group class

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 truste

monitor: Add tach sensor trust group class

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>

show more ...