| commit | da98f095f25cc75af3c0268643bde2b21f5503e0 | [log] [tgz] |
|---|---|---|
| author | Zhikui Ren <zhikui.ren@intel.com> | Mon Nov 01 09:41:08 2021 -0700 |
| committer | Zhikui Ren <zhikui.ren@intel.com> | Wed Nov 10 14:26:08 2021 -0800 |
| tree | b61c06857bc0e6a050de547ea5488bb227b5e530 | |
| parent | 45f844ac6ca41a6ed452fdc8add009d816e14665 [diff] |
psusensor: fix psu pwm sensor name
Current bug is that psusensor service does not create pwm sensor object
if pid fan configuration has spaces in Name field, like
{
...
"Name" : "PSU$BUS $ADDRESS Fan 1"
"Outputs": [
"Pwm PSU$BUS $ADDRESS Fan 1"
],
...
}
Fix:
Pwm name need to be escaped, which currently replaces " " with "_"
before being passed to CreatePwmSensor in PSUSensor service.
PwmSensor constructor takes the name as is.
Since the escape algorithm may change in the future,
add a helper function escapeName() and update dbus-sensors
to use this helper funtion when sensors are created.
escapeName() currently calls boost replace_all_copy(name," ", "_"),
so it does not introduce functional changes except the bug identified
above.
Tested:
No regression found for existing working sensors.
Sensors are created as before with the same sensor name.
Fix for non-working case works correctly now.
psu pwm sensor name with space are created correctly with the change.
busctl tree xyz.openbmc_project.PSUSensor
...
|-/xyz/openbmc_project/control
| `-/xyz/openbmc_project/control/fanpwm
| |-/xyz/openbmc_project/control/fanpwm/Pwm_PSU17_2_Fan_1
| |-/xyz/openbmc_project/control/fanpwm/Pwm_PSU17_2_Fan_2
...
Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
Change-Id: If3b60f93de324e59cc3d774285c23bf50a6f989c
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