summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Add MAINTAINERS fileAndrew Jeffery2018-05-211-0/+46
| | | | | Change-Id: Iee7a92941638d2b147eef2f0e85f9c90f638003c Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* utility: Remove getService functionMatthew Barth2018-05-172-59/+1
| | | | | | | | | | The getService function is no longer used and is not necessary with the getService function within sdbusplus.hpp Tested: N/A Change-Id: Ifad8ec1efb64508923d4f5c42bef318f0b03124c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* utility: Remove getInvService functionMatthew Barth2018-05-172-14/+0
| | | | | | | | | | The getInvService function is no longer used and is not necessary with the getService function within sdbusplus.hpp Tested: N/A Change-Id: Ibb2d55ef5be1852ae8ebd3dac32d66518d5d705c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* cooling-type: Use lookupAndCallMethodMatthew Barth2018-05-173-21/+18
| | | | | | | | | | | | | Have phosphor-cooling-type fail with a DBusMethodError exception when a failure occurs on updating inventory. Resolves: openbmc/openbmc#2628 Tested: Cooling type properties still set correctly Change-Id: Ia7e3379fc7d75c70e9c71d4f940f9da84b9f5774 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use setProperty function in fan set speedMatthew Barth2018-05-171-25/+8
| | | | | | | | | | | | | | | | When a fan's target speed is set, using the setProperty function allows for better handling of dbus failures setting the fan target property. If a failure occurs setting this property, a journal entry is created and a DBusPropertyError exception is thrown to allow the fan control application to exit and restart quickly in its allowed attempts configured in systemd. Tested: Fan control application logs an error to the journal and then terminates when a dbus error occurs setting a fan target speed. Change-Id: Ibd4bd8b18b6010727831d97e32c14fd6c681e170 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Throw DBusPropertyError for all property accessesMatthew Barth2018-05-172-7/+100
| | | | | | | | | | | | | On all get/set property functions, when an error occurs performing the access of a property, throw a DBusPropertyError exception containing the identifying parameters of the property. Tested: DBusPropertyError exception occurs on failing to set a property DBusPropertyError exception occurs on failing to get a property Change-Id: I9882d62d75153b4320a8d4a21ba7a52efbdd0af2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add set property functions without mapper lookupMatthew Barth2018-05-171-0/+44
| | | | | | | | Tested: Property set with provided service name Change-Id: I158d33f85602f48d1dfe8baa7ce54eec6e8f8296 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Call method and return functionMatthew Barth2018-05-171-0/+21
| | | | | | | | | | | | Add a function that calls a method and returns the response message without checking for an error. Its up to the user of this function to check if response.is_method_error() exists and handle accordingly. Tested: Method is called and raw response is returned Change-Id: I6678a78d8cfb32d2d13dba7cb48719fd26eccebc Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* perf: Cache service name for fan target sensorsMatthew Barth2018-05-172-30/+14
| | | | | | | | | | | Cache the service name for each fan target sensor path and use that service when a new target speed is set on the Target property. Tested: Fan target sensor created and set speed functions the same Change-Id: I3e25e355cf5d31ce814a73c801c6f086fa45531a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use shared callMethod function in control managerMatthew Barth2018-05-172-25/+8
| | | | | | | | | | | | | To better handle exit/restart of the fan control application use the shared callMethod function to call systemd's startunit on the fan control ready target. This allows the fan control application to exit and restart quickly in its allowed attempts configured in systemd. Tested: StartUnit on fan control ready target works the same Change-Id: Idce2d8831b4e8de0ef181a0849587e465419f68c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use shared getProperty function in control managerMatthew Barth2018-05-171-51/+7
| | | | | | | | | | | | When the manager checks a getProperty condition for fan control, it should use the shared getProperty function that now returns a DbusMethodError to better exit/restart the fan control application. Tested: Condition check functions the same Change-Id: I37f83ef4273343bd527ac149ac5eee213d0ad63d Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* perf: Count state of properties before set speedMatthew Barth2018-05-171-18/+19
| | | | | | | | | | | | Once the number of properties at a given state are at/above the given number allowed, set the fan speed and stop checking the remaining properties. Tested: Action function results are unchanged Change-Id: Icfd347703c973b12f4b7806ea1ba84056f987253 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Enhance precondition function and tracingMatthew Barth2018-05-161-3/+12
| | | | | | | | | | | | | | | | Replace count_if with all_of in the property states match precondition to stop iterating over the group members once a property state does not match. Include additional debug tracing when the precondition passes and fails to help in determining where the precondition causes fans to be at full speed. Tested: Verify debug traces align with precondition state Change-Id: I1c3d8f096a645ac3bfcdfb7b9197682cf7ca52a0 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Move generated code template to fileMatthew Barth2018-05-113-234/+251
| | | | | | | | | | | | | | In preparation of enhancing the generated code format, the template used has been externalized and will continue to be modified in future commits to parse & generate more efficiently. Tested: Generated code remains unchanged Resolves openbmc/phosphor-fan-presence#8 Change-Id: Ifbf718e8a22acb2f2f939bbdcc2e7fe041e9ed58 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Remove property change traceMatthew Barth2018-05-091-5/+0
| | | | | | | | | | | | | | Fan control is required to be configured for all possible temperature sensors within a machine type, however not every configuration of that machine type contains all of those sensors. The trace removed here was filling the journal with unnecessary entries for sensors that are expected to not be present. Tested: Journal entry is not longer traced Change-Id: Iccb85ae7e9463ee03522ce4efde6410ed14a76ca Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Throw custom exceptions on D-Bus method failuresMatt Spinler2018-05-096-44/+130
| | | | | | | | | | | | | | | | | | | | | All 3 fan applications - control, monitor, and presence have cases where it is expected that a getProperty call may fail because a sensor is missing. While the applications already handle this, the InternalFailure exception that was being thrown by the underlying call generates log entries that make it look like something bad happened. The custom exceptions now being thrown do not log anything on creation, but store all of the failing information so that any callers could still log the info if they wanted to. Tested: Boot a water cooled Witherspoon and see the fan presence and monitor applications not look like they are failing. Boot a system without the fan hwmon running, and see fan-control-init still show the fails. Change-Id: Ifd8ad6e3deb492bbaf33f12c7258125dce1e5ea8 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Presence: Fix a log metadata entryMatt Spinler2018-05-091-1/+1
| | | | | Change-Id: I2d7b154de98bef1cb518d036496828c57a391144 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add generation of propertiesMatch conditionMatthew Barth2018-05-032-1/+50
| | | | | | | | | | | | | | | | | Update the mako template to generate conditions within the FanDefinition sections when a condition is defined for a fan. Each supported condition function's parameters are generated within a `getCondParams` mako method, allowing easy support of additional conditions with differing parameters. Tested: A given condition's function and parameters generate correctly No condition function is generated on a fan where not defined Resolves: openbmc/openbmc#2976 Change-Id: I3f0b30702fdcef6749929d85543270863eb26381 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Support optional conditions on creating fansMatthew Barth2018-05-035-2/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the functional infrastructure to optionally attach a condition function to a fan definition. When a condition is defined on a fan, it must be true for a fan's associated functional properties to be created. When the given condition fails, that fan's functional properties will not be created by fan monitor. A fan without a defined condition will have all of its associated functional properties created. Example of generated condition (generation commit to follow): make_condition(condition::propertiesMatch( std::vector<PropertyState>{ PropertyState{ PropertyIdentity{ "/xyz/openbmc_project/inventory/system/chassis", "xyz.openbmc_project.Inventory.Decorator.CoolingType", "WaterCooled" }, static_cast<bool>(false) } } )), Tested: Fan functional properties are not created when a condition fails Fan functional properties are created when condition passes Fan functional properties are created when no condition exists Change-Id: I9ced2e520d2f97e6655c9417970b3e976d78fef4 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add methods to return property variantMatthew Barth2018-05-031-0/+77
| | | | | | | | | | | | Create methods to return a property variant for use where the overloaded comparison operations are needed against a property value stored as a variant. Tested: A property is looked up and returned as the given variant type Change-Id: Iab557781a3ab9e33d3595ad69db5544a25efe2eb Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Rename remove object interface functionMatthew Barth2018-04-122-3/+3
| | | | | | | | | | Update the removeObjIntf function name to removeObjectInterface. This was requested per a review comment. Tested: N/A Change-Id: I52589724685bb5b8d92d3da22072b63b43f69a01 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Generate InterfacesRemoved signal eventsMatthew Barth2018-03-301-4/+12
| | | | | | | | | | | | | | | | | | | | In the case that an interface containing a property used within an event is removed from dbus, that event can subscribe to the InterfacesRemoved signal. When an InterfacesRemoved signal is received by fan control, the corresponding interface (and all associated properties) is removed from the cache used by all events. *Note: This area of signal subscription/handling code generation is intended to be re-worked under openbmc/openbmc#2911. This is the reason for supporting a different yaml layout for the InterfacesRemoved signal. Tested: Generated code constructs InterfacesRemoved signals correctly Resolves openbmc/openbmc#2223 Change-Id: Idc3e8db4e7dc07a2bb6898d3cc30ab775362dd35 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add InterfacesRemoved signal handlingMatthew Barth2018-03-304-0/+129
| | | | | | | | | | | | | | | When an InterfacesRemoved signal is received for a subscribed object path, each interface returned is checked against the interface which was defined for each object on the event. When these are equal, the interface (and all associated properties) are removed from the shared cache of event properties. Tested: Manually added an InterfacesRemoved signal Verified interface was removed from object path in cache Change-Id: I348d82f14e0cfba2b18a81a9f54c6cb06b586797 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Minimize service name mapper lookupsMatthew Barth2018-03-122-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Retrieve the service names from the cached dataset within the zone for a path and interface, updating the cache when not found. This is used when initializing property values and service name owners. Additional performance enhancements to use `GetSubTree` prior to processing a set speed event will be included under openbmc/openbmc#2911. This will keep unnecessary `GetSubTree` lookups from occurring for paths/interfaces that don't exist to further improve upon initializing properties fan control is defined to use. Tested: First path updates service name cache for all paths sharing the same interface First missing interface on a path updates service name cache for all paths sharing that interface Verify mapper lookups for X number of paths sharing the same interface is reduced to (X-(X-1)) NameOwnerChanged events read/update the same set of service name cache Change-Id: Ia235b36ba5ae8cda38342d7521f3d87080c2970a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Get a property without service name lookupMatthew Barth2018-03-121-0/+40
| | | | | | | | | | | Expand on the current getProperty functions to allow a service name to be passed in so a mapper lookup is not necessary. Tested: A property value is read from a message where the service is given Change-Id: Ia0450163744c9f89a26a053ec2cfb44ae761426d Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Cache service names for paths and interfacesMatthew Barth2018-03-122-0/+122
| | | | | | | | | | | | | | | | To lookup a service name for a given path and interface, use GetSubTree to retrieve all the service names from the root path for the interface and add each entry to a cached dataset. Tested: Check that a missing interface's service is added Check that a missing path that exists has its service added Inspect all missing paths for an interface are added Inspect missing interfaces are added to existing service Returned service name matches the service for a path/interface Change-Id: I6db05479e825350198896b2e237882f7ebc58d51 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add GetSubTree method for single interfaceMatthew Barth2018-03-061-0/+38
| | | | | | | | | | | | Perform a GetSubTree mapper call and return the mapper response structure as is for a single interface over a given path subtree depth. Tested: Returned subtree structure matches mapper structure for an interface Returned subtree data matches mapper data for an interface Change-Id: If6b66433a331ac20633ac99c458eb5edb653bff2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Make event actions optionalMatthew Barth2018-03-061-2/+5
| | | | | | | | | | | | | | | | | | Event actions should be made optional for events that only require subscribing to group signals. This is in preparation for separating signal and timer based event actions. A use case would be where one event can be used to subscribe to signals that update cached property values without performing an action, and another timer based event performs an action based on those property values the signal event provides. Tested: Events without an action are generated correctly Events without an action are handled correctly and run no action Change-Id: I757a82ce6c45ac637ce7cea8f82a62b98b600e3e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Parse a list of groups with zone conditionsMatthew Barth2018-03-061-198/+219
| | | | | | | | | | | | | | | Set speed events can use a list of groups associated with its actions where each group defines what zone conditions the group should be included in actions. Tested: List a single group within an event List two groups within an event with different zone conditions List two groups within an event in the same zone conditions List more than two groups with different zone conditions Change-Id: Ifba30e116f92d945f8812c15e856a5e772e077f2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Handle timer expiration on state changesMatthew Barth2018-03-011-19/+17
| | | | | | | | | | | | | | | | | | Update to start all tach sensor functional state change timers on a fan where the corresponding state and inventory is updated when the timer expires. Only start the timer in nonfunctional mode when a tach sensor is out of range and is currently functional and start the functional mode timer when its in range and currently nonfunctional. Tested: Tach sensors are marked nonfunctional as normal. Tach sensors are updated to functional after 5sec(yaml test value) Nonfunctional timer is cancelled if fan returns within spec Functional timer is cancelled if fan returns out of spec Change-Id: I88622d07d8713f88e8070940a4bd96046a053fb5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Define a mode for tach sensor timerMatthew Barth2018-03-014-14/+67
| | | | | | | | | | | | | | Use a single timer on the tach sensors for delaying both nonfunctional and functional state changes by declaring what mode the timer is in. Since a fan is either transitioning from a functional state to a nonfunctional state or vice-versa, enabling the timer in the mode requested allows the user to define a delay for both of these transition states. Tested: Current nonfunctional timer delay operates the same Change-Id: I0c165355d41d27e1906918953e5226968062ee16 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add tach sensor functional delayMatthew Barth2018-03-016-4/+21
| | | | | | | | | | | | | | Add ability to define a delay to marking a tach sensor as functional when it transitions from a nonfunctional state. Essentially this gives the option to wait a given amount of time that a tach sensor must be within the allowed deviation before being updated to functional. Default functional delay = 0 seconds Tested: Current fan definition values function the same Change-Id: I58bf70d2335e27c06037b755cbee8dae81528a5a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* NonzeroSpeed: Check trust determination sensorsMatthew Barth2018-03-012-6/+11
| | | | | | | | | | | | Only include defined trust determination sensors in checking the group trust. Tested: Current trust group associations & reactions are unchanged Combination of sensors included and excluded in trust determination Change-Id: I0f610b2910ffda849871a9ac9be95f2c056d8248 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Replace tuple with struct for trust sensor groupMatthew Barth2018-03-012-12/+16
| | | | | | | | | | | To simplify sensor and trust access, utilize a struct in place of a tuple for storing the trust group sensors and their inclusion in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: Ifd5cf5d0540a3b2028ccf74e725d8ddd11982aee Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Generate sensor to trust associationMatthew Barth2018-03-013-21/+34
| | | | | | | | | | | | | | | | | Each sensor listed to be associated with a trust group is defined to either be part of the trust group or just affected by the results of the trust group. This is denoted by defining an "in_trust" boolean attribute that will include the sensor in the trust group for determination of trust when true, otherwise only be included in the resulting trust affect when defined as false. When no "in_trust" attribute is given, the sensor is defaulted to be included in the trust group determining trust. Tested: Current trust group associations & reactions are unchanged Change-Id: I717074bc1a32a07dc59f172a4c823c7e2bb84f8c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* optimize: Tach sensors as shared pointersMatthew Barth2018-03-015-13/+12
| | | | | | | | | | | | | The fan and trust group objects should utilize shared pointers to the tach sensor objects. This allows optimizing the storage of additional attributes associated with the tach sensors. e.g. An attribute to declare which sensors should be included in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: I249cc7debf467e8275fae7fa157ce97078b40802 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add target interface for fan controlLei YU2018-02-265-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Current fan control assumes the use of the FanSpeed interface for fan targets. For fans controlled by pwm, FanPwm interface is added. This commit adds "target_interface" config parameter, so that user can specify the interface for the fan targets. E.g. - inventory: /system/chassis/motherboard/fan0 cooling_zone: 0 cooling_profile: air sensors: - fan0 target_interface: xyz.openbmc_project.Control.FanPwm The config is optional and defaults to FanSpeed, so the current code will not be affected. Tested: Use this config on Romulus, ensures the fan control sets target on FanPwm interface and works fine. Change-Id: I73adccaa770d657b5d7aaeb307917f89588524de Signed-off-by: Lei YU <mine260309@gmail.com>
* Add target interface for fan monitorLei YU2018-02-266-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | Current fan monitor assumes the use of the FanSpeed interface for fan targets. For fans controlled by pwm, FanPwm interface is added. This commit adds a "target_interface" config parameter, so that user can specify the interface for the fan targets. E.g. - name: fan0 has_target: true target_interface: xyz.openbmc_project.Control.FanPwm This config is optional and defaults to FanSpeed, so the current code will not be affected. Tested: Use this config on Romulus, ensures fan monitor gets fan target from FanPwm interface and works OK. Change-Id: I262a486c335b2b43a46af7abdd0e71e95a133b98 Signed-off-by: Lei YU <mine260309@gmail.com>
* Add factor and offset for fan monitorLei YU2018-02-266-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For fans controlled via pwm, the fan target and speed are different, where the fan target is pwm and the speed is rpm. Usually it is a linear mapping from pwm to rpm. So this commit defines the optional configs, factor and offset for calculating the expected fan speed from target, e.g. - name: fan0 has_target: true factor: 21 offset: 1600 The fan monitor service will calculate expected fan speed as: target * factor + offset The default value is 1 for factor and 0 for offset if they are not defined. Tested: Use this config together with the following commit's changes, test on Romulus and ensures the fan monitor works OK; Without this config, fan monitor always mark fans as non-functional due to the fan speed does not match the pwm value. Change-Id: If5e25368b4530df7a7face9377efb58804db21df Signed-off-by: Lei YU <mine260309@gmail.com>
* Set tach sensor to functional on startMatthew Barth2018-01-304-71/+78
| | | | | | | | | | With the addition of a functional state for each fan rotor tach sensor, these should be set to functional on each power on. This is done during fan monitor init mode when no monitor is done and then again once monitoring mode begins. Change-Id: I3c73c1be5f912c7cee8499f47cc799ac3c20983b Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Support properties of type stringMatthew Barth2018-01-292-8/+32
| | | | | | | | | | | | Properties used within set speed events may be of type string to trigger an action. These should be handled where the defined type attribute is given as 'std::string' and a parsed value is an instance of python str type. Resolves openbmc/openbmc#292 Change-Id: Ib188e7abc212062a1c61950abaa28434a4726521 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use setFunctional when tach sensor is constructedMatthew Barth2018-01-231-2/+1
| | | | | Change-Id: I32e30dc8f659172026258ca533099404c90aebbc Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Remove getTargetSpeedMatthew Barth2018-01-232-21/+2
| | | | | | | | The getTargetSpeed function is no longer needed. The tach sensors are used to get the target speed. Change-Id: I5f82b0c3e8104203e2700b22a5488cf63673d181 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* All sensors should return a target speed valueMatthew Barth2018-01-184-28/+44
| | | | | | | | | | | | | All tach sensors associated with a fan should return a target speed sensor from its getTarget function. In the case where a target speed sensor does not exist for the tach sensor, it retrieves and returns the target speed value from the fan where the fan finds the target speed value from a tach sensor the fan contains that provides it. Resolves openbmc/openbmc#2784 Change-Id: Iea5561b0aad6942be52af262c7255c60e5e75c7a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Decreases allowed based on all groupsMatthew Barth2017-12-143-30/+58
| | | | | | | | | | | | | | | For speed decreases to occur, all sensor groups involved with setting a net decrease delta must be below their given t-control low values for the associated zone. This handles the case where one or more sensor groups' temperatures stabilize above their t-control low value, but one or more other sensor groups' temperatures are below their t-control low value which would result in speed decrease requests that could eventually lead to fan speed oscillations. Resolves openbmc/openbmc#2710 Change-Id: I382de5d3f9c3e631a332d49dfcb06e705ff6fc17 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add path to trace for missing propertyMatthew Barth2017-12-111-1/+2
| | | | | | | | When a property can not be found after receiving a property changed signal include the path for the property on the journal entry. Change-Id: Ie0151b943914e02d38bf89760f8a16dc530aa89e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use Ceiling speed as request baseMatthew Barth2017-12-111-0/+5
| | | | | | | | | When determining the request base speed for speed decreases, the current ceiling speed should be used when the request base speed is above the ceiling. Change-Id: Iefc2f1669b853e099fbda15dc8c8983f5f1f269a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set tach sensor inventory functional stateMatthew Barth2017-12-052-7/+12
| | | | | | | | | | | At startup, initialize the functional state of each tach sensor to true and then update the inventory's functional state to match the tach sensor's functional state. Resolves openbmc/openbmc#2629 Change-Id: If608e4c044d9eeaa3dbdafa22bc89327e323c9a8 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add functional property for each tach sensorMatthew Barth2017-12-054-2/+47
| | | | | | | | | | | | Each fan's tach sensor creates a child inventory object under the fan's inventory path containing the sensor's functional state. This child inventory object path is the fan's path plus the tach sensor's defined id. i.e.) /xyz/openbmc_project/inventory/system/chassis/motherboard/fan0/fan0_0 Change-Id: I0fe5000eadbe55d60b475ccad700b0264ed0ac75 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update fan inventory methodMatthew Barth2017-12-054-52/+60
| | | | | | | | | Use the methods provided within sdbusplus.hpp to update fan inventory along with prepping inventory to be updated for each fan rotor sensor's functional state. Change-Id: I7d3026d289b1dd22cd4e7b4457c4d4396309c0b5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
OpenPOWER on IntegriCloud