clang-tidy: reduce repo-specific flags

Adjust the clang-tidy settings so that it does not need to have
a bunch of values related to the libpeci subproject. In general
we should be ignoring any head

clang-tidy: reduce repo-specific flags

Adjust the clang-tidy settings so that it does not need to have
a bunch of values related to the libpeci subproject. In general
we should be ignoring any header files from any subprojects since
they are not under direct control of the repository-under-test.

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

show more ...

Fix clang-tidy failures

Change-Id: I4e9e02cb57ae5eac8d7dc9f7c6e1083959170766
Signed-off-by: Ed Tanous <edtanous@google.com>

sensors: Align source structure away from anti-patterns

The anti-patterns document comments on source structure, specifically
on placing internal headers in a parallel subtree[1]. dbus-sensors is an

sensors: Align source structure away from anti-patterns

The anti-patterns document comments on source structure, specifically
on placing internal headers in a parallel subtree[1]. dbus-sensors is an
example of violating this anti-pattern, so fix it.

[1]: https://github.com/openbmc/docs/blob/master/anti-patterns.md#placing-internal-headers-in-a-parallel-subtree

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I50ecaddd53fa9c9b7a0441af9de5e60bd94e47c6

show more ...

Added support for IPMB based SDR detection dynamically

SDR is a data record that provides platform management sensor type,
locations, event generation and access information.

A data records that co

Added support for IPMB based SDR detection dynamically

SDR is a data record that provides platform management sensor type,
locations, event generation and access information.

A data records that contain information about the type and the
number of sensors in the platform, sensor threshold support,
event generation capabilities and information on what type
of readings the sensor provides.

Here, SDR of Type 1 records are implemented based on IPMB to read
the sensor information from each bus which can be configured
using IPMB FRU from the EM file.

Sample Config :
{
"Bus": "$ipmbindex",
"Class": "IpmbDevice",
"Name": "$ipmbindex + 1 Twinlake Board",
"PowerState": "Always",
"Type": "IpmbDevice"
}

This configuration is based on the "xyz.openbmc_project.Ipmb.FruDevice"
service, which will read FRU information from each IPMB bus. "$bus"
will give the bus index for each IPMB bus.

If IPMB FRU is detected, SDR info and record count of the sensor in
each bus will be identified. After getting the record count,
Reservation ID for each IPMB bus will be received.

IpmbSDRDevice will retrieve the full set of SDR Records starting with
0000h as the Record ID to get the first record. The Next Record ID is
extracted from the response and this is then used as the Record ID in
a Get SDR request to get the next record. This is repeated until the
record count value is matched.

The full information of each sensor such as sensor name, sensor type,
sensor unit, threshold values, sensor unique number will be received
using IPMB.

Once all the sensor information is read, each data will be processed
and stored in the structure. These data will be accessed in the
below gerrit patch.

https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/52164

Tested : Tested on YosemiteV2 platform and verified all the IPMB based
SDR Type 1 supported device data.

Signed-off-by: Jayashree Dhanapal <jayashree-d@hcl.com>
Change-Id: I5f808b68c3052ec5bf78d3d5c5495bd1f448ade3

show more ...

Capture weak reference of sensor object in lambda

dbus callback methods are capturing 'this' pointer directly. A sensor
object can get deleted while a callback is pending invocation. This is
crashin

Capture weak reference of sensor object in lambda

dbus callback methods are capturing 'this' pointer directly. A sensor
object can get deleted while a callback is pending invocation. This is
crashing ipmbsensor daemon.

Capture weak reference in place of this pointer.

Tested: Run ipmbsensor as a binary with entity manager constantly
restarting to simulated destruction and construction of new sensor
object. No crash was observed after running for three hours. Prior to
this ipmbsensor was crashing within one hour

Signed-off-by: Vikash Chandola <vikash.chandola@intel.com>
Change-Id: Idd53cbeb912c87ca3c4c09302279fc9383c569bc

show more ...

hwmontempsensor: Fix crash on eventHandler signal callback

Previously the device-management logic didn't handle the eventHandler()
case quite right, leading to crashes like the following when
eventH

hwmontempsensor: Fix crash on eventHandler signal callback

Previously the device-management logic didn't handle the eventHandler()
case quite right, leading to crashes like the following when
eventHandler()'s call to createSensors() ends up spuriously trying to
re-create sensor devices:

hwmontempsensor[455]: terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
hwmontempsensor[455]: what(): open: No such file or directory [system:2 at /usr/include/boost/asio/detail/impl/io_uring_file_service.ipp:61:5 in function 'boost::system::error_code boost::asio::detail::io_uring_file_service::open(implementation_type&, const char*, boost::asio::file_base::flags, boost::system::error_code&)']

To fix this we have instantiateDevices() augment the map it returns to
include all sensor devices (not just newly created ones) and adding a
bool to indicate whether each one was newly instantiated or already
existed. This allows createSensors() to reuse existing I2CDevices when
called by eventHandler() instead of needlessly trying to destroy &
re-create them.

Tested: On romed8hm3 ran hwmontempsensor by hand (to keep systemd from
restarting it) and restarted E-M to trigger an eventHandler() call,
verified that hwmontempsensor didn't crash and kept all sensors
instantiated. Also tested powering the host on and off to verify that
host-power-domain sensors were still torn down and re-created as
appropriate.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I576ff6238f45d8e2885790a624fb5c838648c897

show more ...

Define Sensor::readingStateGood() in terms of readingStateGood()

We can reuse the same logic instead of duplicating it between the
generic global function and the Sensor class method.

Signed-off-by

Define Sensor::readingStateGood() in terms of readingStateGood()

We can reuse the same logic instead of duplicating it between the
generic global function and the Sensor class method.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: Ibc77c2fe538398a013aab2b13964e37bb6f17f9e

show more ...

Support value "ChassisOn" for "powerState" option

There are some sensors need to be read when the chassis power is On
regardless the boot state of host. Even when the host is failed to
boot the valu

Support value "ChassisOn" for "powerState" option

There are some sensors need to be read when the chassis power is On
regardless the boot state of host. Even when the host is failed to
boot the values of these sensors can be used to debug the failure in
power rails.
The current code of dbus-sensors only supports the values "On",
"BiosPost" and "Always" for "powerState" option which can not used
for these kinds of sensors.
This commit adds "ChassisOn" value for "powerState" sensor option.
This value will be used for sensors which will only be read when the
CurrentPowerState is On.

Tested:
1. Add setting PowerState="ChassisOn" to some sensors.
2. Force the CurrentPowerState to
xyz.openbmc_project.State.Chassis.PowerState.Off.
3. The value D-Bus properties of those sensors should be nan.
4. Force the CurrentPowerState to
xyz.openbmc_project.State.Chassis.PowerState.On.
5. The value D-Bus properties of those sensors should be the real
sensor values.

Signed-off-by: Thu Nguyen <thu@os.amperecomputing.com>
Change-Id: Icdb9d9cf1ac77c891113fa9b69b33b8bfdb082f7

show more ...

hwmontempsensor: Manage devices on host power-state events

We now install handler callbacks for power event signals, deactivating
sensors on power-off and activating them on power-on/POST-complete
a

hwmontempsensor: Manage devices on host power-state events

We now install handler callbacks for power event signals, deactivating
sensors on power-off and activating them on power-on/POST-complete
according to their PowerState configuration. This is needed to properly
support sensor devices that are in the same power domain as the host,
and hence may need their drivers bound only after the host is powered on
so that the driver can properly probe and attach to the device (and
likewise be unbound when the host is powered off).

Tested: in combination with corresponding entity-manager patches to
prevent it from trying to manage the same devices, hwmontempsensor
successfully activates and deactivates host-power-domain nct6779 and
w83773g sensors on romed8hm3. After the host is shut off, sensors
remain on dbus with 'Available' set to false and 'Value' reading NaN.
Also tested killing hwmontempsor after it instantiated host-power-domain
sensors, shutting off the host, and then restarting hwmontempsensor to
verify that it removed and re-created the sensor devices as necessary.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I2e272fd0870f3abfb06b6f3617f32721861bbc5b

show more ...

Add getPollRate helper function

This open-coded pattern had been duplicated in a few places; deduplicate
and increase readability by adding a dedicated function. While we're at
it, also ensure the

Add getPollRate helper function

This open-coded pattern had been duplicated in a few places; deduplicate
and increase readability by adding a dedicated function. While we're at
it, also ensure the configured value isn't inf or NaN.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I5f8fe788eb342ca3bf8b52bd6a2e7cc3364f45e1

show more ...

DeviceMgmt: add I2CDeviceParams::deviceStatic() method

This will be used to determine whether a given i2c device is statically
instantiated via a device tree or if it's a dynamically-created device

DeviceMgmt: add I2CDeviceParams::deviceStatic() method

This will be used to determine whether a given i2c device is statically
instantiated via a device tree or if it's a dynamically-created device
managed by userspace. As dbus-sensors daemons assume responsibility for
device lifecycle management this can be used to distinguish between
static and dynamic device nodes even if a previous process crashed after
instantiating one (whereas a simple presence check might mistake a
device that was instantiated but not cleaned up for a static device and
thus never remove it).

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I3911b0cace60689766993a8be3b8f160f71de2d1

show more ...

DeviceMgmt: split I2CDeviceParams out of I2CDevice

The parameters struct now exists on its own, separately from the device
struct which instantiates the kernel device in its constructor and
removes

DeviceMgmt: split I2CDeviceParams out of I2CDevice

The parameters struct now exists on its own, separately from the device
struct which instantiates the kernel device in its constructor and
removes it in its destructor. This allows the parameters to exist
standalone so that we can do things like use an instance of it to check
if a device is already instantiated without attempting to do so.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: Ib1c37ee26e27e59020a8e26916e697729a3661af

show more ...

Move to steady_timer

deadline_timer and steady_timer have one important difference, the
former runs off CLOCK_REALTIME, and the later runs off CLOCK_MONOTONIC.
For a long time we've relied on deadli

Move to steady_timer

deadline_timer and steady_timer have one important difference, the
former runs off CLOCK_REALTIME, and the later runs off CLOCK_MONOTONIC.
For a long time we've relied on deadline_timer incorrectly, given that
dbus-sensors does not care in the least about the calendar time, and
only cares about the difference between sensor scans.

Fortunately, this likely has no effect on the behavior of the sensors
most of the time, and in general, in a time change, the clock generally
moves forward, so all timers would immediately expire, scan all sensors,
and move on. phosphor-pid-control is intentionally designed to handle
this case, so it's quite likely that a user would never notice it, and
even if they did, would have to be looking at a debug console the moment
it happened.

The other effect is that in most cases, sensors call clock_gettime more
than they probably need to, which might slow down the performance.

This commit moves all usages of sensor timing to steady_timer, which
should give us more consistent results, and (in theory at least) be
faster. Because of stdlib compliance things, this also has the effect
of us dropping our dependence on boost::posix_time, and move to
std::chrono::duration objects, per the coding standard.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I69f948fb3f0fc0dfd7fd196d26ba46742a3e15a7

show more ...

Add device-management infrastructure

We're moving toward having dbus-sensors take over sensor device
lifecycle management from entity-manager; this code (loosely based on
entity-manager's include/de

Add device-management infrastructure

We're moving toward having dbus-sensors take over sensor device
lifecycle management from entity-manager; this code (loosely based on
entity-manager's include/devices.hpp and src/overlay.cpp) provides some
general-purpose utilities for instantiating and destroying devices.

This also includes a variant of setupPropertiesChangedMatches() taking
an I2CDeviceTypeMap instead of a span of C strings, so that we can
support both existing sensor daemons and ones that get converted to use
that instead of the simple string arrays they currently employ.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I39fcd0de2c70cd58b4d132cdcae5f82319732dbb

show more ...

Remove Configuration interface prefix from utils APIs

This eliminates some repetitive verbosity from daemons that handle a lot
of different sensor types (such as hwmontempsensor and psusensor). It

Remove Configuration interface prefix from utils APIs

This eliminates some repetitive verbosity from daemons that handle a lot
of different sensor types (such as hwmontempsensor and psusensor). It
also positions us to more cleanly use a single data structure for both
existing APIs like GetSensorConfiguration() and
setupPropertiesChangedMatches(), as well as upcoming I2C
device-management support.

Tested: hwmontempsensor and adcsensor on romed8hm3 continue to behave as
they did previously.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I9d80475ca4160c8d2ff0afab942709496d51238d

show more ...

Replace boost string predicate functions with stdlib ones

Now that we're on C++20 we no longer need boost for starts_with() and
ends_with() tests.

Also remove the predicate.hpp #include from files

Replace boost string predicate functions with stdlib ones

Now that we're on C++20 we no longer need boost for starts_with() and
ends_with() tests.

Also remove the predicate.hpp #include from files that weren't actually
using anything from it.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: Id68a019d5108a4646eb9b5fd18af33d60617e048

show more ...

Refactor PropertiesChanged handler setup

Most sensor daemons had pretty much the same duplicated open-coded
pattern for setting up PropertiesChanged signal matches; introduce a
helper function to re

Refactor PropertiesChanged handler setup

Most sensor daemons had pretty much the same duplicated open-coded
pattern for setting up PropertiesChanged signal matches; introduce a
helper function to reduce the duplication and make things more readable.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I803a21eea2f6d7fc71b50d54bb8fd57a104f3349

show more ...

cpusensor: Change cpusensor to intelcpusensor

cpusensor class is specifically used for Intel CPU. The name of this
class and the build option should be changed to reflect with their
role.
The patch

cpusensor: Change cpusensor to intelcpusensor

cpusensor class is specifically used for Intel CPU. The name of this
class and the build option should be changed to reflect with their
role.
The patch set https://gerrit.openbmc.org/c/openbmc/openbmc/+/56096 is
required to prevent the build error in openbmc source.

Tested:
1. No build error.

Signed-off-by: Thu Nguyen <thu@os.amperecomputing.com>
Change-Id: I1f941fffa10222cdac908fd763dccc866ba0e8a6

show more ...

tachsensor: Similar fixes from HwmonTempSensor

Ported the substance of the changes from here to TachSensor:
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/56019

The goal is to provide similar

tachsensor: Similar fixes from HwmonTempSensor

Ported the substance of the changes from here to TachSensor:
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/56019

The goal is to provide similar fixes to I/O and buffering, catching up
to similar changes made recently in HwmonTempSensor.

Tested: Fan RPM now shows up correctly on my machine again.

Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I49c539e3713e9d02d4584f305e4ced6d4b2ba572

show more ...

psusensor: remove unused fd

After enabling io-uring in [0], the underlying file is managed by the
random_access_file and the raw file descriptor is no longer used.

[0] https://gerrit.openbmc.org/c/

psusensor: remove unused fd

After enabling io-uring in [0], the underlying file is managed by the
random_access_file and the raw file descriptor is no longer used.

[0] https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/46918

Signed-off-by: Justin Ledford <justinledford@google.com>
Change-Id: Ie896f62d75ea9a461179ef807775a25bf517420a

show more ...

Utils: add optional callback for power state changes

Some systems require sensors to be instantiated and destroyed on host
power state transitions; this plumbing provides infrastructure for
dbus-sen

Utils: add optional callback for power state changes

Some systems require sensors to be instantiated and destroyed on host
power state transitions; this plumbing provides infrastructure for
dbus-sensors daemons to be notified on power state changes so they can
respond appropriately.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I2fc24c91e6d62bb3da71928ef0761760cc90e75f

show more ...

hwmontempsensor: Simplify I/O and buffering

We can avoid the complexity and additional allocations of
boost::asio::streambuf by just using a simple fixed-size inline array as
the HwmonTempSensor rea

hwmontempsensor: Simplify I/O and buffering

We can avoid the complexity and additional allocations of
boost::asio::streambuf by just using a simple fixed-size inline array as
the HwmonTempSensor read buffer.

While the underlying cause of the issue remains unknown at present, this
also seems to resolve a use-after-free bug that could occur with the
existing buffering scheme (https://github.com/openbmc/dbus-sensors/issues/20).

Based on a WIP patch by @edtanous:
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/55041

Tested: on romed8hm3, hwmontempsensor provides appropriate readings on
dbus as it did prior to this patch. In combination with the debug
patches in https://github.com/openbmc/dbus-sensors/issues/20, an ASAN
build did not report any problems while repeatedly rebuilding sensors.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I7f0ab63fc398b8c938592f38f137174187c5e438

show more ...

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are

sdbusplus: use shorter type aliases

The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t

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

show more ...

sensor: Bypass updating Nan to value when it's already Nan

Bypass updating sensor value when both old and new value of the sensor
are Nan. This avoids continuous value update to some sensor types
(n

sensor: Bypass updating Nan to value when it's already Nan

Bypass updating sensor value when both old and new value of the sensor
are Nan. This avoids continuous value update to some sensor types
(nvmesensor, adcsensor) when the power state is off, and affecting
speed of applications that listen to their propertiesChanged signals.

Signed-off-by: chaul.ampere <chaul@amperecomputing.com>
Change-Id: I20044ecdb2f420928a83bed7e37eef6750ce9e5f

show more ...

NVMeBasicContext: Properly cleanup resources, allowing destruction

nvmesensor was terminating with an uncaught exception, e.g:

Jun 03 04:52:09 bmc nvmesensor[507]: terminate called after throwi

NVMeBasicContext: Properly cleanup resources, allowing destruction

nvmesensor was terminating with an uncaught exception, e.g:

Jun 03 04:52:09 bmc nvmesensor[507]: terminate called after throwing an instance of 'sdbusplus::exception::SdBusError'
Jun 03 04:52:09 bmc nvmesensor[507]: what(): sd_bus_add_object_vtable: org.freedesktop.DBus.Error.FileExists: File exists

This would occur whenever entity-manager published a configuration for a
new drive in the system. The implementation of nvmesensor isn't the
smartest, and it tries to just scrap all NVMeContexts it knows of, along
with their NVMeSensor instances, and reconstruct them all from newly
captured entity-manager configuration data.

The problem lies in the fact that the NVMeContexts were not getting
destructed due embedding of std::shared_ptrs obtained via
shared_from_this() into async callback lambda captures whose context was
owned by the NVMeContext implementation.

Switch to capturing `this` via weak_from_this() in callback lambdas to
prevent the circular references. By doing so we are able to successfully
destruct the NVMeContext derivative instances via the clear() method on
the context map.

However, there's more to the story, as the NVMeSensors owned by a given
context are asynchronously iterated for polling purposes. To make sure
we don't have races from unbounded latency on asynchronous destruction
of NVMeSensors, we order the std::jthread and async stream member
variables of NVMeBasicContext such that destruction of the streams exits
the IO thread due to read() or write() syscall failures on the pipes.
The use of std::jthread ensures we join() to complete the cleanup prior
to returning from the NVMeBasicContext destructor.

Preventing active polling of NVMeSensor instances ensures their
destruction when clearing the NVMe context map, opening the path for
successful (re-)construction of NVMeSensor DBus objects for the
published sensor configurations.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I63d0e7eb3318c209b08551072a3cb7279da21269

show more ...