commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream.
The DT specifies a threshold of 65000, we setup the register with a value in
the temperature resolution for the controller, 64656.
When we reach 64656, the interrupt fires, the interrupt is disabled. Then the
irq thread runs and calls thermal_zone_device_update() which will call in turn
hisi_thermal_get_temp().
The function will look if the temperature decreased, assuming it was more than
65000, but that is not the case because the current temperature is 64656
(because of the rounding when setting the threshold). This condition being
true, we re-enable the interrupt which fires immediately after exiting the irq
thread. That happens again and again until the temperature goes to more than
65000.
Potentially, there is here an interrupt storm if the temperature stabilizes at
this temperature. A very unlikely case but possible.
In any case, it does not make sense to handle dozens of alarm interrupt for
nothing.
Fix this by rounding the threshold value to the controller resolution so the
check against the threshold is consistent with the one set in the controller.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream.
The step and the base temperature are fixed values, we can simplify the
computation by converting the base temperature to milli celsius and use a
pre-computed step value. That saves us a lot of mult + div for nothing at
runtime.
Take also the opportunity to change the function names to be consistent with
the rest of the code.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream.
The threaded interrupt for the alarm interrupt is requested before the
temperature controller is setup. This one can fire an interrupt immediately
leading to a kernel panic as the sensor data is not initialized.
In order to prevent that, move the threaded irq after the Tsensor is setup.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream.
The interrupt for the temperature threshold is not enabled at the end of the
probe function, enable it after the setup is complete.
On the other side, the irq_enabled is not correctly set as we are checking if
the interrupt is masked where 'yes' means irq_enabled=false.
irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
&data->irq_enabled);
As we are always enabling the interrupt, it is pointless to check if
the interrupt is masked or not, just set irq_enabled to 'true'.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Tested-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 07209fcf33542c1ff1e29df2dbdf8f29cdaacb10 ]
There is a particular situation when the cooling device is cpufreq and the heat
dissipation is not efficient enough where the temperature increases little by
little until reaching the critical threshold and leading to a SoC reset.
The behavior is reproducible on a hikey6220 with bad heat dissipation (eg.
stacked with other boards).
Running a simple C program doing while(1); for each CPU of the SoC makes the
temperature to reach the passive regulation trip point and ends up to the
maximum allowed temperature followed by a reset.
This issue has been also reported by running the libhugetlbfs test suite.
What is observed is a ping pong between two cpu frequencies, 1.2GHz and 900MHz
while the temperature continues to grow.
It appears the step wise governor calls get_target_state() the first time with
the throttle set to true and the trend to 'raising'. The code selects logically
the next state, so the cpu frequency decreases from 1.2GHz to 900MHz, so far so
good. The temperature decreases immediately but still stays greater than the
trip point, then get_target_state() is called again, this time with the
throttle set to true *and* the trend to 'dropping'. From there the algorithm
assumes we have to step down the state and the cpu frequency jumps back to
1.2GHz. But the temperature is still higher than the trip point, so
get_target_state() is called with throttle=1 and trend='raising' again, we jump
to 900MHz, then get_target_state() is called with throttle=1 and
trend='dropping', we jump to 1.2GHz, etc ... but the temperature does not
stabilizes and continues to increase.
[ 237.922654] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 237.922678] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 237.922690] thermal cooling_device0: cur_state=0
[ 237.922701] thermal cooling_device0: old_target=0, target=1
[ 238.026656] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 238.026680] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
[ 238.026694] thermal cooling_device0: cur_state=1
[ 238.026707] thermal cooling_device0: old_target=1, target=0
[ 238.134647] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 238.134667] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 238.134679] thermal cooling_device0: cur_state=0
[ 238.134690] thermal cooling_device0: old_target=0, target=1
In this situation the temperature continues to increase while the trend is
oscillating between 'dropping' and 'raising'. We need to keep the current state
untouched if the throttle is set, so the temperature can decrease or a higher
state could be selected, thus preventing this oscillation.
Keeping the next_target untouched when 'throttle' is true at 'dropping' time
fixes the issue.
The following traces show the governor does not change the next state if
trend==2 (dropping) and throttle==1.
[ 2306.127987] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2306.128009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 2306.128021] thermal cooling_device0: cur_state=0
[ 2306.128031] thermal cooling_device0: old_target=0, target=1
[ 2306.231991] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2306.232016] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=1
[ 2306.232030] thermal cooling_device0: cur_state=1
[ 2306.232042] thermal cooling_device0: old_target=1, target=1
[ 2306.335982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2306.336006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=1
[ 2306.336021] thermal cooling_device0: cur_state=1
[ 2306.336034] thermal cooling_device0: old_target=1, target=1
[ 2306.439984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2306.440008] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
[ 2306.440022] thermal cooling_device0: cur_state=1
[ 2306.440034] thermal cooling_device0: old_target=1, target=0
[ ... ]
After a while, if the temperature continues to increase, the next state becomes
2 which is 720MHz on the hikey. That results in the temperature stabilizing
around the trip point.
[ 2455.831982] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2455.832006] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=0
[ 2455.832019] thermal cooling_device0: cur_state=1
[ 2455.832032] thermal cooling_device0: old_target=1, target=1
[ 2455.935985] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2455.936013] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
[ 2455.936027] thermal cooling_device0: cur_state=1
[ 2455.936040] thermal cooling_device0: old_target=1, target=1
[ 2456.043984] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=0,throttle=1
[ 2456.044009] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=0,throttle=0
[ 2456.044023] thermal cooling_device0: cur_state=1
[ 2456.044036] thermal cooling_device0: old_target=1, target=1
[ 2456.148001] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=1,throttle=1
[ 2456.148028] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=1,throttle=1
[ 2456.148042] thermal cooling_device0: cur_state=1
[ 2456.148055] thermal cooling_device0: old_target=1, target=2
[ 2456.252009] thermal thermal_zone0: Trip0[type=1,temp=65000]:trend=2,throttle=1
[ 2456.252041] thermal thermal_zone0: Trip1[type=1,temp=75000]:trend=2,throttle=0
[ 2456.252058] thermal cooling_device0: cur_state=2
[ 2456.252075] thermal cooling_device0: old_target=2, target=1
IOW, this change is needed to keep the state for a cooling device if the
temperature trend is oscillating while the temperature increases slightly.
Without this change, the situation above leads to a catastrophic crash by a
hardware reset on hikey. This issue has been reported to happen on an OMAP
dra7xx also.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Tested-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
there are three concepts represent backlight in int3406_thermal driver.
1. the raw brightness value from native graphics driver.
2. the percentage numbers from ACPI _BCL control method.
3. the consecutive numbers represent cooling states.
int3406_thermal driver
1. uses value from DDDL/DDPC as the lower/upper limit, which is consistent
with ACPI _BCL control methods.
2. reads current and maximum brightness from the native graphics driver.
3. expose them to thermal sysfs I/F
This patch fixes the code that switches between the raw brightness value
and the cooling state, which results in bogus value in thermal sysfs I/F.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch adds support for mt2712 chip thermal calibration data
and calculation, and is compatible with the existing chips.
Signed-off-by: Louis Yu <louis.yu@mediatek.com>
Reviewed-by: Dawei Chien <dawei.chien@mediatek.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch adds support for mt2712 chip to mtk_thermal,
and integrate mt2712 into the same mediatek thermal driver.
MT2712 has only 1 bank and 4 sensors.
Signed-off-by: Louis Yu <louis.yu@mediatek.com>
Reviewed-by: Dawei Chien <dawei.chien@mediatek.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Using the TSDSS flag to determine whether the thermal sensor is
enabled is problematic. Broadwell-DE (Xeon D-1500) does not support
dynamic shutdown and the TSDSS flag always reads 0 (contrary to the
current datasheet). Even on hardware supporting dynamic shutdown, the
driver does nothing to configure it, and the dynamic shutdown state
should not prevent the driver from loading. The ETS flag itself
indicates whether the thermal sensor is enabled, so use it instead of
the TSDSS flag on all hardware platforms.
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
RK3328 SOC has one Temperature Sensor for CPU.
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
Reviewed-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to thermal_zone_of_sensor_register, which is declared as const.
Thus the thermal_zone_of_device_ops structure itself can be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to thermal_zone_of_sensor_register, which is declared as const.
Thus the thermal_zone_of_device_ops structure itself can be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to thermal_zone_of_sensor_register, which is declared as const.
Thus the thermal_zone_of_device_ops structure itself can be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to devm_thermal_zone_of_sensor_register, which is declared
as const. Thus the thermal_zone_of_device_ops structure itself can
be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to thermal_zone_of_sensor_register, which is declared as const.
Thus the thermal_zone_of_device_ops structure itself can be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The thermal_zone_of_device_ops structure is only passed as the fourth
argument to devm_thermal_zone_of_sensor_register, which is declared
as const. Thus the thermal_zone_of_device_ops structure itself can
be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Reorder error handling code in order to fix some resources leaks in some
cases:
- 'tz' would leak if 'thermal_zone_create_device_groups()' fails
- memory allocated by 'thermal_zone_create_device_groups()' would leak
if 'device_register()' fails
With this patch, we now have 2 error handling paths: one before
'device_register()', and one after it.
This is needed because some resources are released in 'thermal_release()'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Simplify code by using the new 'thermal_zone_destroy_device_groups()'
helper function.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
In order to easily free resources allocated by
'thermal_zone_create_device_groups()' we need 2 new helper functions.
The first one undoes 'thermal_zone_create_device_groups()'.
The 2nd one undoes 'create_trip_attrs()', which is a function called by
'thermal_zone_create_device_groups()'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Some BIOS implement ACPI notification code 0x83 to indicate active
relationship table(ART) and/or thermal relationship table(TRT) changes
to INT3400 device. This event needs to be propagated to user space so
that it can be handled by the user space thermal daemon.
Signed-off-by: Brian Bian <brian.bian@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Add a thermal driver for on-chip PVT (Process, Voltage and Temperature)
monitoring unit implemented on UniPhier SoCs. This driver supports
temperature monitoring and alert function.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch fix the few typos in trt structure. Also, update
kernel warn message for failed to get device name from acpi
handle.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
The critical shutdown notice string used to have some spaces missing,
which makes it not so pretty.
Add the spaces to satisfy usual English space rules.
Reported-by: Mingcong Bai <jeffbai@aosc.io>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
We get a Kconfig warning when selecting this without also enabling
CONFIG_PCI:
warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE
&& SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG)
selects IOSF_MBI which has unmet direct dependencies (PCI)
This adds a new depedency.
Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common APIs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
On all supported platforms, the TS Reading (TSR) field in the
Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78
degrees C) are plausible, so don't mask out the topmost bit. And the
register itself is 16 bits wide, so use readw() rather than readl().
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
3152 1096 8 4256 10a0 processor_thermal_device.o
File size After adding 'const':
text data bss dec hex filename
3216 1032 8 4256 10a0 processor_thermal_device.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
1687 592 0 2279 8e7 int3400_thermal.o
File size After adding 'const':
text data bss dec hex filename
1751 528 0 2279 8e7 int3400_thermal.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Pull thermal management updates from Zhang Rui:
- Improve thermal cpu_cooling interaction with cpufreq core.
The cpu_cooling driver is designed to use CPU frequency scaling to
avoid high thermal states for a platform. But it wasn't glued really
well with cpufreq core.
For example clipped-cpus is copied from the policy structure and its
much better to use the policy->cpus (or related_cpus) fields directly
as they may have got updated. Not that things were broken before this
series, but they can be optimized a bit more.
This series tries to improve interactions between cpufreq core and
cpu_cooling driver and does some fixes/cleanups to the cpu_cooling
driver. (Viresh Kumar)
- A couple of fixes and cleanups in thermal core and imx, hisilicon,
bcm_2835, int340x thermal drivers. (Arvind Yadav, Dan Carpenter,
Sumeet Pawnikar, Srinivas Pandruvada, Willy WOLFF)
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (24 commits)
thermal: bcm2835: fix an error code in probe()
thermal: hisilicon: Handle return value of clk_prepare_enable
thermal: imx: Handle return value of clk_prepare_enable
thermal: int340x: check for sensor when PTYP is missing
Thermal/int340x: Fix few typos and kernel-doc style
thermal: fix source code documentation for parameters
thermal: cpu_cooling: Replace kmalloc with kmalloc_array
thermal: cpu_cooling: Rearrange struct cpufreq_cooling_device
thermal: cpu_cooling: 'freq' can't be zero in cpufreq_state2power()
thermal: cpu_cooling: don't store cpu_dev in cpufreq_cdev
thermal: cpu_cooling: get_level() can't fail
thermal: cpu_cooling: create structure for idle time stats
thermal: cpu_cooling: merge frequency and power tables
thermal: cpu_cooling: get rid of 'allowed_cpus'
thermal: cpu_cooling: OPPs are registered for all CPUs
thermal: cpu_cooling: store cpufreq policy
cpufreq: create cpufreq_table_count_valid_entries()
thermal: cpu_cooling: use cpufreq_policy to register cooling device
thermal: cpu_cooling: get rid of a variable in cpufreq_set_cur_state()
thermal: cpu_cooling: remove cpufreq_cooling_get_level()
...
Pull MFD updates from Lee Jones:
"New Drivers:
- Intel Cherry Trail Whiskey Cove PMIC
- TI LP87565 PMIC
New Device Support:
- Add support for Cannonlake to intel-lpss-pci
- Add support for Simatic IOT2000 to intel_quark_i2c_gpio
New Functionality:
- Add Regulator support (axp20x)
Fix-ups:
- Rework IRQ handling (intel_soc_pmic_bxtwc, rtsx_pcr, cros_ec)
- Remove unused/unwelcome code (ipaq-micro, wm831x-core, da9062-core)
- Provide deregistration on unbind (rn5t618)
- Rework DT code/documentation (arizona)
- Constify things (fsl-imx25-tsadc)
- MAINTAINERS updates (DA9062/61)
- Kconfig configuration adaptions (INTEL_SOC_PMIC, MFD_AXP20X_I2C)
- Switch to DMI matching (intel_quark_i2c_gpio)
- Provide an appropriate level of error checking (wm831x-{i2c,spi},
twl4030-irq, tc6393xb)
- Make use of devm_* (resource handling) calls (intel_soc_pmic_bxtwc,
stm32-timers, atmel-flexcom, cros_ec, fsl-imx25-tsadc,
exynos-lpass, palmas, qcom-spmi-pmic, smsc-ece1099,
motorola-cpcap)"
[ Skipped the last commit in that series that added eight thousand
lines of pointless repeated register definitions. - Linus ]
* tag 'mfd-next-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (38 commits)
mfd: Add LP87565 PMIC support
mfd: cros_ec: Free IRQ on exit
dt-bindings: vendor-prefixes: Add arctic to vendor prefix
mfd: da9061: Fix to remove BBAT_CONT register from chip model
mfd: da9061: Fix to remove BBAT_CONT register from chip model
mfd: axp20x-i2c: Document that this must be builtin on x86
mfd: Add Cherry Trail Whiskey Cove PMIC driver
mfd: tc6393xb: Handle return value of clk_prepare_enable
mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform
mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency
mfd: motorola-cpcap: Use devm_of_platform_populate()
mfd: smsc-ece: Use devm_of_platform_populate()
mfd: qcom-spmi-pmic: Use devm_of_platform_populate()
mfd: palmas: Use devm_of_platform_populate()
mfd: exynos: Use devm_of_platform_populate()
mfd: fsl-imx25: Use devm_of_platform_populate()
mfd: cros_ec: Use devm_of_platform_populate()
mfd: atmel: Use devm_of_platform_populate()
mfd: stm32-timers: Use devm_of_platform_populate()
mfd: intel_soc_pmic: Select designware i2c-bus driver
...
Here is the big patchset of USB and PHY driver updates for 4.13-rc1.
On the PHY side, they decided to move files around to "make things
easier" in their tree. Hopefully that wasn't a mistake, but in
linux-next testing, we haven't had any reported problems.
There's the usual set of gadget and xhci and musb updates in here as
well, along with a number of smaller updates for a raft of different USB
drivers. Full details in the shortlog, nothing really major.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCWVpavQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymJrgCgp8Pso8bs+bnIknUSQFSguWd3wM0AnA8X3NHf
lrdCuqw+2oxGOQrecacz
=5L4Q
-----END PGP SIGNATURE-----
Merge tag 'usb-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/PHY updates from Greg KH:
"Here is the big patchset of USB and PHY driver updates for 4.13-rc1.
On the PHY side, they decided to move files around to "make things
easier" in their tree. Hopefully that wasn't a mistake, but in
linux-next testing, we haven't had any reported problems.
There's the usual set of gadget and xhci and musb updates in here as
well, along with a number of smaller updates for a raft of different
USB drivers. Full details in the shortlog, nothing really major.
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (173 commits)
Add USB quirk for HVR-950q to avoid intermittent device resets
USB hub_probe: rework ugly goto-into-compound-statement
usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable
USB: serial: cp210x: add ID for CEL EM3588 USB ZigBee stick
usbip: Fix uninitialized variable bug in vhci
usb: core: read USB ports from DT in the usbport LED trigger driver
dt-bindings: leds: document new trigger-sources property
usb: typec: ucsi: Add ACPI driver
usb: typec: Add support for UCSI interface
usb: musb: compress return logic into one line
USB: serial: propagate late probe errors
USB: serial: refactor port endpoint setup
usb: musb: tusb6010_omap: Convert to DMAengine API
ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines
usb: musb: tusb6010: Handle DMA TX completion in DMA callback as well
usb: musb: tusb6010_omap: Allocate DMA channels upfront
usb: musb: tusb6010_omap: Create new struct for DMA data/parameters
usb: musb: tusb6010_omap: Use one musb_ep_select call in tusb_omap_dma_program
usb: musb: tusb6010: Add MUSB_G_NO_SKB_RESERVE to quirks
usb: musb: Add quirk to avoid skb reserve in gadget mode
...
This causes a static checker because we're passing a valid pointer to
PTR_ERR(). "err" is already the correct error code, so we can just
delete this line.
Fixes: bcb7dd9ef206 ("thermal: bcm2835: add thermal driver for bcm2835 SoC")
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
For INT3403 sensor PTYP field is mandatory. But some platforms didn't
have this field for sensors. This cause load failure for int3403 driver.
This change checks for the presence of _TMP method and if present, then
treats this device as a sensor.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch fix the few typos in function header of
acpi_parse_trt. Also, fix the typo in kernel debug
message for acpi_parse_art.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Some parameters are not documented, or not present at all, in thermal
governors code.
Signed-off-by: Willy Wolff <willy.mh.wolff@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Since all second level thermal IRQs are consumed by the same
device(bxt_wcove_thermal), there is no need to expose them as separate
interrupts. We can just export only the first level IRQs for thermal and
let the device(bxt_wcove_thermal) driver handle the second level IRQs
based on thermal interrupt status register. Also, just using only the
first level IRQ will eliminate the bug involved in requesting only the
second level IRQ and not explicitly enable the first level IRQ. For
more info on this issue please read the details at,
https://lkml.org/lkml/2017/2/27/148
This patch also makes relevant change in bxt_wcove_thermal driver to use
only first level PMIC thermal IRQ.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Use the new helper for reusing a device-tree node of another device
instead of managing the node references explicitly.
This also makes sure that the new of_node_reuse flag is set if the
device is ever reprobed, something which specifically now avoids driver
core from attempting to claim any pinmux resources already claimed by
the parent device.
Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The thermal child device reuses the parent MFD-device device-tree node
when registering a thermal zone, but did not take a reference to the
node.
This leads to a reference imbalance, and potential use-after-free, when
the node reference is dropped by the platform-bus device destructor
(once for the child and later again for the parent).
Fix this by dropping any reference already held to a device-tree node
and getting a reference to the parent's node which will be balanced on
reprobe or on platform-device release, whichever comes first.
Note that simply clearing the of_node pointer on probe errors and on
driver unbind would not allow the use of device-managed resources as
specifically thermal_zone_of_sensor_unregister() claims that a valid
device-tree node pointer is needed during deregistration (even if it
currently does not seem to use it).
Fixes: ec4664b3fd6d ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: stable <stable@vger.kernel.org> # 4.9
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the compile after the switch to the UUID API in commit f4c19ac9
("thermal: int340x_thermal: Switch to use new generic UUID API").
Signed-off-by: Christoph Hellwig <hch@lst.de>
There are new types and helpers that are supposed to be used in
new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
The conversion fixes a potential bug in int340x_thermal as well
since we have to use memcmp() on binary data.
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This shrinks the size of the structure on arm64 by 8 bytes by avoiding
padding of 4 bytes at two places.
Also add missing doc comment for freq_table
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
