phosphor-hwmon, branch master

Add frequency capability to hwmon publisher

2018-05-19T11:06:03+00:00

Increase raw fan control steps to avoid fan hunting

2018-05-16T09:05:36+00:00

Enable raw PWM control mode for systems without known fan types

2018-05-16T09:05:36+00:00

Use s.c_str() in log messages

2018-05-14T21:01:54+00:00

Resolves openbmc/openbmc#2905 Tested: static_assert only Change-Id: Iac42db5c4a63116959b8f5fb7b611106e36e51bf Signed-off-by: Joseph Reynolds

.gitignore: Add test-driver

2018-05-07T21:47:51+00:00

Change-Id: I08226c55afaebf0f2633a2a34879589e66fdf9ee Signed-off-by: Matthew Barth

Support indirections other than just "label"

2018-05-07T21:19:53+00:00

The current code only allowed the MODE_ env var to be "label" when doing DBus naming indirection. Add support to allow it to be anything, and then use that value to do the lookup. For example, if MODE_temp1 = "foo", then the code will read the temp1_foo file to find the value to append to LABEL to find the DBus object name. So if temp1_foo contained a 42, then the code will use the LABEL_temp42 var to find the object name. Tested: Test on the OpenPower OCC device which use 'label' and now 'function_id' for the indirections. Change-Id: I1f3115a2d37d008efca74748ac7eff8434d8320a Signed-off-by: Matt Spinler

mainloop: add uniqueness to busname

2018-05-07T15:52:55+00:00

There can be multiple daemon instances that have the same devpath which leads to a collision which errors silently. This adds uniqueness to the path, which was no longer human-readable to avoid this collision situation. Tested: Ran on quanta-q71l with unique devices and two instances pointing to the same device and it correctly set them up with unique but deterministic bus names. Change-Id: Id5aea3c3df5f793b28557a74995608ec40792a43 Signed-off-by: Patrick Venture

Remove OCC EREMOTEIO return code hack

2018-04-27T20:09:34+00:00

With openbmc/openbmc#2329, an OCC sensor value will not be read when the associated fault file is set to true. This will set the value to 0 when a sensor is faulted at startup or not update the previous value during the monitoring loop if the OCC sensor becomes faulted. Applications(i.e. fan control) needing to react to a faulted OCC sensor can subscribe to property changed signals on the OperationalStatus Functional property for the sensor's dbus object. Tested: A faulted OCC sensor has a non-functional status on dbus Change-Id: Ia43ebb1e0fe0227797bc4034e617ac357edd348d Signed-off-by: Matthew Barth

Refresh sensor functional state

2018-04-27T20:09:34+00:00

During the monitoring loop, the associated fault file of a sensor is read and its functional status is updated prior to reading the sensor's input file. Tested: The functional property is updated according to its fault file Resolves: openbmc/openbmc#2329 Change-Id: Icc28e914df79c6681d45e92a5ea4054704ad8efd Signed-off-by: Matthew Barth

Skip updating value for faulted sensors

2018-04-27T20:09:34+00:00

When a sensor is marked as faulted, the input value is skipped from being read and updated in the sensor's dbus object during the monitoring loop. This keeps the sensor's value set to its previously known state. The hwmon documentation states that when a sensor input channel presents an associated fault file, the measurement value provided for that channel should not be trusted when the fault boolean has a value of 1. Not updating the sensor value follows this specification. Tested: A non-functional sensor's input value is not read A non-functional sensor's value state in dbus object is not updated Any functional sensor's input value is read during monitoring Any functional sensor's value state is updated during monitoring All sensors without a fault sysfs file are read/updated normally Change-Id: Iccf3e4e44125d6e481ce91c8f63e8f0e4ee3df4b Signed-off-by: Matthew Barth