sysfs-api.txt 24 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585
  1. Generic Thermal Sysfs driver How To
  2. ===================================
  3. Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
  4. Updated: 2 January 2008
  5. Copyright (c) 2008 Intel Corporation
  6. 0. Introduction
  7. The generic thermal sysfs provides a set of interfaces for thermal zone
  8. devices (sensors) and thermal cooling devices (fan, processor...) to register
  9. with the thermal management solution and to be a part of it.
  10. This how-to focuses on enabling new thermal zone and cooling devices to
  11. participate in thermal management.
  12. This solution is platform independent and any type of thermal zone devices
  13. and cooling devices should be able to make use of the infrastructure.
  14. The main task of the thermal sysfs driver is to expose thermal zone attributes
  15. as well as cooling device attributes to the user space.
  16. An intelligent thermal management application can make decisions based on
  17. inputs from thermal zone attributes (the current temperature and trip point
  18. temperature) and throttle appropriate devices.
  19. [0-*] denotes any positive number starting from 0
  20. [1-*] denotes any positive number starting from 1
  21. 1. thermal sysfs driver interface functions
  22. 1.1 thermal zone device interface
  23. 1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *type,
  24. int trips, int mask, void *devdata,
  25. struct thermal_zone_device_ops *ops,
  26. const struct thermal_zone_params *tzp,
  27. int passive_delay, int polling_delay))
  28. This interface function adds a new thermal zone device (sensor) to
  29. /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the
  30. thermal cooling devices registered at the same time.
  31. type: the thermal zone type.
  32. trips: the total number of trip points this thermal zone supports.
  33. mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
  34. devdata: device private data
  35. ops: thermal zone device call-backs.
  36. .bind: bind the thermal zone device with a thermal cooling device.
  37. .unbind: unbind the thermal zone device with a thermal cooling device.
  38. .get_temp: get the current temperature of the thermal zone.
  39. .set_trips: set the trip points window. Whenever the current temperature
  40. is updated, the trip points immediately below and above the
  41. current temperature are found.
  42. .get_mode: get the current mode (enabled/disabled) of the thermal zone.
  43. - "enabled" means the kernel thermal management is enabled.
  44. - "disabled" will prevent kernel thermal driver action upon trip points
  45. so that user applications can take charge of thermal management.
  46. .set_mode: set the mode (enabled/disabled) of the thermal zone.
  47. .get_trip_type: get the type of certain trip point.
  48. .get_trip_temp: get the temperature above which the certain trip point
  49. will be fired.
  50. .set_emul_temp: set the emulation temperature which helps in debugging
  51. different threshold temperature points.
  52. tzp: thermal zone platform parameters.
  53. passive_delay: number of milliseconds to wait between polls when
  54. performing passive cooling.
  55. polling_delay: number of milliseconds to wait between polls when checking
  56. whether trip points have been crossed (0 for interrupt driven systems).
  57. 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
  58. This interface function removes the thermal zone device.
  59. It deletes the corresponding entry from /sys/class/thermal folder and
  60. unbinds all the thermal cooling devices it uses.
  61. 1.1.3 struct thermal_zone_device *thermal_zone_of_sensor_register(
  62. struct device *dev, int sensor_id, void *data,
  63. const struct thermal_zone_of_device_ops *ops)
  64. This interface adds a new sensor to a DT thermal zone.
  65. This function will search the list of thermal zones described in
  66. device tree and look for the zone that refer to the sensor device
  67. pointed by dev->of_node as temperature providers. For the zone
  68. pointing to the sensor node, the sensor will be added to the DT
  69. thermal zone device.
  70. The parameters for this interface are:
  71. dev: Device node of sensor containing valid node pointer in
  72. dev->of_node.
  73. sensor_id: a sensor identifier, in case the sensor IP has more
  74. than one sensors
  75. data: a private pointer (owned by the caller) that will be
  76. passed back, when a temperature reading is needed.
  77. ops: struct thermal_zone_of_device_ops *.
  78. get_temp: a pointer to a function that reads the
  79. sensor temperature. This is mandatory
  80. callback provided by sensor driver.
  81. set_trips: a pointer to a function that sets a
  82. temperature window. When this window is
  83. left the driver must inform the thermal
  84. core via thermal_zone_device_update.
  85. get_trend: a pointer to a function that reads the
  86. sensor temperature trend.
  87. set_emul_temp: a pointer to a function that sets
  88. sensor emulated temperature.
  89. The thermal zone temperature is provided by the get_temp() function
  90. pointer of thermal_zone_of_device_ops. When called, it will
  91. have the private pointer @data back.
  92. It returns error pointer if fails otherwise valid thermal zone device
  93. handle. Caller should check the return handle with IS_ERR() for finding
  94. whether success or not.
  95. 1.1.4 void thermal_zone_of_sensor_unregister(struct device *dev,
  96. struct thermal_zone_device *tzd)
  97. This interface unregisters a sensor from a DT thermal zone which was
  98. successfully added by interface thermal_zone_of_sensor_register().
  99. This function removes the sensor callbacks and private data from the
  100. thermal zone device registered with thermal_zone_of_sensor_register()
  101. interface. It will also silent the zone by remove the .get_temp() and
  102. get_trend() thermal zone device callbacks.
  103. 1.1.5 struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
  104. struct device *dev, int sensor_id,
  105. void *data, const struct thermal_zone_of_device_ops *ops)
  106. This interface is resource managed version of
  107. thermal_zone_of_sensor_register().
  108. All details of thermal_zone_of_sensor_register() described in
  109. section 1.1.3 is applicable here.
  110. The benefit of using this interface to register sensor is that it
  111. is not require to explicitly call thermal_zone_of_sensor_unregister()
  112. in error path or during driver unbinding as this is done by driver
  113. resource manager.
  114. 1.1.6 void devm_thermal_zone_of_sensor_unregister(struct device *dev,
  115. struct thermal_zone_device *tzd)
  116. This interface is resource managed version of
  117. thermal_zone_of_sensor_unregister().
  118. All details of thermal_zone_of_sensor_unregister() described in
  119. section 1.1.4 is applicable here.
  120. Normally this function will not need to be called and the resource
  121. management code will ensure that the resource is freed.
  122. 1.1.7 int thermal_zone_get_slope(struct thermal_zone_device *tz)
  123. This interface is used to read the slope attribute value
  124. for the thermal zone device, which might be useful for platform
  125. drivers for temperature calculations.
  126. 1.1.8 int thermal_zone_get_offset(struct thermal_zone_device *tz)
  127. This interface is used to read the offset attribute value
  128. for the thermal zone device, which might be useful for platform
  129. drivers for temperature calculations.
  130. 1.2 thermal cooling device interface
  131. 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name,
  132. void *devdata, struct thermal_cooling_device_ops *)
  133. This interface function adds a new thermal cooling device (fan/processor/...)
  134. to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
  135. to all the thermal zone devices registered at the same time.
  136. name: the cooling device name.
  137. devdata: device private data.
  138. ops: thermal cooling devices call-backs.
  139. .get_max_state: get the Maximum throttle state of the cooling device.
  140. .get_cur_state: get the Currently requested throttle state of the cooling device.
  141. .set_cur_state: set the Current throttle state of the cooling device.
  142. 1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
  143. This interface function removes the thermal cooling device.
  144. It deletes the corresponding entry from /sys/class/thermal folder and
  145. unbinds itself from all the thermal zone devices using it.
  146. 1.3 interface for binding a thermal zone device with a thermal cooling device
  147. 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
  148. int trip, struct thermal_cooling_device *cdev,
  149. unsigned long upper, unsigned long lower, unsigned int weight);
  150. This interface function binds a thermal cooling device to a particular trip
  151. point of a thermal zone device.
  152. This function is usually called in the thermal zone device .bind callback.
  153. tz: the thermal zone device
  154. cdev: thermal cooling device
  155. trip: indicates which trip point in this thermal zone the cooling device
  156. is associated with.
  157. upper:the Maximum cooling state for this trip point.
  158. THERMAL_NO_LIMIT means no upper limit,
  159. and the cooling device can be in max_state.
  160. lower:the Minimum cooling state can be used for this trip point.
  161. THERMAL_NO_LIMIT means no lower limit,
  162. and the cooling device can be in cooling state 0.
  163. weight: the influence of this cooling device in this thermal
  164. zone. See 1.4.1 below for more information.
  165. 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
  166. int trip, struct thermal_cooling_device *cdev);
  167. This interface function unbinds a thermal cooling device from a particular
  168. trip point of a thermal zone device. This function is usually called in
  169. the thermal zone device .unbind callback.
  170. tz: the thermal zone device
  171. cdev: thermal cooling device
  172. trip: indicates which trip point in this thermal zone the cooling device
  173. is associated with.
  174. 1.4 Thermal Zone Parameters
  175. 1.4.1 struct thermal_bind_params
  176. This structure defines the following parameters that are used to bind
  177. a zone with a cooling device for a particular trip point.
  178. .cdev: The cooling device pointer
  179. .weight: The 'influence' of a particular cooling device on this
  180. zone. This is relative to the rest of the cooling
  181. devices. For example, if all cooling devices have a
  182. weight of 1, then they all contribute the same. You can
  183. use percentages if you want, but it's not mandatory. A
  184. weight of 0 means that this cooling device doesn't
  185. contribute to the cooling of this zone unless all cooling
  186. devices have a weight of 0. If all weights are 0, then
  187. they all contribute the same.
  188. .trip_mask:This is a bit mask that gives the binding relation between
  189. this thermal zone and cdev, for a particular trip point.
  190. If nth bit is set, then the cdev and thermal zone are bound
  191. for trip point n.
  192. .binding_limits: This is an array of cooling state limits. Must have
  193. exactly 2 * thermal_zone.number_of_trip_points. It is an
  194. array consisting of tuples <lower-state upper-state> of
  195. state limits. Each trip will be associated with one state
  196. limit tuple when binding. A NULL pointer means
  197. <THERMAL_NO_LIMITS THERMAL_NO_LIMITS> on all trips.
  198. These limits are used when binding a cdev to a trip point.
  199. .match: This call back returns success(0) if the 'tz and cdev' need to
  200. be bound, as per platform data.
  201. 1.4.2 struct thermal_zone_params
  202. This structure defines the platform level parameters for a thermal zone.
  203. This data, for each thermal zone should come from the platform layer.
  204. This is an optional feature where some platforms can choose not to
  205. provide this data.
  206. .governor_name: Name of the thermal governor used for this zone
  207. .no_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
  208. is required. when no_hwmon == false, a hwmon sysfs interface
  209. will be created. when no_hwmon == true, nothing will be done.
  210. In case the thermal_zone_params is NULL, the hwmon interface
  211. will be created (for backward compatibility).
  212. .num_tbps: Number of thermal_bind_params entries for this zone
  213. .tbp: thermal_bind_params entries
  214. 2. sysfs attributes structure
  215. RO read only value
  216. RW read/write value
  217. Thermal sysfs attributes will be represented under /sys/class/thermal.
  218. Hwmon sysfs I/F extension is also available under /sys/class/hwmon
  219. if hwmon is compiled in or built as a module.
  220. Thermal zone device sys I/F, created once it's registered:
  221. /sys/class/thermal/thermal_zone[0-*]:
  222. |---type: Type of the thermal zone
  223. |---temp: Current temperature
  224. |---mode: Working mode of the thermal zone
  225. |---policy: Thermal governor used for this zone
  226. |---available_policies: Available thermal governors for this zone
  227. |---trip_point_[0-*]_temp: Trip point temperature
  228. |---trip_point_[0-*]_type: Trip point type
  229. |---trip_point_[0-*]_hyst: Hysteresis value for this trip point
  230. |---emul_temp: Emulated temperature set node
  231. |---sustainable_power: Sustainable dissipatable power
  232. |---k_po: Proportional term during temperature overshoot
  233. |---k_pu: Proportional term during temperature undershoot
  234. |---k_i: PID's integral term in the power allocator gov
  235. |---k_d: PID's derivative term in the power allocator
  236. |---integral_cutoff: Offset above which errors are accumulated
  237. |---slope: Slope constant applied as linear extrapolation
  238. |---offset: Offset constant applied as linear extrapolation
  239. Thermal cooling device sys I/F, created once it's registered:
  240. /sys/class/thermal/cooling_device[0-*]:
  241. |---type: Type of the cooling device(processor/fan/...)
  242. |---max_state: Maximum cooling state of the cooling device
  243. |---cur_state: Current cooling state of the cooling device
  244. Then next two dynamic attributes are created/removed in pairs. They represent
  245. the relationship between a thermal zone and its associated cooling device.
  246. They are created/removed for each successful execution of
  247. thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device.
  248. /sys/class/thermal/thermal_zone[0-*]:
  249. |---cdev[0-*]: [0-*]th cooling device in current thermal zone
  250. |---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
  251. |---cdev[0-*]_weight: Influence of the cooling device in
  252. this thermal zone
  253. Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
  254. the generic thermal driver also creates a hwmon sysfs I/F for each _type_
  255. of thermal zone device. E.g. the generic thermal driver registers one hwmon
  256. class device and build the associated hwmon sysfs I/F for all the registered
  257. ACPI thermal zones.
  258. /sys/class/hwmon/hwmon[0-*]:
  259. |---name: The type of the thermal zone devices
  260. |---temp[1-*]_input: The current temperature of thermal zone [1-*]
  261. |---temp[1-*]_critical: The critical trip point of thermal zone [1-*]
  262. Please read Documentation/hwmon/sysfs-interface for additional information.
  263. ***************************
  264. * Thermal zone attributes *
  265. ***************************
  266. type
  267. Strings which represent the thermal zone type.
  268. This is given by thermal zone driver as part of registration.
  269. E.g: "acpitz" indicates it's an ACPI thermal device.
  270. In order to keep it consistent with hwmon sys attribute; this should
  271. be a short, lowercase string, not containing spaces nor dashes.
  272. RO, Required
  273. temp
  274. Current temperature as reported by thermal zone (sensor).
  275. Unit: millidegree Celsius
  276. RO, Required
  277. mode
  278. One of the predefined values in [enabled, disabled].
  279. This file gives information about the algorithm that is currently
  280. managing the thermal zone. It can be either default kernel based
  281. algorithm or user space application.
  282. enabled = enable Kernel Thermal management.
  283. disabled = Preventing kernel thermal zone driver actions upon
  284. trip points so that user application can take full
  285. charge of the thermal management.
  286. RW, Optional
  287. policy
  288. One of the various thermal governors used for a particular zone.
  289. RW, Required
  290. available_policies
  291. Available thermal governors which can be used for a particular zone.
  292. RO, Required
  293. trip_point_[0-*]_temp
  294. The temperature above which trip point will be fired.
  295. Unit: millidegree Celsius
  296. RO, Optional
  297. trip_point_[0-*]_type
  298. Strings which indicate the type of the trip point.
  299. E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
  300. thermal zone.
  301. RO, Optional
  302. trip_point_[0-*]_hyst
  303. The hysteresis value for a trip point, represented as an integer
  304. Unit: Celsius
  305. RW, Optional
  306. cdev[0-*]
  307. Sysfs link to the thermal cooling device node where the sys I/F
  308. for cooling device throttling control represents.
  309. RO, Optional
  310. cdev[0-*]_trip_point
  311. The trip point in this thermal zone which cdev[0-*] is associated
  312. with; -1 means the cooling device is not associated with any trip
  313. point.
  314. RO, Optional
  315. cdev[0-*]_weight
  316. The influence of cdev[0-*] in this thermal zone. This value
  317. is relative to the rest of cooling devices in the thermal
  318. zone. For example, if a cooling device has a weight double
  319. than that of other, it's twice as effective in cooling the
  320. thermal zone.
  321. RW, Optional
  322. passive
  323. Attribute is only present for zones in which the passive cooling
  324. policy is not supported by native thermal driver. Default is zero
  325. and can be set to a temperature (in millidegrees) to enable a
  326. passive trip point for the zone. Activation is done by polling with
  327. an interval of 1 second.
  328. Unit: millidegrees Celsius
  329. Valid values: 0 (disabled) or greater than 1000
  330. RW, Optional
  331. emul_temp
  332. Interface to set the emulated temperature method in thermal zone
  333. (sensor). After setting this temperature, the thermal zone may pass
  334. this temperature to platform emulation function if registered or
  335. cache it locally. This is useful in debugging different temperature
  336. threshold and its associated cooling action. This is write only node
  337. and writing 0 on this node should disable emulation.
  338. Unit: millidegree Celsius
  339. WO, Optional
  340. WARNING: Be careful while enabling this option on production systems,
  341. because userland can easily disable the thermal policy by simply
  342. flooding this sysfs node with low temperature values.
  343. sustainable_power
  344. An estimate of the sustained power that can be dissipated by
  345. the thermal zone. Used by the power allocator governor. For
  346. more information see Documentation/thermal/power_allocator.txt
  347. Unit: milliwatts
  348. RW, Optional
  349. k_po
  350. The proportional term of the power allocator governor's PID
  351. controller during temperature overshoot. Temperature overshoot
  352. is when the current temperature is above the "desired
  353. temperature" trip point. For more information see
  354. Documentation/thermal/power_allocator.txt
  355. RW, Optional
  356. k_pu
  357. The proportional term of the power allocator governor's PID
  358. controller during temperature undershoot. Temperature undershoot
  359. is when the current temperature is below the "desired
  360. temperature" trip point. For more information see
  361. Documentation/thermal/power_allocator.txt
  362. RW, Optional
  363. k_i
  364. The integral term of the power allocator governor's PID
  365. controller. This term allows the PID controller to compensate
  366. for long term drift. For more information see
  367. Documentation/thermal/power_allocator.txt
  368. RW, Optional
  369. k_d
  370. The derivative term of the power allocator governor's PID
  371. controller. For more information see
  372. Documentation/thermal/power_allocator.txt
  373. RW, Optional
  374. integral_cutoff
  375. Temperature offset from the desired temperature trip point
  376. above which the integral term of the power allocator
  377. governor's PID controller starts accumulating errors. For
  378. example, if integral_cutoff is 0, then the integral term only
  379. accumulates error when temperature is above the desired
  380. temperature trip point. For more information see
  381. Documentation/thermal/power_allocator.txt
  382. Unit: millidegree Celsius
  383. RW, Optional
  384. slope
  385. The slope constant used in a linear extrapolation model
  386. to determine a hotspot temperature based off the sensor's
  387. raw readings. It is up to the device driver to determine
  388. the usage of these values.
  389. RW, Optional
  390. offset
  391. The offset constant used in a linear extrapolation model
  392. to determine a hotspot temperature based off the sensor's
  393. raw readings. It is up to the device driver to determine
  394. the usage of these values.
  395. RW, Optional
  396. *****************************
  397. * Cooling device attributes *
  398. *****************************
  399. type
  400. String which represents the type of device, e.g:
  401. - for generic ACPI: should be "Fan", "Processor" or "LCD"
  402. - for memory controller device on intel_menlow platform:
  403. should be "Memory controller".
  404. RO, Required
  405. max_state
  406. The maximum permissible cooling state of this cooling device.
  407. RO, Required
  408. cur_state
  409. The current cooling state of this cooling device.
  410. The value can any integer numbers between 0 and max_state:
  411. - cur_state == 0 means no cooling
  412. - cur_state == max_state means the maximum cooling.
  413. RW, Required
  414. 3. A simple implementation
  415. ACPI thermal zone may support multiple trip points like critical, hot,
  416. passive, active. If an ACPI thermal zone supports critical, passive,
  417. active[0] and active[1] at the same time, it may register itself as a
  418. thermal_zone_device (thermal_zone1) with 4 trip points in all.
  419. It has one processor and one fan, which are both registered as
  420. thermal_cooling_device. Both are considered to have the same
  421. effectiveness in cooling the thermal zone.
  422. If the processor is listed in _PSL method, and the fan is listed in _AL0
  423. method, the sys I/F structure will be built like this:
  424. /sys/class/thermal:
  425. |thermal_zone1:
  426. |---type: acpitz
  427. |---temp: 37000
  428. |---mode: enabled
  429. |---policy: step_wise
  430. |---available_policies: step_wise fair_share
  431. |---trip_point_0_temp: 100000
  432. |---trip_point_0_type: critical
  433. |---trip_point_1_temp: 80000
  434. |---trip_point_1_type: passive
  435. |---trip_point_2_temp: 70000
  436. |---trip_point_2_type: active0
  437. |---trip_point_3_temp: 60000
  438. |---trip_point_3_type: active1
  439. |---cdev0: --->/sys/class/thermal/cooling_device0
  440. |---cdev0_trip_point: 1 /* cdev0 can be used for passive */
  441. |---cdev0_weight: 1024
  442. |---cdev1: --->/sys/class/thermal/cooling_device3
  443. |---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
  444. |---cdev1_weight: 1024
  445. |cooling_device0:
  446. |---type: Processor
  447. |---max_state: 8
  448. |---cur_state: 0
  449. |cooling_device3:
  450. |---type: Fan
  451. |---max_state: 2
  452. |---cur_state: 0
  453. /sys/class/hwmon:
  454. |hwmon0:
  455. |---name: acpitz
  456. |---temp1_input: 37000
  457. |---temp1_crit: 100000
  458. 4. Event Notification
  459. The framework includes a simple notification mechanism, in the form of a
  460. netlink event. Netlink socket initialization is done during the _init_
  461. of the framework. Drivers which intend to use the notification mechanism
  462. just need to call thermal_generate_netlink_event() with two arguments viz
  463. (originator, event). The originator is a pointer to struct thermal_zone_device
  464. from where the event has been originated. An integer which represents the
  465. thermal zone device will be used in the message to identify the zone. The
  466. event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL,
  467. THERMAL_DEV_FAULT}. Notification can be sent when the current temperature
  468. crosses any of the configured thresholds.
  469. 5. Export Symbol APIs:
  470. 5.1: get_tz_trend:
  471. This function returns the trend of a thermal zone, i.e the rate of change
  472. of temperature of the thermal zone. Ideally, the thermal sensor drivers
  473. are supposed to implement the callback. If they don't, the thermal
  474. framework calculated the trend by comparing the previous and the current
  475. temperature values.
  476. 5.2:get_thermal_instance:
  477. This function returns the thermal_instance corresponding to a given
  478. {thermal_zone, cooling_device, trip_point} combination. Returns NULL
  479. if such an instance does not exist.
  480. 5.3:thermal_notify_framework:
  481. This function handles the trip events from sensor drivers. It starts
  482. throttling the cooling devices according to the policy configured.
  483. For CRITICAL and HOT trip points, this notifies the respective drivers,
  484. and does actual throttling for other trip points i.e ACTIVE and PASSIVE.
  485. The throttling policy is based on the configured platform data; if no
  486. platform data is provided, this uses the step_wise throttling policy.
  487. 5.4:thermal_cdev_update:
  488. This function serves as an arbitrator to set the state of a cooling
  489. device. It sets the cooling device to the deepest cooling state if
  490. possible.