summaryrefslogtreecommitdiffstats
path: root/mainloop.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Support indirections other than just "label"Matt Spinler2018-05-071-4/+11
| | | | | | | | | | | | | | | | | | | The current code only allowed the MODE_<type><Num> 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 <spinler@us.ibm.com>
* mainloop: add uniqueness to busnamePatrick Venture2018-05-071-6/+10
| | | | | | | | | | | | | 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 <venture@google.com>
* Remove OCC EREMOTEIO return code hackMatthew Barth2018-04-271-13/+4
| | | | | | | | | | | | | | | | | 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 <msbarth@us.ibm.com>
* Refresh sensor functional stateMatthew Barth2018-04-271-1/+7
| | | | | | | | | | | | | | 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 <msbarth@us.ibm.com>
* Skip updating value for faulted sensorsMatthew Barth2018-04-271-3/+14
| | | | | | | | | | | | | | | | | | | | | 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 <msbarth@us.ibm.com>
* Fault status check before reading sensor valueMatthew Barth2018-04-271-14/+26
| | | | | | | | | | | | | | | | | | | | | Checking for the fault sysfs file should be done prior to reading the input value when creating the sensor's dbus object. A sensor providing a fault sysfs file will have a status interface functional property created with its initial functional state. A sensor in a nonfunctional state when the object is created, will have an initial value of 0. 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. Using an initial value of 0 follows this specification and allows the corresponding dbus object to be created. Tested: Faulted sensor at hwmon start shows functional status of false. Faulted sensor at hwmon start contains a sensor value of 0. Change-Id: I6388a3f84f638360b03e557aadc6de8331e67a69 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add status interface to sensorsMatthew Barth2018-04-271-0/+4
| | | | | | | | | | | | | | | | | When a fault sysfs file is present for a sensor, the OperationalStatus interface is attached to the sensor object. The functional property is initially set to the corresponding value read from the fault sysfs file when the sensor object is created. A follow-up commit will address updating the functional property based on reading the fault sysfs file during the polling interval. Tested: OperationalStatus interface created for sensors with fault files Interface not created for sensors without fault file Functional property set to correct value from sensor's fault file Change-Id: Id75b3711d048d4667d2173a3255512cf5482ab67 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Return sensor object state data as optionalMatthew Barth2018-04-251-16/+35
| | | | | | | | | | | | | | | | | | | Previously, the getObject function moved the sensor data passed in as a constant reference, which should not have been done. The intention of the getObject function is to retrieve the sensor's object state data. Then, the necessary sensor data and the created object state data can be appropriately handled for monitoring. This change is to remove this confusion and clearly create the sensor's object state data without modifying the sensor set data passed in to getObject. Tested: Sensor objects are still created correctly Sensor states are monitoring and updated as before Change-Id: I19fc22fa79094d749e7d5f3b2693094e245b5a4a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* hwmonio: split IoAccess object outPatrick Venture2018-04-241-4/+5
| | | | | | | | Split out the hwmon io access object from the sysfs namespace into its own. Change-Id: I8d1a45630117d1d503d0d5fa6061163911b695e8 Signed-off-by: Patrick Venture <venture@google.com>
* mainloop cleanup: added std namespace where missingPatrick Venture2018-04-241-3/+4
| | | | | | | | | A few calls into libc weren't wrapped with the standard namespace. This will ensure they are the calls intended via the wrapped cpp libraries. Change-Id: I966b5d2133efe6c0ac56701a2a60eef6d6d7f6e0 Signed-off-by: Patrick Venture <venture@google.com>
* Get sensor identifiers functionMatthew Barth2018-04-231-18/+44
| | | | | | | | | | | | | | To minimize handling the return cases when getting a sensor object, retrieve the sensor identifiers from a function. The identifiers returned are then checked to be valid before proceeding in creating the sensor object. Tested: Sensor objects created the same Empty id or label cause sensor object to not be created Change-Id: I7c2f0df3fee99448af5365e0a40c4282f9a235fa Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Check for empty return code list on addingMatthew Barth2018-04-231-18/+11
| | | | | | | | | | | | | Move the check for an empty return code list for sensor removal to within the function that adds the return codes per sensor. This eliminates the need to check for an empty return code list prior to calling this function. Tested: Empty return code sensor removal list is handled Change-Id: Icdf3692cd79b3198d90ad8c0688104e4a8040186 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* mainloop cleanup: moved getAttrs to hwmon namespacePatrick Venture2018-04-181-94/+12
| | | | | | | | Moved the code that maps a sensor type to its dbus and hwmon components from mainloop to the hwmon namespace. Change-Id: I7963951c9484c02d17a3eb415906859609e0efd3 Signed-off-by: Patrick Venture <venture@google.com>
* move calls to cstdlib::getenv to env::getEnvPatrick Venture2018-04-181-5/+5
| | | | | | | | | | | | | | Wrapped the cstdlib::getenv() call into env::getEnv so that it can be tested by mocking the env namespace, by just dropping in test_env.cpp which implements those methods and tying them a singleton upon which we can set expectations. Note: regardless of the approach taken to mock this, wrapping this method is a good fix. Change-Id: I65d22da08fc3dd76e6860f728c54e6c847ed07de Signed-off-by: Patrick Venture <venture@google.com>
* move getEnv methods into env namespacePatrick Venture2018-04-181-8/+8
| | | | | | | | Move the getEnv(...) methods into the env namespace, for consistency. Change-Id: I4055d9456c17f8b20071cdee1b8e531c10fb0c7e Signed-off-by: Patrick Venture <venture@google.com>
* mainloop: Add some helpful commentsPatrick Venture2018-04-181-0/+3
| | | | | | | | | Added a couple helpful comments that save someone from reading the code and thinking about it to know what it does. Change-Id: Ieac770e99fbd75a42be6803ee7959aba6ad6e96a Signed-off-by: Patrick Venture <venture@google.com>
* No retries when adding a purposely removed sensorMatthew Barth2018-04-131-4/+11
| | | | | | | | | | | | | | When a sensor is removed due to a removal return code being received during a read, no read retries should be done when attempting to re-add it. This requires the sensor to be successful in its first read attempted when being re-added and keeps the re-adding of purposely removed sensors from consuming up to 1 second during the re-add attempt. Tested: A removed sensor is attempted to be read once on re-add Change-Id: Ia7eb463deb569c9d10883632e017b4dd05413854 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Trace return code driven remove/add of sensorsMatthew Barth2018-04-131-18/+39
| | | | | | | | | | | | | | | A review comment request was to trace to the journal each time a sensor is removed given a return code for removal and when that sensor is re-added. Request->https://gerrit.openbmc-project.xyz/#/c/9823/2/mainloop.cpp Tested: Verify journal entry created when sensor is removed Verify journal entry created when sensor is re-added Change-Id: I258bc98da7970080771762717f6a9383f4c68942 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Check TARGET_MODE on target sensorsMatthew Barth2018-04-131-41/+5
| | | | | | | | | | Move the TARGET_MODE config entry to be done on target specific sensors. Tested: Target sensors are still created for the mode given in TARGET_MODE Change-Id: I7731b73e14495360ccb5b8fb8ada59176e9125d3 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Include monitoring removed sensors for re-addingMatthew Barth2018-04-131-7/+4
| | | | | | | | | | | | | | | | | When a sensor returns a defined return code causing it to be removed during the monitoring loop, it should be re-added once the sensor is successfully read not producing any of the defined return codes. Once the sensor is re-added, it is erased from the removed list of sensors. When a sensor continues to return a defined return code, it remains in the removed sensor list and is attempted to be added after each completion of the monitoring loop. Tested: Verify sensor is removed when return code received during monitoring Sensor object added after successful read with no return codes Change-Id: Id286d4b1f1e11e1148ad4182dd9726d3c348c9de Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Attempt adding sensors with initial read error rcMatthew Barth2018-04-131-164/+206
| | | | | | | | | | | | | | | Sensors that initially returned a read error return code defined to not have the sensor added to dbus should be attempted to be added after the monitoring loop for all device sensors has ended. When a sensor object that was not created due to this is successfully added to dbus, the sensor is removed from the removal list. Tested: Verify a sensor with a defined return code returned is not added A sensor not initially created is added when successfully read Change-Id: I5188500fc1a1cdfbcfdb8b3d76e144955489c8fa Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Remove sensors for given return codesMatthew Barth2018-04-131-40/+65
| | | | | | | | | | | | | A sensor defined to be removed for a given set of return codes is not added or is removed from dbus when any of those return codes are received while attempting to do a read. Tested: Sensor is not created when return code received Sensor is removed when return code received Change-Id: I095800dea943360c2990f395105c150e0eda6eb6 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Store sensor return codes for dbus removalMatthew Barth2018-04-131-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add any return codes defined at the device level and/or the sensor within the hwmon device config file for removal of the sensor. The sensor is removed from dbus when any of those return codes given are received by hwmon when doing a read. ex.) Removal return codes 2 & 11 defined at device level apply for all sensors(gpu0 core & mem) whereas removal return code 5 applies to only the the gpu0 core temp sensor. REMOVERCS = "2,11" LABEL_temp1 = "gpu0_core_temp" WARNHI_temp1 = "75000" WARNLO_temp1 = "0" CRITHI_temp1 = "80000" CRITLO_temp1 = "0" REMOVERCS_temp1 = "5" LABEL_temp2 = "gpu0_mem_temp" WARNHI_temp2 = "75000" WARNLO_temp2 = "0" CRITHI_temp2 = "80000" CRITLO_temp2 = "0" Tested: All device sensors contain removal return code defined on the device Each sensor contains removal return codes defined on them Change-Id: Ib0bf1e38ae40aaaea06e93d96322f9499eeefdb1 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* performance: setup sysfs read independent of D-BusDeepak Kodihalli2018-04-091-89/+110
| | | | | | | | | | | | | | | | | | | | | | Previously, phosphor-hwmon had a polling loop to read the sysfs - it would wakeup every second or when a D-Bus event occurs (in which case it would service D-Bus and then read sysfs). This causes successive D-Bus calls to slow down, because hwmon would be busy in the loop, reading sysfs, after servicing D-Bus. To solve this, schedule the sysfs read independently of the D-Bus event loop : add a timer handler to an sd event loop, and attach the D-Bus event loop to the sd event loop. Tested: An example of how this helped : the 'dcmi sensors' command (to read 50 temperature sensors) would take more than 60 seconds on Witherspoon (based off of master 00f02f3). With this patch, the time taken is about 15 seconds. Resolves openbmc/openbmc#2985. Change-Id: I5f512ed11cb6f5f5d2455863ac8e62b5ada16c7a Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
* Add configure option for how read fails behavePatrick Venture2018-03-301-0/+10
| | | | | | | | | | | | | | | | Different platforms have different requirements for handling hwmon sysfs access failures. The default behavior is that a read failure leads to the daemon exiting after some number of read failures. This can be controlled to then remove the object from the dbus on failure. Now, it can instead be controlled to return -errno on read failure. This new behavior to set the value to -errno must be checked by whatever mechanism is reporting the value. Change-Id: I50b93aea56f22267da79c9571319f281e24a1e6f Signed-off-by: Patrick Venture <venture@google.com>
* Handle OCC EAGAIN & EREMOTEIO in 4.13Matthew Barth2018-03-221-4/+13
| | | | | | | | | | | | | | | | | | | This is a temporary fix until the following issues are completed: openbmc/openbmc#2327 openbmc/openbmc#2329 When an EAGAIN or an EREMOTEIO return code is received by hwmon from the OCC driver in the 4.13 kernel, they should be translated to an unavailable sensor(0x00) and failed sensor(0xFF) scaled values respectively. This will keep the OCC hwmon instance running and allow applications to continue using these sensors as they were reported under the mainline openbmc/linux 4.10 kernel. Tested: Verified return codes are caught and sensor value modified Change-Id: Ie61859863e7d88878caa942e5f5b062acabe67aa Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Make it possible to choose the target interfaceMatt Spinler2018-02-261-6/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | The current code will always try to add a FanSpeed interface if an <X>_target sysfs file is present, and a FanPwm interface if a pwm<X> file is present. For devices that have both types of files, it will create both interfaces, and since each have a Target property, it can cause REST calls which get these properties to return the wrong one, as they can't select the interface to use. To fix this, allow a TARGET_MODE environment variable to be specified to select which target to try to create, either RPM or PWM. If TARGET_MODE isn't there, default to the current behavior of creating an interface for whichever sysfs file type is exposed, so the code doesn't limit what is created. Tested: Set TARGET_MODE to RPM and then PWM in the config file, and ensure only the 1 interface is created. Remove that entry from the config file, and ensure it still works as it does today. Change-Id: I2983e514c86c8d4fb785648520a913339daf6c8f Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Read MaxValue and MinValue from configurationJames Feist2018-02-221-0/+11
| | | | | | | | | Read MaxValue and MinValue from enviroment variables file. With this change MAXVALUE_temp1 and MINVALUE_temp1 for example can be read from the configuration and added to dbus. Change-Id: Ic7c2ba57ae65415bb154c617b13866d661969e5a Signed-off-by: James Feist <james.feist@linux.intel.com>
* Add fan pwm interface targetPatrick Venture2018-02-011-1/+9
| | | | | | | | | | | | | | The current daemon only supports RPM-based fan control, whereas the hwmon interface for PWM is often present. This implements the Fan Control PWM dbus interface. This CL is not the complete solution, but if mixed with a follow-on CL that does this, I think it'll be ideal. For instance, this assumes the pwm number matches, whereas the other CL lets you specify the corresponding PWM target for the fan. Change-Id: I23aaa0619cdefba0a004ac0d26dc6b928e78f1e8 Signed-off-by: Patrick Venture <venture@google.com>
* Support reading 64 bit integersMatt Spinler2017-11-291-3/+3
| | | | | | | | | | | | | Some sysfs *_input values may be bigger than 32 bits, for example power values reported in microwatts. As such, read an int64_t value out of sysfs instead of just a uint32_t. The D-Bus property that will hold the value is also the same type, an int64_t. Resolves openbmc/openbmc#2686 Change-Id: I4376de120825b73580d18d339fe76be454eeb18d Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Claim a stable well known busnameBrad Bishop2017-11-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch readd instances claim a busname with a format of: xyz.openbmc_project.Hwmon.Hwmon<N> where N is the hwmon sysfs class instance. This is problematic for client applications that cache sensor object busname mappings for objects provided by readd. When readd instances restart (due to udev events) the hwmon sysfs class index may have changed, resulting in clients connecting to the wrong service instance. Address this by ensuring readd instances claim the same name every time they are started: xyz.openbmc_project.Hwmon-<ID>.Hwmon1 Where ID is a std::hash of the /sys/devices path backing the hwmon instance. Additionally, add a trailing API version as recommended best practice by the D-Bus specification. Change-Id: Idd0057ce883a49c1e828fb54fede27ea14022d6a Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* Read fan target sysfs value on startupMatt Spinler2017-10-241-1/+1
| | | | | | | | | | | | | | | When creating the object that represents the Control.FanSpeed interface for a fan, read the target fan speed out of sysfs and save it in the object so it shows up in D-Bus immediately. Previously the Target property would have a value of zero until another application wrote it, leaving a window where the D-Bus property wouldn't match the underlying sysfs file value. Change-Id: I08b149840c2cf731bc48f89118622fa63222600e Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Pass discrete type/ID values into addThresholdMatt Spinler2017-10-171-2/+2
| | | | | | | | The ID has to be looked up separately in some cases so can't always be the ID specified in the key_type object. Change-Id: I7f5b395ec3db2182fe84df24047bfae64fcee479 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Refactor method of looking up indirect labelsMatt Spinler2017-10-171-11/+15
| | | | | | | | | | | | Use a combination of getIndirectID() and getEnv() when looking up labels when their values are specified in sysfs files instead of getIndirectLabelEnv(). This is done so the ID is exposed and can be used later for looking up thresholds. Change-Id: I4d2399bb7717130e61a8aacc37e75f36f410c94e Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Remove old TODOMatt Spinler2017-10-171-2/+1
| | | | | | | This ended up being handled completely outside of hwmon. Change-Id: I54d322761a90a6efb033b9994974b4d1933bf88e Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Log the failing sysfs filenameMatt Spinler2017-10-091-0/+19
| | | | | | | | | | | | | Add the name of the sysfs path an access failed on to the journal when an error log is created. This is useful for debug. An example of the path in the journal metadata is: FILE=/sys/class/hwmon/hwmon7/temp1_input Change-Id: I4bc3548619e561cd3acc95ba3ecc778fb08c7104 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Enhancement to support GAIN and OFFSET value for sensor readingChiabing Lee2017-09-141-0/+40
| | | | | | | | | | | | | | | | | | | | | | For example, AST BMC chips ADC input voltage range is 0 to 2.5V, good nominal input voltage is 1.8V. Other voltages are scaled into that range using external resistors(ADC voltage divider). Since the values of these resistors can change from their own motherboard design, the conversions cannot be hard coded into the Linux driver and have to be done in user space. In the sensor configuration file, add the GAIN_in[0-*] and OFFSET_in[0-*] value. The sensor reading conversion can be: value = (raw sensor reading) * gain + offset Resolves: openbmc/openbmc#2259 Change-Id: I2502c656e0d34dd69b9c795788505f209a77a72b Signed-off-by: Chiabing Lee <chiabinglee@gmail.com> Signed-off-by: Lei YU <mine260309@gmail.com>
* sysfs IO enhancementsBrad Bishop2017-09-081-49/+11
| | | | | | | | | | | | | | | | | | Add retries for some sysfs IO errors: EIO: Tolerate intermittant device or bus failures. ETIMEDOUT: Tolerate intermittant timeouts. EAGAIN: Tolerate drivers that do not block. ENXIO: Tolerate momentarily unplugged devices on busses that don't support hotplug. EBADMSG: Tolerate CRC errors. Flush stdio buffers after writes. Remove redundant retry and delay constants. Resolves: openbmc/openbmc#2262 Change-Id: I2104139bf7ced96bb10f7450b42ca36e61c84287 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* Use hwmonio for attribute IOBrad Bishop2017-08-311-51/+76
| | | | | | | | | | Moves disparate error handling scenarios from the method doing the IO to the call point. Resolves openbmc/openbmc#2166 Change-Id: I3b6d2e175433dd8b2946ae60381901f2d7ca1798 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* mainloop: Cache devpath at startupBrad Bishop2017-08-311-0/+2
| | | | | | | | | | Currently the devpath is determined after a bus error to make a callout. Finding the path at startup is less prone to race conditions around ENOENT on driver unload in the event of a callout. Change-Id: I8ce8d9f630c8b7ecc398082002aa113ab352d3cb Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* Add configure option to control how fails behaveMatt Spinler2017-08-101-0/+13
| | | | | | | | | | | | | | | | | Different platforms have different requirements for handling hwmon sysfs access failures. The default behavior is now that the application will terminate if a hardware read fails, and rely on systemd restarting it as a way of doing retries. The new configure option --enable-remove-from-dbus-on-fail will cause the application to remove the property permanently from D-Bus and never try to access it again, but not fail out. This was the previous (recently added) default behavior. Change-Id: I6367f2e3e072a2ca9a3da700d4de1b6c34b219ff Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Allow EAGAIN failuresMatt Spinler2017-07-281-18/+45
| | | | | | | | | | | | | | Certain devices are known to return EAGAIN failures when read too frequently, so be tolerant of them. On startup, the code will retry for up to a second to get a good first reading, and then in the main loop the code will just stick with the current value if it fails that way. Resolves openbmc/openbmc#2038 Change-Id: I7621aa30429c43276239982a03ec3eef02ce9c6e Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Don't exit program on sysfs read failures.Patrick Venture2017-07-271-31/+71
| | | | | | | | | | | | | | | | | | | | | We have an unreliable fan in one of the test systems and at present if the sysfs entry is unavailable or returns failure, then the program will exit. The program could be serving many sensors, and any one failure will cause it to exit. This is true not only when initially creating the sensors, but also if any sensor read fails at run-time. Testing: I verified the program logged the failures, which may not be ideal if there is a buggy sensor, but, I also ran it and managed to catch it where the sensor wasn't there initially and it cleanly reported only the sensors that were responsive and didn't just exit. There is certainly a case to be made for re-scanning periodically if the sensor returns or there was a timing issue, and there is a separate bug for that. This commit means only to make the program more robust on failure. Change-Id: I310a3e3c0e0ea86e439341a296b741ded18f46f2 Signed-off-by: Patrick Venture <venture@google.com>
* Add a level of indirection when naming the DBUS objectsTom Joseph2017-06-141-6/+27
| | | | | | | | | | | | The current design ignores the itemX_label sysfs attribute, if the environment variable is populated with the MODE_itemX="label", then fetch the label from itemX_label file.The actual label for the dbus object is fetched from the environment variable LABEL_item<label>. Resolves openbmc/openbmc#1633 Change-Id: I0d4baaa91073dd5db75ac62277d78ad9b3065e64 Signed-off-by: Tom Joseph <tomjoseph@in.ibm.com>
* Introduce interval configuration for sensor reads.Patrick Venture2017-06-051-4/+9
| | | | | | | | | | | | | | | | | This introduces the ability to specify in the sensor label configuration file, a specific sleep interval. The interval is in this file to allow straightforward interval control over the sensors listed in that file. Sensors grouped in the same file are treated as a group and run within the same instance. Tested: I tested setting the interval in one of four running configurations and the change was picked up in that configuration while the others ran at the default interval. Resolves openbmc/phosphor-hwmon#5 Change-Id: Ia9e474bc446090c8ac95dc2e6bf23a4fd6ccf7b7 Signed-off-by: Patrick Venture <venture@google.com>
* Exit early if no sensors matched.Patrick Venture2017-05-231-0/+6
| | | | | | | | | | | | | | | | | | | Previously, if it finds that there are no sensors or no matching labels it would create the bus and then spin on the interval indefinitely doing nothing but occupying precious memory. Not that this is a case that is likely to happen in real-use, but it is a reasonable edge execution case that can be easily addressed. I ran into this when trying to momentarily stop it from reading the fans while I was running timing code. I had simply commented out the fan labels, but the program ran anyway -- now it didn't read the fans, but it seemed odd that it didn't simply exit when it had nothing to do. There is a comment about checking for new sensors in the map, but this idea isn't fully fleshed out. Therefore, in the interim, this is a perfectly reasonable execution flow modification. Change-Id: Idd2a9568b09148ffffe1af5c00193a0f394ec6a6 Signed-off-by: Patrick Venture <venture@google.com>
* Write pwmX_enable for fans that have a fanX_targetMatt Spinler2017-05-111-1/+7
| | | | | | | | | | | | | | | | | | For fans that have a fanX_target hwmon sysfs attribute, write the pwmX_enable on startup to put that fan into RPM mode, which is safe to do because this application requires that the target is written in RPMs. The write will only occur if the pwm_enable file exists. In the future, if fans with a target need to run in pwm mode, this code will need to be updated to convert between RPM and pwm anyway and the pwm_enable value can then be different based on that. Resolves openbmc/openbmc#1584 Change-Id: I4f6f3ac8d6651314367aaf5c51ac176220f1fba6 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Update hwmon fan target sysfs entriesMatthew Barth2017-03-301-7/+2
| | | | | | | | | | | | | Override the default FanSpeed.Target set implementation so when a target value is written to the FanSpeed interface it is also updated in the related fan target sysfs file. This sets a particular fan to the given target speed. Resolves openbmc/openbmc#962 Resolves openbmc/phosphor-hwmon#1 Change-Id: I867811737269b3f42d2a0dc15b37782a74f147b8 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Create a FanSpeedObject interfaceMatthew Barth2017-03-301-0/+10
| | | | | | | | | Create the FanSpeedObject target interface when the fanx_target sysfs file exists. The "xyz.openbmc_project.Control.Target" interface is on the /xyz/openbmc_project/sensors/fan_tac/fan[#] object paths. Change-Id: Ib4a099cff17cacea501b474969f292516db212b5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Change constexpr function pointers to static constantsSaqib Khan2017-03-201-0/+29
| | | | | | | | | | | Note: Newer version of gcc no longer supports constexpr function pointers to be declared in the header file. Therefore we fixed this by declaring them as static constants in the header file and moved the initialization to the source file. Change-Id: Ied87c62b14be79cc268cfe8c63e8f2385c7e75b6 Signed-off-by: Saqib Khan <khansa@us.ibm.com>
OpenPOWER on IntegriCloud