summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* hwmonio:: Add Interface base class and testsPatrick Venture2018-06-149-28/+318
| | | | | | | | | | Enable injecting hwmonio::HwmonIO mocks for testing. Tested: Ran on quanta-q71l and saw all sensors exported to dbus as expected with the expected values. Change-Id: I35912bf2a733932d9e1e774ff53b0114ae16560b Signed-off-by: Patrick Venture <venture@google.com>
* Add documentation pointer to READMEMatt Spinler2018-06-061-0/+1
| | | | | Change-Id: Ibc3798c8d764bf59ce5ef00f115605bcfd03412a Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Move sensor adjust within sensor objectMatthew Barth2018-06-043-43/+47
| | | | | | | | | | | | | All sensor adjustments should be contained within the sensor object for the sensor. This allows the adjustments to be retrieved for a given sensor and applied accordingly. Tested: No change in adjusting a sensor value No change in removing a sensor given a removal return code Change-Id: I5e1e40fe41b4064422a47178aec1f297b781566d Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add EMSGSIZE to the list of retryable errorsEddie James2018-06-011-0/+9
| | | | | | | | | | | | Some devices return -EMSGSIZE if the hardware is being powered off in a normal manner, as incomplete data is received. Retrying allows time for the system to clean up driver devices, or in the event of a real failure, attempt to get the rest of the data. Resolves openbmc/openbmc#3226 Change-Id: Ib507acf4cbd4094e4369e15b8519058c57a74bc2 Signed-off-by: Eddie James <eajames@us.ibm.com>
* Move value iface creation into sensor objectMatthew Barth2018-05-243-135/+165
| | | | | | | | | | | | Create the Sensor.Value interface for a sensor within the sensor object. Each sensor must have an input sysfs file to get a Value property on the Sensor.Value interface and be included by hwmon. Tested: No change in value interface creation for sensors Change-Id: I09b1c79142ba2a34424f5ec29f41d19a987c84e7 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Move status iface creation into sensor objectMatthew Barth2018-05-243-29/+36
| | | | | | | | | | | | | For sensors that have a status interface created with a functional property set according to its fault sysfs file value, the object associated with the sensor should contain the creation of this interface. Tested: No change in status interface creation for sensors Change-Id: Ic3c0a81c661ac481b90ad9bd4c8bf415dae3520e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add sensor object frameworkMatthew Barth2018-05-225-6/+54
| | | | | | | | | | Create a sensor object to store sensor monitoring specifications. Tested: Sensor objects are created and stored for each sensor Change-Id: Idfa982f1bb8da888abbd473881870df4beec6824 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add MAINTAINERS fileAndrew Jeffery2018-05-181-0/+47
| | | | | Change-Id: I21fd38620b72c984bbe8afdca71fd17c65fcb144 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* Use s.c_str() in log messagesJoseph Reynolds2018-05-141-1/+1
| | | | | | | | | Resolves openbmc/openbmc#2905 Tested: static_assert only Change-Id: Iac42db5c4a63116959b8f5fb7b611106e36e51bf Signed-off-by: Joseph Reynolds <jrey@us.ibm.com>
* .gitignore: Add test-driverMatthew Barth2018-05-071-0/+1
| | | | | Change-Id: I08226c55afaebf0f2633a2a34879589e66fdf9ee Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Support indirections other than just "label"Matt Spinler2018-05-073-6/+16
| | | | | | | | | | | | | | | | | | | 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-073-6/+17
| | | | | | | | | | | | | 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-274-31/+6
| | | | | | | | | | | | | | | | | 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-276-1/+124
| | | | | | | | | | | | | | | | | 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-252-17/+44
| | | | | | | | | | | | | | | | | | | 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-2412-317/+353
| | | | | | | | 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>
* hwmon module unit-tests -- first onePatrick Venture2018-04-245-2/+35
| | | | | | | | This patchset just starts the process of adding unit-tests to the hwmon module. Change-Id: I569aa97658b0ff56634ddf1a599fedb4caa95abe Signed-off-by: Patrick Venture <venture@google.com>
* test: moved to toolsPatrick Venture2018-04-2410-168/+23
| | | | | | | | | | | Moved the current test folder to tools and started a new test folder. This will allow for rapid introduction of new unit-tests into phosphor-hwmon. The tools folder contains small tools to aid in phosphor-hwmon configuration and misc. This folder will go under review at another time. Change-Id: Ice18ffb5cdcbd519d49088e233a8082a9410b03e Signed-off-by: Patrick Venture <venture@google.com>
* sysfs: cleanup: add missing namespace commentPatrick Venture2018-04-241-1/+1
| | | | | | | Namespace was missing terminator comment. Change-Id: I9a35742fbdf5c0cdf162dfead0e86864b635a9ab 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-232-18/+63
| | | | | | | | | | | | | | 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-184-95/+115
| | | | | | | | 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-184-14/+24
| | | | | | | | | | | | | | 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-186-12/+23
| | | | | | | | 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>
* Update configure.ac to fix gtestPatrick Venture2018-04-181-2/+9
| | | | | | | | Updated the configure.ac to match the example and this fixed gtest. Change-Id: I246f5e4da257a0475c69505fd357d7441087b525 Signed-off-by: Patrick Venture <venture@google.com>
* No retries when adding a purposely removed sensorMatthew Barth2018-04-132-4/+12
| | | | | | | | | | | | | | 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>
* Remove OCC EAGAIN workaroundMatthew Barth2018-04-131-8/+1
| | | | | | | | | | | | | | | | The ability to handle an EAGAIN for a sensor from the OCC device can be done by defining the EAGAIN return code(11) as a sensor removal return code within each OCC config file. This return code can be defined at the device level within the config file to be applied across all sensors the OCC provides. Tested: OCC sensors are removed from Dbus when EAGAIN is returned Resolves openbmc/openbmc#2327 Change-Id: If16ec37da6d960d54de1d47af3a39944249df772 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-132-73/+72
| | | | | | | | | | 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-132-164/+218
| | | | | | | | | | | | | | | 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>
* README: Reword cleaning the repoGunnar Mills2018-04-121-1/+1
| | | | | | | Reworded cleaning the repo. The old wording did not make sense. Change-Id: I6d0859b7c7cb325abf3940b21324211b1e9b3757 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
* performance: setup sysfs read independent of D-BusDeepak Kodihalli2018-04-092-93/+126
| | | | | | | | | | | | | | | | | | | | | | 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 a Timer classDeepak Kodihalli2018-04-093-1/+178
| | | | | | | | The class provides for a timer, callback invocation on timer expiry, and timer control/cleanup. This will be used in subsequent commits. Change-Id: Ieb04e5ec76a1023efa2c3f5c5b88f03e9819c3eb Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
* Add configure option for how read fails behavePatrick Venture2018-03-303-0/+28
| | | | | | | | | | | | | | | | 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-224-6/+38
| | | | | | | | | | | | | | | | | | | 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>
* Find hwmon path based on input path typeMatt Spinler2018-03-072-4/+13
| | | | | | | | | | | | | | | | If the input path starts with /devices, find the hwmon path using the findHwmonFromDevPath function, otherwise use findHwmonFromOFPath. Also change the argument name to something more generic. Did not change the argument's short name so the service file isn't coupled to this change. Tested: Tested with both paths. Change-Id: I5feb8a897fc86117b102ce44584ed977282cb955 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add findHwmonFromDevPath()Matt Spinler2018-03-073-0/+57
| | | | | | | | | | | | | | | | | | This function can find the hwmon path from a /devices path. This path is similar to what udev lists as the device path, but with the /hwmon/hwmonN directories removed from the end. In addition, any ':' characters in the path have been converted to '--', so the code needs to convert them back. This is done because some devices are not in the device tree, and hence wouldn't have the open firmware device path that the code previously only supported. Tested: Tested with the new /devices path. Change-Id: Ic26646c6f609323cff86d4cd10bbe0a44d7d61ac Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Rename functionMatt Spinler2018-03-054-5/+5
| | | | | | | | | | | A future commit will add a new function to find the hwmon device from a different type of path, so clarify the current function name in preparation. Tested: Compiled Change-Id: I3c990f4a91b12e592e22818b085dcd3736e5fcde Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Make it possible to choose the target interfaceMatt Spinler2018-02-262-6/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 pwm id as fan pwm targetLei YU2018-02-021-35/+22
| | | | | | | | | | | | | | | | | | | The current code assumes fan and pwm has the same id. This commit add the support to use pwmX as fan pwm target by PWM_TARGET_ environment. E.g. PWM_TARGET_fan0 = "1" PWM_TARGET_fan1 = "1" PWM_TARGET_fan2 = "2" PWM_TARGET_fan3 = "2" The above config tells hwmon to set pwm1 for fan0/1's pwm target, and set pwm2 for fan2/3's pwm target. Change-Id: Ic1d850ca3d6d20274d905fa9004d7eba2718e9eb Signed-off-by: Lei YU <mine260309@gmail.com>
* Add fan pwm interface targetPatrick Venture2018-02-019-16/+202
| | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud