PSUSensor: Add support for MP2975 sensor

Add support for Monolithic Power Systems, Inc. (MPS) vendor dual-loop,
digital, multi-phase controller MP2975.

Tested: sensor data is correctly displayed in

PSUSensor: Add support for MP2975 sensor

Add support for Monolithic Power Systems, Inc. (MPS) vendor dual-loop,
digital, multi-phase controller MP2975.

Tested: sensor data is correctly displayed in webui-vue

Change-Id: I8c2757d5304341ddd276149ae2a05efc74f248a2
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>

show more ...

Fix clang-tidy failures

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

psusensor: Formatting cleanup

Formatting issues are causing errors in the CI. Cleaning them up here.

Change-Id: I7ae134a14f783629aead1c6b5b0d76c539539aa9
Signed-off-by: Matt Simmering <matthew.sim

psusensor: Formatting cleanup

Formatting issues are causing errors in the CI. Cleaning them up here.

Change-Id: I7ae134a14f783629aead1c6b5b0d76c539539aa9
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 ...

NVMeSensorMain: Fix sensor object manager path

Change 661d4378467a ("Identify active sensors via the D-Bus "sensors"
service") added a trailing '/' to the path. Remove it, as it breaks
sensor detect

NVMeSensorMain: Fix sensor object manager path

Change 661d4378467a ("Identify active sensors via the D-Bus "sensors"
service") added a trailing '/' to the path. Remove it, as it breaks
sensor detection by introspection.

Resolves: #23
Fixes: 661d4378467a ("Identify active sensors via the D-Bus "sensors" service")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I6fed1a36b6feae84160cdb5e16a1bdb7cebed262

show more ...

HwmonTempMain: add support TMP100 to sensorTypes

Signed-off-by: Tim Lee <timlee660101@gmail.com>
Change-Id: I6fa3b6f9e1084120481556ce9b41d76d0214440b

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

pwmsensor: Correct the type of MaxValue/MinValue

The MaxValue/MinValue must be double so that redfish can read the value

Before:
{
"@odata.id": "/redfish/v1/Chassis/<chassis>/Thermal#/Fans/0",

pwmsensor: Correct the type of MaxValue/MinValue

The MaxValue/MinValue must be double so that redfish can read the value

Before:
{
"@odata.id": "/redfish/v1/Chassis/<chassis>/Thermal#/Fans/0",
"@odata.type": "#Thermal.v1_3_0.Fan",
"MemberId": "fan0_pwm",
"Name": "fan0 pwm",
"Reading": 25,
"ReadingUnits": "Percent",
"Status": {
"Health": "OK",
"State": "Enabled"
}
},

After:
{
"@odata.id": "/redfish/v1/Chassis/<chassis>/Thermal#/Fans/0",
"@odata.type": "#Thermal.v1_3_0.Fan",
"MaxReadingRange": 100,
"MemberId": "fan0_pwm",
"MinReadingRange": 0,
"Name": "fan0 pwm",
"Reading": 90,
"ReadingUnits": "Percent",
"Status": {
"Health": "OK",
"State": "Enabled"
}
},

ref:
https://github.com/openbmc/phosphor-dbus-interfaces/blob/a134741830/yaml/xyz/openbmc_project/Sensor/Value.interface.yaml#L27-L36

Signed-off-by: David Wang <davidwang@quantatw.com>
Change-Id: I2e1c94648d344988f23aef68fe7a70ad0d7ba3b8

show more ...

hwmontempsensor: Fix DBus update value after power on issue

HwmontempSensor failed to update value on DBus interface when the
state changes from off to on and these sensors are static sensors
(senso

hwmontempsensor: Fix DBus update value after power on issue

HwmontempSensor failed to update value on DBus interface when the
state changes from off to on and these sensors are static sensors
(sensor filesystem created from device-tree setting). When the
condition is satisfied "findI2CDev == devices.end()", it does not
activate those sensors that already exist.

To fix this we move this condition to 'findI2CDev != devices.end()'.
Only check the status of activateOnly and isActive() to make sure these
sensors can be activated after power on.

Tested:
Before
```
root@qbmc:~# ipmitool power status
Chassis Power is on
root@qbmc:~# busctl get-property xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/cputemp xyz.openbmc_project.Sensor.Value Value
d 36.625

root@qbmc:~# ipmitool power off
Chassis Power Control: Down/Off
root@qbmc:~# ipmitool power status
Chassis Power is off
root@qbmc:~# busctl get-property xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/cputemp xyz.openbmc_project.Sensor.Value Value
d nan

root@qbmc:~# ipmitool power on
Chassis Power Control: Up/On
root@qbmc:~# ipmitool power status
Chassis Power is on
root@qbmc:~# busctl get-property xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/cputemp xyz.openbmc_project.Sensor.Value Value
d nan
```

After
Power on this device which was already there, it can get value from
dbus property.
```
root@qbmc:~# ipmitool power status
Chassis Power is on
root@qbmc:~# busctl get-property xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/cputemp xyz.openbmc_project.Sensor.Value Value
d 36.5
root@qbmc:~# busctl get-property xyz.openbmc_project.HwmonTempSensor /xyz/openbmc_project/sensors/temperature/cputemp xyz.openbmc_project.Sensor.Value Value
d 36.625
```

Signed-off-by: Joseph Fu <joseph.fu@quantatw.com>
Change-Id: Ic99c1f2dd292ab99656df06228210d3c714e27d5

show more ...

Properly detect CPU presence in ADCSensor

The ADCSensor daemon in dbus-sensors attempts to determine if an
inventory path is a CPU by just checking for 'cpu' anwhere in the
name.
But for all cpu pat

Properly detect CPU presence in ADCSensor

The ADCSensor daemon in dbus-sensors attempts to determine if an
inventory path is a CPU by just checking for 'cpu' anwhere in the
name.
But for all cpu paths should end with "cpuX" or "CPUx".

Tested:
For a non-CPU path: /xyz/openbmc_project/.../cpu0/xxx
With out this patch: it will mistake this for a CPU path.
With this patch: it will filter out this path.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I0702e306a532f12d8cf646a46eae988205e1d004

show more ...

psusensor: Add support for Delta AHE-50DC fan control module

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

psusensor: Add support for up to four fans

Some PMBus devices, such as the Delta AHE-50DC fan control module, have
more than two fans, so increase the number we support.

Signed-off-by: Zev Weiss <z

psusensor: Add support for up to four fans

Some PMBus devices, such as the Delta AHE-50DC fan control module, have
more than two fans, so increase the number we support.

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

show more ...

fansensor: Add inventory object manager

The fansensor creates fan present objects under
/xyz/openbmc_project/inventory/, add object manager for this path,
otherwise the DBus objects are not created.

fansensor: Add inventory object manager

The fansensor creates fan present objects under
/xyz/openbmc_project/inventory/, add object manager for this path,
otherwise the DBus objects are not created.

Tested: Verify the fan present objects are created in
/xyz/openbmc_project/inventory/

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I1817c5f1de437f0be194dd0bd1d168b1d37f3b70

show more ...

adcsensor: Use unique timer for CPU pres events

If a CPU Present property changes within 1 second of a normal ADC sensor
config being put on D-Bus by entity-manager for the first time, the
single fi

adcsensor: Use unique timer for CPU pres events

If a CPU Present property changes within 1 second of a normal ADC sensor
config being put on D-Bus by entity-manager for the first time, the
single filter timer being used will only call createSensors once. That
sensor will then be ignored since that call to createSensors is only
looking for CPU required sensors.

To fix this, add a separate filter timer for CPU presence changes. That
way the standard ADC sensors will get a chance to be processed in a
createSensors call using UpdateType::init.

Tested: Our IBM systems would hit this issue a lot because there are a
lot of inventory items with 'cpu' in the name so there are a lot of
calls to cpuPresenceHandler. With this fix, the RTC battery voltage
sensor would always be created after a reboot.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Id33587f7b3c9bf29c6e92f64c283b8659293c851

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

IpmbSensor:Add bus index for multiple IPMB bus

IPMB bus is a physical bus which is exposed using IPMB driver. IPMB
is an I2c based serial bus that interconnects the baseboard and
chassis management.

IpmbSensor:Add bus index for multiple IPMB bus

IPMB bus is a physical bus which is exposed using IPMB driver. IPMB
is an I2c based serial bus that interconnects the baseboard and
chassis management.

A BMC that includes IPMB interface support and also provides the
capability for system software to send and receive messages to
and from the IPMB using the BMC as a kind of communication
controller.

In OCP multi-host platform, multiple IPMB bus support is present.
Therefore, for each config, IPMB bus value will be passed from
entity-manager json config file.

Through this IPMB bus, BMC will send and receive messages and then
store the response for each configuration.

Example :
{
"Address": "0x01",
"Bus": "$bus",
"Name": "Temp_Sensor",
"Type": "IpmbSensor"
}

In the current patchset, only IPMB bus value is read and further
implementation using this value will be done in the following
patchset.

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

IPMB GPIO State :
https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/47952

TESTED: Tested on Facebook YosemiteV2 hardware and verified the
IPMB bus value.

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

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

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

PSUSensor: Add regulator devices

Add following device type:
IR38060
IR38164
IR38263
PLI1209BC
XDPE11280

TEST= Build and Boot IBM Genesis3 Board. Sensor
related data i.e., voltage, current, power &

PSUSensor: Add regulator devices

Add following device type:
IR38060
IR38164
IR38263
PLI1209BC
XDPE11280

TEST= Build and Boot IBM Genesis3 Board. Sensor
related data i.e., voltage, current, power & temperature
properly display in webui.

Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I46c06beff370cb4312d4a485e326ea35955b179e

show more ...

Add control ObjectManager to PSUSensor

For platforms that use phosphor-pid-control for PSU fans, apply same
change:
https://github.com/openbmc/dbus-sensors/commit/d90672513d726c63fc57bb48ae06138b307

Add control ObjectManager to PSUSensor

For platforms that use phosphor-pid-control for PSU fans, apply same
change:
https://github.com/openbmc/dbus-sensors/commit/d90672513d726c63fc57bb48ae06138b30793564

Tested:
Build and run on platforms with PSU fan zones defined, swampd starts
successfully.

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

show more ...

Identify active sensors via the D-Bus "sensors" service

Upstream modified how sensors are organized on D-Bus. Sensors are now
mapped under the /xyz/openbmc_project/sensors object. Each service
retri

Identify active sensors via the D-Bus "sensors" service

Upstream modified how sensors are organized on D-Bus. Sensors are now
mapped under the /xyz/openbmc_project/sensors object. Each service
retrieves sensor data via a GetManagedObject call.

Tested:

busctl call -j xyz.openbmc_project.$sensor /xyz/openbmc_project/sensors \
org.freedesktop.DBus.ObjectManager GetManagedObjects
ipmitool sdr dump sdrs.bin

Confirmed neither function resulted in an error message in the journal

Change-Id: I3a41ea2c28b34c9e28abe2f16f6c325ec715dd27
Signed-off-by: Johnathan Mantey <johnathanx.mantey@intel.com>

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

PSUSensor: Add device type TPS53679

Add device type TPS53679 to the allowed list.

Tested: tested on AMD DaytonaX board

Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Change-Id: Ibc101

PSUSensor: Add device type TPS53679

Add device type TPS53679 to the allowed list.

Tested: tested on AMD DaytonaX board

Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Change-Id: Ibc101c616d4083a538e73fdddf03087f6937820e

show more ...

Add control ObjectManager

14ed5e995f2a9893e63a6f83318565102ca3fca7 seems to have exposed the fact
that an ObjectManager is required on the /xyz/openbmc_project/control
namespace. It's not clear why

Add control ObjectManager

14ed5e995f2a9893e63a6f83318565102ca3fca7 seems to have exposed the fact
that an ObjectManager is required on the /xyz/openbmc_project/control
namespace. It's not clear why, and we need to get it documented, but
fix the bug.

Tested: Code compiles. The submitter of this suggestion has tested on
his platform, and it resolves the immediate crash.

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

show more ...

Add ObjectManager in the right place

Per
https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/55308
dbus-sensors has been putting the ObjectManager in the wrong place. Fix
that.

Tested:

Add ObjectManager in the right place

Per
https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/55308
dbus-sensors has been putting the ObjectManager in the wrong place. Fix
that.

Tested:
Loaded build with all patches under this same topic, and observed IPMI
and Redfish trees working correctly and responding with sensor data.

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

show more ...