meson: reformat with meson formatter

Apply the `meson format` results.

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

Add mctpreactor for dynamic configuration of MCTP networks

While mctpd[1] may see heavy use in projects such as OpenBMC, it
implements generic functionality necessary to operate MCTP as a
protocol.

Add mctpreactor for dynamic configuration of MCTP networks

While mctpd[1] may see heavy use in projects such as OpenBMC, it
implements generic functionality necessary to operate MCTP as a
protocol. It therefore should be easy to use in other contexts, and so
it feels unwise to embed OpenBMC-specific details in its implementation.

Conversely, entity-manager's scope is to expose inventory and board
configuration. It externalises all other responsibilities for the sake
of stability and maintenance. While entity-manager is central to
OpenBMC's implementation and has little use in other contexts, embedding
details of how to configure mctpd in entity-manager exceeds its scope.

Thus we reach the design point of mctpreactor, an intermediary process
that encapsulates OpenBMC-specific and mctpd-specific behaviors to
constrain their dispersion in either direction. The design-point was
reached via discussion at [2].

mctpreactor tracks instances of transport-specific MCTP device
configurations[3] appearing as a result of inventory changes, and uses
them to assign endpoint IDs via mctpd.

The lifecycle of an MCTP device can be quite dynamic - mctpd provides
behaviors to recover[4] or remove endpoints from the network. Their
presence cannot be assumed. mctpreactor handles these events: If
a device is removed at the MCTP layer (as it may be unresponsive),
mctpreactor will periodically attempt to re-establish it as an endpoint
so long as the associated configuration on the entity-manager inventory
object remains exposed.

[1]: https://github.com/CodeConstruct/mctp/
[2]: https://github.com/CodeConstruct/mctp/pull/17
[3]: https://gerrit.openbmc.org/c/openbmc/entity-manager/+/70628
[4]: https://github.com/CodeConstruct/mctp/blob/7ec2f8daa3a8948066390aee621d6afa03f6ecd9/docs/endpoint-recovery.md

Change-Id: I5e362cf6e5ce80ce282bab48d912a1038003e236
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

meson: Define include_directories in dependencies for static libraries

This way the headers are found automatically via the dependency objects.

Change-Id: I740b331cd134497663dbd21565ea918c861f9901

meson: Define include_directories in dependencies for static libraries

This way the headers are found automatically via the dependency objects.

Change-Id: I740b331cd134497663dbd21565ea918c861f9901
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

Move source files into application-specific sub-directories

Currently, dbus-sensors implement multiple applications:
- psusensor
- adcsensor
- intelcpusensor
- hwmontempsensor
- ipmbsensor
- n

Move source files into application-specific sub-directories

Currently, dbus-sensors implement multiple applications:
- psusensor
- adcsensor
- intelcpusensor
- hwmontempsensor
- ipmbsensor
- nvmesensor
- externalsensor
- mcutempsensor
- intrusionsensor
- fansensor
- exitairtempsensor

This commit is to create separate directories for each application so
that things can be separated more easily and the files are smaller,
instead of creating one huge file for the sensor implementation.

There was some discussion in discord on this. [1][2]

[1]: https://discord.com/channels/775381525260664832/1187158775438778408/1284106093756289067
[2]: https://discord.com/channels/775381525260664832/867820390406422538/1303217796821553214

Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I258fc2ee7d8f939c7b83a07350395e78775b2b8d

show more ...

Move GPIO presence object to its own files

This commit moves and renames the PresenceSensor to PresenceGpio
from TachSensors to its own file so that it can be used for more
than just fans.
It is cur

Move GPIO presence object to its own files

This commit moves and renames the PresenceSensor to PresenceGpio
from TachSensors to its own file so that it can be used for more
than just fans.
It is currently only used for GPIO presence monitoring for fans.

This commit maintains the same functionality as the original code.
Once the objects is created for a GPIO, it will be monitoring for
gpiod::line_request::EVENT_BOTH_EDGES changes. The user can call
isPresent() anytime to read the presence status.

Interface:
EventPresenceGpio(const std::string& iDeviceType,
const std::string& iDeviceName,
const std::string& gpioName, bool inverted,
boost::asio::io_context& io);
Sample usage:
presenceGpio = std::make_unique<EventPresenceGpio>(
"Fan", "Fan4b", "FAN4_PRESENCE_R_N", true, io);
if (presenceGpio->isPresent())
{
// Fan is present
}

Testing: Unable to test this update because no hardware supporting
event driven GPIO detection available.

Change-Id: I1f1a4cbab39d3e3ab38b30288f6aa199ee0cfe3c
Signed-off-by: Chris Cain <cjcain@us.ibm.com>

show more ...

Add IpmbSensor unit tests

Because everything was packed into IpmbSensor.cpp, which also included
main(), this commit breaks it up into the patterns we have in other
sensors, with <X>main.cpp contain

Add IpmbSensor unit tests

Because everything was packed into IpmbSensor.cpp, which also included
main(), this commit breaks it up into the patterns we have in other
sensors, with <X>main.cpp containing the things for main.

While this doesn't clean up everything, it at least makes
processResponse unit testable, and adds one minor test for it.

Change-Id: I1eabf650ff635211e5b9a94816c2ffce250ed252
Signed-off-by: Ed Tanous <ed@tanous.net>

show more ...

meson: Format build files according to meson style guide

muon[1], an meson-compatible build system, provides a `fmt` subcommand
to format meson build files in accordance with the meson style guide[2

meson: Format build files according to meson style guide

muon[1], an meson-compatible build system, provides a `fmt` subcommand
to format meson build files in accordance with the meson style guide[2].

[1]: https://muon.build/
[2]: https://mesonbuild.com/Style-guide.html

Apply `muon fmt` using the following to provide consistent formatting:

```
for f in $(git ls-files | grep meson.build)
do
muon fmt $f | sponge $f
done
```

Change-Id: I7ef7693ddf964e9540b2e3e256cdf584fb8ac9cd
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer retur

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer return true for auto features. Instead, the
expectation is to use `allowed()` which is true for both enabled and auto.

Switch all uses of `enabled` to `allowed`.

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

show more ...

Fix libpeci build

libpeci recently moved to meson. The detection logic here wasn't
working, and would always fall back to a custom build using cmake.

Replace with a simple dependency call.

Change

Fix libpeci build

libpeci recently moved to meson. The detection logic here wasn't
working, and would always fall back to a custom build using cmake.

Replace with a simple dependency call.

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

show more ...

Add uring_args for all build targets in package

io_uring backend is enabled with uring_args. Add them to package args.
All build targets including static libraries for utils and thresholds
and senso

Add uring_args for all build targets in package

io_uring backend is enabled with uring_args. Add them to package args.
All build targets including static libraries for utils and thresholds
and sensor services executables are built consistently.

Currently steady timer in utils.cpp fires right away for services build
with io_uring enabled like fansensor, hwmontempsensor.
https://github.com/openbmc/dbus-sensors/blob/master/src/Utils.cpp#L472

Tested:
Added debug print and verified the above timer handler is called 10
seconds after the timer is started as expected. intelcpusensor, which
does not use random_access_file with io_uring backend reads sensor
values successfully. Services use random_access_file read sensor data
successfully.

Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
Change-Id: I8cf3a9a0d1ffca459eb6c2c37e4e2220ce5100ac

show more ...

IntelCPUSensor: Use libpeci when communicating via peci-legacy

When using peci-legacy the general approach is to use libpeci as
the middleware to communicate with peci core from userspace.
Integrate

IntelCPUSensor: Use libpeci when communicating via peci-legacy

When using peci-legacy the general approach is to use libpeci as
the middleware to communicate with peci core from userspace.
Integrate libpeci with IntelCPUSensor and use library functions to issue
peci commands where necessary.

Tested: hwmons are succesfully created in the same way
they were created using ioctl.

Change-Id: I4ecd70e604d447a4066dc5fb8d902992cb97cadf
Signed-off-by: Oleksandr Shulzhenko <oleksandr.shulzhenko.viktorovych@intel.com>

show more ...

psusensor: Convert sensorTypes to I2CDeviceTypeMap

Similar to change
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/56127.

Tested: same sensors get initialized before and after change.

Change

psusensor: Convert sensorTypes to I2CDeviceTypeMap

Similar to change
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/56127.

Tested: same sensors get initialized before and after change.

Change-Id: I57aca3738b01aa22da4dab5d8b1ed251578d9123
Signed-off-by: Matt Simmering <matthew.simmering@intel.com>

show more ...

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

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

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

Enable an io-uring build

There exists a bug where calls that we previously thought were
non-blocking, actually do block when used with hwmon or filesystem fds.
This causes high latencies on the dbus

Enable an io-uring build

There exists a bug where calls that we previously thought were
non-blocking, actually do block when used with hwmon or filesystem fds.
This causes high latencies on the dbus interfaces when lots of sensors
are used in a single daemon, as is the case in PSUSensor.

This patchset moves the PSUSensor code over to using io-uring, through
boost asio, using the random_access_file class. This helps with
performance in a number of ways, the largest of which being that sensor
reads are no longer blocking.

Tested:

Booted the sensor system on Tyan S7106; dbus-monitor shows sensors
scanning normally.

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

show more ...

nvmesensor: Remove MCTP transport implementation

This was implemented in terms of a series of patches against libmctp
that were never upstreamed (because they in-turn relied on kernel
patches that a

nvmesensor: Remove MCTP transport implementation

This was implemented in terms of a series of patches against libmctp
that were never upstreamed (because they in-turn relied on kernel
patches that also were never upstreamed). Further, there are no
configurations enabling the nvme-mi-mctp option in openbmc/openbmc.

This is motivated by the need to refactor NVMeContext to support polling
all sensors inside the polling period on a given root bus.

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

show more ...

nvmesensor: Introduce nvme-mi-mctp build feature

Allow MCTP support to be configured at build time.

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

nvmesensor: Introduce nvme-mi-mctp build feature

Allow MCTP support to be configured at build time.

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

show more ...

nvmesensor: Support the NVMe MI basic management command

The NVMe MI basic management command is an optional extension to the
NVMe specification that allows management controllers to query drive
sta

nvmesensor: Support the NVMe MI basic management command

The NVMe MI basic management command is an optional extension to the
NVMe specification that allows management controllers to query drive
state without needing an MCTP stack[1].

[1] https://nvmexpress.org/wp-content/uploads/NVMe_Management_-_Technical_Note_on_Basic_Management_Command.pdf

Given the current lack of support for the SMBus MCTP binding in upstream
OpenBMC, provide an NVMe MI basic management command implementation that
allows nvmesensor to function without diving into a maze of out-of-tree
patches.

As we're doing this in userspace we exploit Linux's I2C chardev
interface for talking to the drives. However, the interface is driven by
ioctl()s, which interacts poorly with the event-driven ASIO design.

Click the lego together by using an IO thread to transform ioctl()s into
read() and write() operations that we can handle asynchronously.

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

show more ...

build: DRY dependencies

Nearly everything uses 'sdbusplus' and 'nlohmann-json'. Since
'nlohmann-json' is a header-only library there is no issue with
excessively including it as a dependency. DRY

build: DRY dependencies

Nearly everything uses 'sdbusplus' and 'nlohmann-json'. Since
'nlohmann-json' is a header-only library there is no issue with
excessively including it as a dependency. DRY up the dependency
specification by creating a 'default_deps' array that can contain
these.

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

show more ...

build: use nlohmann-json dependency

Many sources files want to use the 'json.hpp' file from nlohmann,
but when this is installed as a subproject it isn't in the default
search path, unless a depende

build: use nlohmann-json dependency

Many sources files want to use the 'json.hpp' file from nlohmann,
but when this is installed as a subproject it isn't in the default
search path, unless a dependency to it is explicitly added. In
most cases this is pulled in via the 'Thresholds.hpp' file which is
in-turn linked in by the thresholds static library.

In meson, static libraries shouldn't be linked against directly but
instead indirectly through a 'dependency' relationship, otherwise the
implicit header file needs are not able to be communicated up to users
of the library (such as Thresholds -> json.hpp here). Revamp the
static library relationships to use 'dependencies' rather than
'link_with' so that the header file needs are properly expressed.

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

show more ...

NVMeContext: Split out NVMeMCTPContext

The MCTP-oriented implementation of NVMeContext requires linking against
a libmctp build that provides an SMBus binding implementation. The SMBus
binding imple

NVMeContext: Split out NVMeMCTPContext

The MCTP-oriented implementation of NVMeContext requires linking against
a libmctp build that provides an SMBus binding implementation. The SMBus
binding implementation isn't upstream, and neither are the kernel
interfaces it relies on.

Later, an NVMe MI Basic implementation will be introduced. NVMe MI Basic
only requires support for SMBus block reads rather than MCTP, though is
not as fully featured as the MCTP interface and is not required to be
supported by implementers of the NVMe specification.

For now, reduce NVMeContext to a base class that NVMeMCTPContext
extends and only use the NVMeMCTPContext type where explicitly
required. This opens up the opportunity to make MCTP support a
build-time configurable option.

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

show more ...

NVMeSensor: Split out NVMeContext

An NVMeContext instance contains some number of NVMeSensors, but
NVMeSenors do not need to be concerned with the implementation details
of NVMeContext. Make it easi

NVMeSensor: Split out NVMeContext

An NVMeContext instance contains some number of NVMeSensors, but
NVMeSenors do not need to be concerned with the implementation details
of NVMeContext. Make it easier to discern what's related to what by
splitting NVMeContext out into its own header and source file.

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

show more ...

nvmesensor: Link against liblibmctp

Because the CMake build system ends up installing the library on the
system as liblibmctp.

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

nvmesensor: Link against liblibmctp

Because the CMake build system ends up installing the library on the
system as liblibmctp.

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

show more ...