| commit | 8a28bf11b0064224393b880fdcdc7423ef817106 | [log] [tgz] |
|---|---|---|
| author | Shounak Mitra <shounak@google.com> | Mon Oct 17 18:07:50 2022 +0000 |
| committer | Zhikui Ren <zhikui.ren@intel.com> | Fri Mar 03 22:31:07 2023 +0000 |
| tree | a306e3c4bfede76cd941c2a73976ec370928715f | |
| parent | 1f427c2407f7451ae42eb69d4cbcb0e145a1e14d [diff] |
dbus-sensors: Associate PSU sensors correctly PSUSensors associate sensors with the inventory item that defined its config in EM. It also needs to associate the sensor with the containing chassis. Today, it associates the sensor with the object that defined the config *and* with any all objects that implement Inventory.System. In the situation where the sensor is defined in a PowerSupply configuration, this works because the PowerSupply itself is not a chassis. As a result, the "chassis" <-> "all_sensors" association pointing to the power supply inventory object is ignored. However, if the power supply is itself a chassis, this sensor is now associated with at least two different chassis, which results in it showing up in two different Redfish resources in bmcweb (the defining chassis and the system chassis). This change uses the defining object as the chassis if it is actually a chassis or board (i.e. represented as a Redfish Chassis resource). If it is not, it uses the system chassis. This will not work correctly if there is more than one chassis which also implements Inventory.System, but we presently assume that there is only one system in a number of places. This should be fixed when we add support for multiple Systems. Tested: Sensors on PSUs that are also chassis have a single "chassis" association: busctl get-property \ xyz.openbmc_project.PSUSensor \ /xyz/openbmc_project/sensors/power/hotswap_in_Input_Power \ xyz.openbmc_project.Association.Definitions Associations a(sss) 2 "inventory" "sensors" "/xyz/openbmc_project/inventory/system/board/psu_chassis" "chassis" "all_sensors" "/xyz/openbmc_project/inventory/system/board/psu_chassis" Changed PSU to PowerSupply type: busctl get-property \ xyz.openbmc_project.PSUSensor \ /xyz/openbmc_project/sensors/power/hotswap_in_Input_Power \ xyz.openbmc_project.Association.Definitions Associations a(sss) 2 "inventory" "sensors" "/xyz/openbmc_project/inventory/system/powersupply/psu_chassis" "chassis" "all_sensors" "/xyz/openbmc_project/inventory/system/board/mainboard" Change-Id: I8a9e4191c427b441d96f0ab53ba59825eccee997 Signed-off-by: Shounak Mitra <shounak@google.com>
dbus-sensors is a collection of sensor applications that provide the xyz.openbmc_project.Sensor collection of interfaces. They read sensor values from hwmon, d-bus, or direct driver access to provide readings. Some advance non-sensor features such as fan presence, pwm control, and automatic cpu detection (x86) are also supported.
runtime re-configurable from d-bus (entity-manager or the like)
isolated: each sensor type is isolated into its own daemon, so a bug in one sensor is unlikely to affect another, and single sensor modifications are possible
async single-threaded: uses sdbusplus/asio bindings
multiple data inputs: hwmon, d-bus, direct driver access
A typical dbus-sensors object support the following dbus interfaces:
Path /xyz/openbmc_project/sensors/<type>/<sensor_name>
Interfaces xyz.openbmc_project.Sensor.Value
xyz.openbmc_project.Sensor.Threshold.Critical
xyz.openbmc_project.Sensor.Threshold.Warning
xyz.openbmc_project.State.Decorator.Availability
xyz.openbmc_project.State.Decorator.OperationalStatus
xyz.openbmc_project.Association.Definitions
Sensor interfaces collection are described here.
Consumer examples of these interfaces are Redfish, Phosphor-Pid-Control, IPMI SDR.
dbus-sensor daemons are reactors that dynamically create and update sensors configuration when system configuration gets updated.
Using asio timers and async calls, dbus-sensor daemons read sensor values and check thresholds periodically. PropertiesChanged signals will be broadcasted for other services to consume when value or threshold status change. OperationStatus is set to false if the sensor is determined to be faulty.
A simple sensor example can be found here.
Sensor devices are described using Exposes records in configuration file. Name and Type fields are required. Different sensor types have different fields. Refer to entity manager schema for complete list.