- 23 Mar, 2020 8 commits
-
-
Daniel Lezcano authored
The WARN_ON macros are used at the entry functions state2power() and set_cur_state(). state2power() is called with the max_state retrieved from get_max_state which returns cpufreq_cdev->max_level, then it check if max_state is > cpufreq_cdev->max_level. The test does not really makes sense but let's assume we want to make sure to catch an error if the code evolves. However the WARN_ON is overkill. set_cur_state() is also called from userspace if we write to the sysfs. It is easy to see a stack dumped by just writing to sysfs /sys/class/thermal/cooling_device0/cur_state a value greater than "max_level". A bit scary. Returing -EINVAL is enough. Remove these WARN_ON. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20200321193107.21590-1-daniel.lezcano@linaro.org
-
Willy Wolff authored
When setting the cooling device current state from userspace via sysfs, the operation fails by returning an -EINVAL. It appears the recent changes with the per-policy frequency QoS introduced a regression as reported by: https://lkml.org/lkml/2020/3/20/599 The function freq_qos_update_request returns 0 or 1 describing update effectiveness, and a negative error code on failure. However, cpufreq_set_cur_state returns 0 on success or an error code otherwise. Consider the QoS update as successful if the function does not return an error. Fixes: 3000ce3c ("cpufreq: Use per-policy frequency QoS") Signed-off-by:
Willy Wolff <willy.mh.wolff.ml@gmail.com> Acked-by:
-
Anson Huang authored
i.MX8MP shares same TMU with i.MX8MM, the only difference is i.MX8MP has two thermal sensors while i.MX8MM ONLY has one, add multiple sensors support for i.MX8MM TMU driver. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
-
Anson Huang authored
Add thermal binding doc for Freescale's i.MX8MP Thermal Monitoring Unit. Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by:
-
Anson Huang authored
The temperature value passed from SCU could be negative value, the data type should be signed instead of unsigned. Fixes: e20db70d ("thermal: imx_sc: add i.MX system controller thermal support") Signed-off-by:
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Pandruvada, Srinivas <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Sumeet Pawnikar authored
Added new PCI id for Tiger Lake processor thermal device along with MMIO RAPL support. Signed-off-by:
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
- 21 Mar, 2020 1 commit
-
-
Clark Williams authored
The spinlock pkg_temp_lock has the potential of being taken in atomic context because it can be acquired from the thermal IRQ vector. It's static and limited scope so go ahead and make it a raw spinlock. Signed-off-by:
Clark Williams <williams@redhat.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
- 20 Mar, 2020 21 commits
-
-
Yuantian Tang authored
Cooling-maps doesn't have to be a required property because there may be no cooling device on system, or there are no enough cooling devices for each thermal zone in multiple thermal zone cases since cooling devices can't be shared. So make this property optional to remove such limitations. For thermal zones with no cooling-maps, there could be critic trips that can trigger CPU reset or shutdown. So they still can take actions. Signed-off-by:
Yuantian Tang <andy.tang@nxp.com> Reviewed-by:
-
Rob Herring authored
There's no need to specify 'maxItems' with the same value as the number of entries in 'items'. A meta-schema update will catch future cases. Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Amit Kucheria <amit.kucheria@linaro.org> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Rob Herring authored
There's no need to specify 'maxItems' with the same value as the number of entries in 'items'. A meta-schema update will catch future cases. Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Amit Kucheria <amit.kucheria@verdurent.com> Cc: linux-pm@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Signed-off-by:
-
Anson Huang authored
imx_thermal_unregister_legacy_cooling() should be used for handling legacy cpufreq cooling cleanups in .remove callback instead of calling cpufreq_cooling_unregister() and cpufreq_cpu_put() directly, especially for !CONFIG_CPU_FREQ scenario, no operation needed for handling legacy cpufreq cooling cleanups at all. Signed-off-by:
-
Anson Huang authored
Sort includes alphabetically for consistency, and take this chance to remove unused include of of_address.h. Signed-off-by:
-
Anson Huang authored
Use devm_add_action_or_reset() to handle all cleanups of failure in .probe and .remove, then .remove callback can be dropped. Signed-off-by:
-
Niklas Söderlund authored
With the ctemp value returned instead of cached in the private data structure their is no need to take the lock when translating ctemp into a temperature. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Niklas Söderlund authored
There is no need to cache the ctemp value in the private data structure as it's always prefetched before it's used. Remove it from the structure and have rcar_thermal_update_temp return the value instead of storing it. Signed-off-by:
-
Niklas Söderlund authored
Since commit a1ade565 ("thermal: rcar: check every rcar_thermal_update_temp() return value") the temperature is always read in rcar_thermal_get_current_temp() so comparing it before and after enabling interrupts have little effect. Remove the check and always update the thermal zone when we get an interrupt that the temperature have changed. Signed-off-by:
-
Amit Kucheria authored
IRQF_TRIGGER_HIGH is already specified through devicetree interrupts property. Remove it from code. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Amit Kucheria authored
Document ul_lock, threshold and control structure members and make the following kernel-doc invocation happy: $ scripts/kernel-doc -v -none drivers/thermal/qcom/* drivers/thermal/qcom/qcom-spmi-temp-alarm.c:105: info: Scanning doc for qpnp_tm_get_temp_stage drivers/thermal/qcom/tsens-common.c:18: info: Scanning doc for struct tsens_irq_data drivers/thermal/qcom/tsens-common.c:130: info: Scanning doc for tsens_hw_to_mC drivers/thermal/qcom/tsens-common.c:163: info: Scanning doc for tsens_mC_to_hw drivers/thermal/qcom/tsens-common.c:245: info: Scanning doc for tsens_set_interrupt drivers/thermal/qcom/tsens-common.c:268: info: Scanning doc for tsens_threshold_violated drivers/thermal/qcom/tsens-common.c:362: info: Scanning doc for tsens_critical_irq_thread drivers/thermal/qcom/tsens-common.c:438: info: Scanning doc for tsens_irq_thread drivers/thermal/qcom/tsens.h:41: info: Scanning doc for struct tsens_sensor drivers/thermal/qcom/tsens.h:59: info: Scanning doc for struct tsens_ops drivers/thermal/qcom/tsens.h:494: info: Scanning doc for struct tsens_features drivers/thermal/qcom/tsens.h:513: info: Scanning doc for struct tsens_plat_data drivers/thermal/qcom/tsens.h:529: info: Scanning doc for struct tsens_context Signed-off-by:
-
Amit Kucheria authored
TSENS IP v2.3 onwards adds support for a watchdog to detect if the TSENS HW FSM is stuck. Add support to detect and restart the FSM in the driver. The watchdog is configured by the bootloader, we just enable the watchdog bark as a debug feature in the kernel. Signed-off-by:
-
Amit Kucheria authored
TSENS IP v2.x adds critical threshold interrupt support for each sensor in addition to the upper/lower threshold interrupt. Add support in the driver. While the critical interrupts themselves aren't currently used by Linux, the HW line is also used by the TSENS watchdog. So this patch acts as infrastructure to enable watchdog functionality for the TSENS IP. Signed-off-by:
-
Amit Kucheria authored
We don't currently call put_device in case of successfully initialising the device. So we hold the reference and keep the device pinned forever. Allow control to fall through so we can use same code for success and error paths to put_device. As a part of this fixup, change devm_ioremap_resource to act on the same device pointer as that used to allocate regmap memory. That ensures that we are free to release op->dev after examining its resources. Signed-off-by:
-
Amit Kucheria authored
We already dereference the sensor and save it into a variable. Use the variable directly to make the code easier to read. Signed-off-by:
-
Amit Kucheria authored
All the sensor data is initialised at init time. Lock it down by passing it to functions as a constant. Signed-off-by:
-
Amit Kucheria authored
struct tsens_features is currently initialized as part of platform data at compile-time and not modifiable. We now have some usecases in feature detection across IP versions where it is more flexible to update the features after probing registers. Remove const qualifier from tsens_features and the encapsulating tsens_plat_data. Signed-off-by:
-
Niklas Söderlund authored
If the common register memory resource is not available the driver needs to fail gracefully to disable PM. Instead of returning the error directly store it in ret and use the already existing error path. Signed-off-by:
-
Anson Huang authored
Remove unused includes to simplify the code. Signed-off-by:
-
Geert Uytterhoeven authored
Add support for the Thermal Sensor/Chip Internal Voltage Monitor in the R-Car M3-W+ (R8A77961) SoC. According to the R-Car Gen3 Hardware Manual Errata for Revision 2.00 of Jan 31, 2020, the thermal parameters for R-Car M3-W+ are the same as for R-Car M3-W. Signed-off-by:
-
Geert Uytterhoeven authored
Document R-Car M3-W+ (R8A77961) SoC bindings. Signed-off-by:
-
- 12 Mar, 2020 10 commits
-
-
Anson Huang authored
Add COMPILE_TEST support to i.MX8MM thermal driver for better compile testing coverage. Signed-off-by:
-
Yuantian Tang authored
Qoriq thermal driver is used by both PowerPC and ARM architecture. When built for PowerPC architecture, it reports error: undefined reference to `.__devm_regmap_init_mmio_clk' To fix it, select config REGMAP_MMIO. Fixes: 4316237b (thermal: qoriq: Convert driver to use regmap API) Signed-off-by:
-
Anson Huang authored
i.MX SCU thermal driver depends on IMX_SCU which does NOT have COMPILE_TEST enabled, so need to remove COMPILE_TEST for i.MX SCU thermal as well. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Anson Huang authored
Add "inline" to thermal_zone_of_get_sensor_id() function to avoid below build warning of !defined(CONFIG_THERMAL_OF). In file included from drivers/hwmon/hwmon.c:22: include/linux/thermal.h:382:12: warning: 'thermal_zone_of_get_sensor_id' defined but not used [-Wunused-function] 382 | static int thermal_zone_of_get_sensor_id(struct device_node *tz_np, Signed-off-by:
-
Anson Huang authored
Use __maybe_unused for power management related functions instead of #if CONFIG_PM_SLEEP to simplify the code. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Anson Huang authored
The i.MX SCU API strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs, use __packed __aligned(4) to avoid potential oopses. Signed-off-by:
-
Linus Walleij authored
This switches the TI SoC thermal driver to use GPIO descriptors instead of retrieveing a GPIO number from the device tree and requesting the GPIO separately. Cc: Keerthy <j-keerthy@ti.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
The thermal subsystem may have relied on sysfs in 2008 when it was introduced, but these days the thermal zones will more often than not come from the hardware descriptions and not from sysfs. Drop the "Generic" phrases as well: there are no non-generic drivers that I know of, the thermal framework is by definition generic. Reword a bit and fix some grammar. [ Daniel Lezcano ] : fixed Randy's comment s/offers/offer/ Signed-off-by:
-
Anson Huang authored
i.MX8MM has a thermal monitoring unit(TMU) inside, it ONLY has one sensor for CPU, add support for reading immediate temperature of this sensor. Signed-off-by:
-
Anson Huang authored
Add thermal binding doc for Freescale's i.MX8MM Thermal Monitoring Unit. Signed-off-by:
-
