Re: [PATCH] thermal: consistently use int for temperatures
Hi Punit, On Fri, Jul 17, 2015 at 12:14:36PM +0100, Punit Agrawal wrote: Hi Sascha, Sascha Hauer s.ha...@pengutronix.de writes: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Thanks for moving over the thermal sub-system in Linux to consistently use a single type. In your patch, you missed migrating over power_allocator governor and it's associated trace events. It got merged for v4.2. Could you incorporate something like below in your next version? It seems I have changed drivers/thermal/power_allocator.c but missed include/trace/events/thermal_power_allocator.h. Please check out the v2 patch I just sent. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha,
Sascha Hauer s.ha...@pengutronix.de writes:
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Thanks for moving over the thermal sub-system in Linux to consistently
use a single type.
In your patch, you missed migrating over power_allocator governor and
it's associated trace events. It got merged for v4.2.
Could you incorporate something like below in your next version?
Thanks,
Punit
[...]
---8---
Subject: [PATCH] Use int for temperature in power_allocator governor
---
drivers/thermal/power_allocator.c | 10 --
include/trace/events/thermal_power_allocator.h | 6 +++---
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/power_allocator.c
b/drivers/thermal/power_allocator.c
index 4672250..1bb7d7f 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -92,8 +92,7 @@ struct power_allocator_params {
* Return: The power budget for the next period.
*/
static u32 pid_controller(struct thermal_zone_device *tz,
- unsigned long current_temp,
- unsigned long control_temp,
+ int current_temp, int control_temp,
u32 max_allocatable_power)
{
s64 p, i, d, power_range;
@@ -223,8 +222,7 @@ static void divvy_up_power(u32 *req_power, u32 *max_power,
int num_actors,
}
static int allocate_power(struct thermal_zone_device *tz,
- unsigned long current_temp,
- unsigned long control_temp)
+ int current_temp, int control_temp)
{
struct thermal_instance *instance;
struct power_allocator_params *params = tz-governor_data;
@@ -411,7 +409,7 @@ static int power_allocator_bind(struct thermal_zone_device
*tz)
{
int ret;
struct power_allocator_params *params;
- unsigned long switch_on_temp, control_temp;
+ int switch_on_temp, control_temp;
u32 temperature_threshold;
if (!tz-tzp || !tz-tzp-sustainable_power) {
@@ -476,7 +474,7 @@ static void power_allocator_unbind(struct
thermal_zone_device *tz)
static int power_allocator_throttle(struct thermal_zone_device *tz, int trip)
{
int ret;
- unsigned long switch_on_temp, control_temp, current_temp;
+ int switch_on_temp, control_temp, current_temp;
struct power_allocator_params *params = tz-governor_data;
/*
diff --git a/include/trace/events/thermal_power_allocator.h
b/include/trace/events/thermal_power_allocator.h
index 12e1321..5afae8f 100644
--- a/include/trace/events/thermal_power_allocator.h
+++ b/include/trace/events/thermal_power_allocator.h
@@ -11,7 +11,7 @@ TRACE_EVENT(thermal_power_allocator,
u32 total_req_power, u32 *granted_power,
u32 total_granted_power, size_t num_actors,
u32 power_range, u32 max_allocatable_power,
-unsigned long current_temp, s32 delta_temp),
+int current_temp, s32 delta_temp),
TP_ARGS(tz, req_power, total_req_power, granted_power,
total_granted_power, num_actors, power_range,
max_allocatable_power, current_temp, delta_temp),
@@ -24,7 +24,7 @@ TRACE_EVENT(thermal_power_allocator,
__field(size_t,num_actors )
__field(u32, power_range )
__field(u32, max_allocatable_power)
- __field(unsigned long, current_temp )
+ __field(int, current_temp )
__field(s32, delta_temp )
),
TP_fast_assign(
@@ -42,7 +42,7 @@ TRACE_EVENT(thermal_power_allocator,
__entry-delta_temp = delta_temp;
),
- TP_printk(thermal_zone_id=%d req_power={%s} total_req_power=%u
granted_power={%s} total_granted_power=%u power_range=%u
max_allocatable_power=%u current_temperature=%lu delta_temperature=%d,
+ TP_printk(thermal_zone_id=%d req_power={%s} total_req_power=%u
granted_power={%s} total_granted_power=%u power_range=%u
Re: [PATCH] thermal: consistently use int for temperatures
Sascha Hauer writes: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: Zhang Rui rui.zh...@intel.com Cc: Eduardo Valentin edubez...@gmail.com Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jean Delvare jdelv...@suse.de Cc: Peter Feuerer pe...@piie.net Cc: Heiko Stuebner he...@sntech.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: linux-a...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Guenter Roeck li...@roeck-us.net Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Darren Hart dvh...@infradead.org Cc: lm-sens...@lm-sensors.org --- [...] For: drivers/platform/x86/acerhdf.c | 9 drivers/thermal/gov_bang_bang.c| 5 ++-- Reviewed-by: Peter Feuerer pe...@piie.net [...] -- --peter; -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 6, 2015 at 9:19 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code
and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare jdelv...@suse.de
Cc: Peter Feuerer pe...@piie.net
Cc: Heiko Stuebner he...@sntech.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: Darren Hart dvh...@infradead.org
Cc: lm-sens...@lm-sensors.org
For rcar-thermal:
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index fe4e767..5d4ae7d 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -200,8 +200,7 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone,
-unsigned long *temp)
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
@@ -235,7 +234,7 @@ static int rcar_thermal_get_trip_type(struct
thermal_zone_device *zone,
}
static int rcar_thermal_get_trip_temp(struct thermal_zone_device *zone,
- int trip, unsigned long *temp)
+ int trip, int *temp)
{
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
struct device *dev = rcar_priv_to_dev(priv);
@@ -299,7 +298,7 @@ static void _rcar_thermal_irq_ctrl(struct
rcar_thermal_priv *priv, int enable)
static void rcar_thermal_work(struct work_struct *work)
{
struct rcar_thermal_priv *priv;
- unsigned long cctemp, nctemp;
+ int cctemp, nctemp;
priv = container_of(work, struct rcar_thermal_priv, work.work);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, 6 Jul 2015 09:19:49 +0200, Sascha Hauer wrote: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Cc: Zhang Rui rui.zh...@intel.com Cc: Eduardo Valentin edubez...@gmail.com Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jean Delvare jdelv...@suse.de Cc: Peter Feuerer pe...@piie.net Cc: Heiko Stuebner he...@sntech.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Thierry Reding thierry.red...@gmail.com Cc: linux-a...@vger.kernel.org Cc: platform-driver-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-o...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: Guenter Roeck li...@roeck-us.net Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Darren Hart dvh...@infradead.org Cc: lm-sens...@lm-sensors.org --- drivers/acpi/thermal.c | 12 +- drivers/hwmon/lm75.c | 2 +- drivers/hwmon/ntc_thermistor.c | 2 +- drivers/hwmon/tmp102.c | 2 +- drivers/input/touchscreen/sun4i-ts.c | 8 +++ drivers/platform/x86/acerhdf.c | 9 drivers/platform/x86/intel_mid_thermal.c | 9 drivers/power/power_supply_core.c | 2 +- drivers/thermal/armada_thermal.c | 2 +- drivers/thermal/db8500_thermal.c | 7 +++--- drivers/thermal/dove_thermal.c | 2 +- drivers/thermal/fair_share.c | 2 +- drivers/thermal/gov_bang_bang.c| 5 ++-- drivers/thermal/hisi_thermal.c | 4 ++-- drivers/thermal/imx_thermal.c | 27 +++--- drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++ .../int340x_thermal/processor_thermal_device.c | 4 ++-- drivers/thermal/intel_quark_dts_thermal.c | 13 +-- drivers/thermal/intel_soc_dts_iosf.c | 8 +++ drivers/thermal/kirkwood_thermal.c | 2 +- drivers/thermal/of-thermal.c | 14 +-- drivers/thermal/power_allocator.c | 16 ++--- drivers/thermal/qcom-spmi-temp-alarm.c | 2 +- drivers/thermal/rcar_thermal.c | 7 +++--- drivers/thermal/rockchip_thermal.c | 10 drivers/thermal/samsung/exynos_tmu.c | 23 +- drivers/thermal/spear_thermal.c| 2 +- drivers/thermal/st/st_thermal.c| 5 ++-- drivers/thermal/step_wise.c| 4 ++-- drivers/thermal/tegra_soctherm.c | 4 ++-- drivers/thermal/thermal_core.c | 26 ++--- drivers/thermal/thermal_hwmon.c| 10 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 drivers/thermal/x86_pkg_temp_thermal.c | 10 include/linux/thermal.h| 26 + 37 files changed, 148 insertions(+), 163 deletions(-) (...) No objection from me. For the hwmon parts: Reviewed-by: Jean Delvare jdelv...@suse.de -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
Hi Sascha, The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de Sascha, thanks for this cleanup work. Reviewed-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: consistently use int for temperatures
On Mon, Jul 06, 2015 at 09:19:49AM +0200, Sascha Hauer wrote: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de ... drivers/platform/x86/acerhdf.c | 9 drivers/platform/x86/intel_mid_thermal.c | 9 For these two: Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thermal: consistently use int for temperatures
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare jdelv...@suse.de
Cc: Peter Feuerer pe...@piie.net
Cc: Heiko Stuebner he...@sntech.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: Darren Hart dvh...@infradead.org
Cc: lm-sens...@lm-sensors.org
---
drivers/acpi/thermal.c | 12 +-
drivers/hwmon/lm75.c | 2 +-
drivers/hwmon/ntc_thermistor.c | 2 +-
drivers/hwmon/tmp102.c | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++
drivers/platform/x86/acerhdf.c | 9
drivers/platform/x86/intel_mid_thermal.c | 9
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 7 +++---
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/fair_share.c | 2 +-
drivers/thermal/gov_bang_bang.c| 5 ++--
drivers/thermal/hisi_thermal.c | 4 ++--
drivers/thermal/imx_thermal.c | 27 +++---
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 10
.../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
.../int340x_thermal/processor_thermal_device.c | 4 ++--
drivers/thermal/intel_quark_dts_thermal.c | 13 +--
drivers/thermal/intel_soc_dts_iosf.c | 8 +++
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/of-thermal.c | 14 +--
drivers/thermal/power_allocator.c | 16 ++---
drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
drivers/thermal/rcar_thermal.c | 7 +++---
drivers/thermal/rockchip_thermal.c | 10
drivers/thermal/samsung/exynos_tmu.c | 23 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/st/st_thermal.c| 5 ++--
drivers/thermal/step_wise.c| 4 ++--
drivers/thermal/tegra_soctherm.c | 4 ++--
drivers/thermal/thermal_core.c | 26 ++---
drivers/thermal/thermal_hwmon.c| 10
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
drivers/thermal/x86_pkg_temp_thermal.c | 10
include/linux/thermal.h| 26 +
37 files changed, 148 insertions(+), 163 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
/* sys I/F for generic thermal sysfs support */
-static int thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
{
struct acpi_thermal *tz = thermal-devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device
*thermal,
}
static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
{
struct acpi_thermal *tz = thermal-devdata;
int i;
@@ -690,7 +689,8 @@ static int thermal_get_trip_temp(struct thermal_zone_device
*thermal,
