03 Aug, 2015
1 commit
-
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
Acked-by: Geert Uytterhoeven
Reviewed-by: Jean Delvare
Reviewed-by: Lukasz Majewski
Reviewed-by: Darren Hart
Reviewed-by: Heiko Stuebner
Reviewed-by: Peter Feuerer
Cc: Punit Agrawal
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Jean Delvare
Cc: Peter Feuerer
Cc: Heiko Stuebner
Cc: Lukasz Majewski
Cc: Stephen Warren
Cc: Thierry Reding
Cc: linux-acpi@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck
Cc: Rafael J. Wysocki
Cc: Maxime Ripard
Cc: Darren Hart
Cc: lm-sensors@lm-sensors.org
Signed-off-by: Zhang Rui
05 May, 2015
1 commit
-
8754d5115693 ("thermal: introduce the Power Allocator governor") dropped
the const attribute in the struct thermal_zone_device. That means that
the thermal_zone_params pointer passed to thermal_zone_device_register()
also lost the const qualifier. Drop the const in x86_pkg_temp_thermal.c
as well to avoid the following warning as reported by the kbuild test
robot:drivers/thermal/x86_pkg_temp_thermal.c: In function 'pkg_temp_thermal_device_add':
>> drivers/thermal/x86_pkg_temp_thermal.c:450:31: warning: passing argument 6 of 'thermal_zone_device_register' discards 'const' qualifier from pointer target type
phy_dev_entry, &tzone_ops, &pkg_temp_tz_params, 0, 0);
^
In file included from drivers/thermal/x86_pkg_temp_thermal.c:30:0:
include/linux/thermal.h:378:29: note: expected 'struct thermal_zone_params *' but argument is of type 'const struct thermal_zone_params *'
struct thermal_zone_device *thermal_zone_device_register(const char *, int, int,
^Cc: Jean Delvare
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Javi Merino
Signed-off-by: Eduardo Valentin
20 Mar, 2014
1 commit
-
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).Instead, the correct and race-free way of performing the callback
registration is:cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);cpu_notifier_register_done();
Fix the thermal x86-pkg-temp code by using this latter form of callback
registration.Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: Ingo Molnar
Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Rafael J. Wysocki
03 Mar, 2014
2 commits
-
The thermal zone type should not include an instance number. Otherwise
each zone is considered a different type and the thermal-to-hwmon
bridge fails to group them all in a single hwmon device.I also changed the type to "x86_pkg_temp", because "pkg" was too
generic, and other thermal drivers use an underscore, not a dash, as
a separator. Or maybe "cpu_pkg_temp" would be better?Signed-off-by: Jean Delvare
Cc: Zhang Rui
Cc: Eduardo Valentin
Signed-off-by: Zhang Rui -
The temperature value reported by x86_pkg_temp_thermal is already
reported by the coretemp driver. So, do not expose this thermal zone
as a hwmon device, because it would be redundant.Signed-off-by: Jean Delvare
Cc: Zhang Rui
Cc: Eduardo Valentin
Acked-by: Guenter Roeck
Signed-off-by: Zhang Rui
02 Jan, 2014
1 commit
-
Mark function sys_set_trip_temp() as static in x86_pkg_temp_thermal.c
because it is not used outside this file.This eliminates the following warning in x86_pkg_temp_thermal.c:
drivers/thermal/x86_pkg_temp_thermal.c:218:5: warning: no previous prototype for ‘sys_set_trip_temp’ [-Wmissing-prototypes]Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
Signed-off-by: Zhang Rui
25 Sep, 2013
1 commit
-
x86_pkg_temp receives thermal notifications via a callback from a
therm_throt driver, where thermal interrupts are processed.
This callback is pkg_temp_thermal_platform_thermal_notify. Here to
avoid multiple interrupts from cores in a package, we disable the
source and also set a variable to avoid scheduling delayed work function.
This variable is protected via spin_lock_irqsave. On one buggy platform,
we still receiving interrupts even if the source is disabled. This
can cause deadlock/lockdep warning, when interrupt is generated while under
spinlock in work function.
Change spin_lock to spin_lock_irqsave and spin_unlock to
spin_unlock_irqrestore as the data it is trying to protect can also
be modified in a notification call called from interrupt handler.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Zhang Rui
22 Jul, 2013
1 commit
-
Commit f1a18a105 "Thermal: CPU Package temperature thermal" had code
that did a get_online_cpus(), run a loop and then do a
put_online_cpus(). The problem is that the loop had an error exit that
would skip the put_online_cpus() part.In the error exit part of the function, it also did a get_online_cpus(),
run a loop and then put_online_cpus(). The only way to get to the error
exit part is with get_online_cpus() already performed. If this error
condition is hit, the system will be prevented from taking CPUs offline.
The process taking the CPU offline will lock up hard.Removing the get_online_cpus() removes the lockup as the hotplug CPU
refcount is back to zero.This was bisected with ktest.
Signed-off-by: Steven Rostedt
Signed-off-by: Zhang Rui
16 Jul, 2013
1 commit
-
Although it is unlikley that physical package id is set to some
arbitary number, it is better to prevent in anycase. Since package
temp zones use this in thermal zone type and for allocation, added
a limit.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Zhang Rui
15 Jul, 2013
2 commits
-
If krealloc() returns NULL, it doesn't free the original. So any code
of the form 'foo = krealloc(foo, ...);' is almost certainly a bug.Signed-off-by: Wei Yongjun
Signed-off-by: Zhang Rui -
On systems with no package MSR support this caused crash as there
is a bug in the logic to check presence of DTHERM and PTS feature
together. Added a change so that when there is no PTS support, module
doesn't get loaded. Even if some CPU comes online with the PTS
feature disabled, and other CPUs has this support, this patch
will still prevent such MSR accesses.Signed-off-by: Srinivas Pandruvada
Reported-by: Daniel Walker
Signed-off-by: Zhang Rui
18 Jun, 2013
1 commit
-
This driver register CPU digital temperature sensor as a thermal
zone at package level.
Each package will show up as one zone with at max two trip points.
These trip points can be both read and updated. Once a non zero
value is set in the trip point, if the package package temperature
goes above or below this setting, a thermal notification is
generated.Signed-off-by: Srinivas Pandruvada
Signed-off-by: Zhang Rui