| commit | 62084c81755eae0a4fe59e1c8d255d376fe3d8f4 | [log] [tgz] |
|---|---|---|
| author | Josh Lehan <krellan@google.com> | Mon Jun 22 15:27:12 2020 -0700 |
| committer | Josh Lehan <krellan@google.com> | Wed Jun 24 20:34:41 2020 +0000 |
| tree | 435b54cb4bbc657a4af93acc735b4ff2955a4ab9 | |
| parent | 9a44547ef3ccb02eb6a3dd4f4b5b01f2c5db7402 [diff] |
psusensor: Update sensorTypes and sync with pmbusNames Trivial patch, to update sensorTypes array, keeping it in sync with pmbusNames array, and sorting both arrays alphabetically. Question, why are there two arrays here? The sensorTypes array could be programmatically generated from pmbusNames easily. If interest, I will make another patch to do this. Question, what is special about the "pmbus" driver name, which does not correspond to a sensor chip, unlike the others? Question, why is pmbusNames in lowercase but sensorTypes is in all caps, except for "pmbus"? Is there a reason for this, or is it just a convention that evolved that way? Signed-off-by: Josh Lehan <krellan@google.com> Change-Id: I9fbc4fb65a0c3a69d43eef2e873169e522f11748
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