In some cases, platform thermal driver may report invalid trip points,
thermal core should not take any action for these trip points.

This fixed a regression that bogus trip point starts to screw up thermal
control on some Lenovo laptops, after
commit bb431ba2
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Oct 30 16:31:47 2015 +0800

    Thermal: initialize thermal zone device correctly

    After thermal zone device registered, as we have not read any
    temperature before, thus tz->temperature should not be 0,
    which actually means 0C, and thermal trend is not available.
    In this case, we need specially handling for the first
    thermal_zone_device_update().

    Both thermal core framework and step_wise governor is
    enhanced to handle this. And since the step_wise governor
    is the only one that uses trends, so it's the only thermal
    governor that needs to be updated.
Tested-by: NManuel Krause <manuelkrause@netscape.net>
Tested-by: Nszegad <szegadlo@poczta.onet.pl>
Tested-by: Nprash <prash.n.rao@gmail.com>
Tested-by: Namish <ammdispose-arch@yahoo.com>
Tested-by: NMatthias <morpheusxyz123@yahoo.de>
Reviewed-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>

CC: <stable@vger.kernel.org> #3.18+
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551Signed-off-by: NZhang Rui <rui.zhang@intel.com>

Enabled temperature reporting device of Skylake Platform Controller hub.
The register map is same as the wildcat point thermal currently implemented
in this driver.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

Add resource managed version of thermal_zone_of_sensor_register() and
thermal_zone_of_sensor_unregister().

This helps in reducing the code size in error path, remove of
driver remove callbacks and making proper sequence for deallocations.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The driver doesn't check if the regulator_get_optional return value is
-EPROBE_DEFER so it will wrongly assume that the regulator couldn't be
found just because the regulator driver wasn't registered yet, i.e:

exynos-tmu 10060000.tmu: Regulator node (vtmu) not found

In this case the return value should be propagated to allow the driver
probe function to be deferred until the regulator driver is registered.
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The Exynos TMU DT binding says that the vtmu-supply is optional but the
driver uses devm_regulator_get() that creates a dummy regulator if it's
not defined in the DT. For example the following message is in the log:

10060000.tmu supply vtmu not found, using dummy regulator

Use the optional version of regulator_get() that doesn't create a dummy
regulator and instead returns a -ENODEV errno code. Since it's expected
that a regulator may not be defined and the driver will inform about it:

exynos-tmu 10060000.tmu: Regulator node (vtmu) not found
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NAndi Shyti <andi.shyti@samsung.com>
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

When DeviveTree contains more trip-points than SoC can configure
(usually more than four) and polling mode is not enabled, then the
remaining trip-points will be silently ignored. No interrupts will be
generated for them.

This might be quite dangerous when one provides DTB with a
non-configurable critical trip-point, like (assuming four supported
thresholds in TMU):
 - alert @50 C (type: active),
 - alert @60 C (type: active),
 - alert @70 C (type: active),
 - alert @80 C (type: active),
 - critical @120 C (type: critical) <- no interrupts generated.

This is a mistake in DTB so print a message in such case.
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Following the fix on thermal Kconfig, this
patch adds dependency on HAS_IOMEM so driver
properly compile test on UM arch.

Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The sign bit of temperature readback is bit 0, not bit 1.
Change to BIT(0) to fix it.
Signed-off-by: NWei Ni <wni@nvidia.com>
Reviewed-by: NMatt Longnecker <mlongnecker@nvidia.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The devres.o gets linked if HAS_IOMEM is present so on ARCH=um
allyesconfig (COMPILE_TEST) failed on many files with:

drivers/built-in.o: In function `kirkwood_thermal_probe':
kirkwood_thermal.c:(.text+0x390a25): undefined reference to `devm_ioremap_resource'
drivers/built-in.o: In function `exynos_tmu_probe':
exynos_tmu.c:(.text+0x39246b): undefined reference to `devm_ioremap'

The users of devm_ioremap_resource() which are compile-testable should
depend on HAS_IOMEM.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

We don't need to initialize "ret".  We can move the IS_ERR() checks into
the if condition instead of doing an assignment first.  Also there is a
check for "ret" when we know it is zero so we can remove that.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This change will also make Coverity happy by avoiding a theoretical NULL
pointer dereference; yet another reason is to use the above helper function
to tighten the code and make it more readable.
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This driver only has runtime but no build time dependencies, so it can be
built for testing purposes if the Kconfig COMPILE_TEST option is enabled.

This is useful to have more build coverage and make sure that drivers are
not affected by changes that could cause build regressions.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

As the TRM says, add the tsadc_q_sel to control the temperature-code
sequence since the rk3228/rk3399 need set this bit (1024 - tsadc_q)
as output.

Fixes: commit
b0d70338 "thermal: rockchip: Support the RK3399 SoCs in thermal driver"
7b02a5e7 "thermal: rockchip: Support the RK3228 SoCs in thermal driver"
Reported-by: NElaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This patch renames to be more adapter compatibles since more and more
SoCs are supported in thermal driver.
Reported-by: NHuang,Tao <huangtao@rock-chips.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

the calculation use a global table, not their own table.
so adapt the table to the correct one.
Signed-off-by: NElaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df217
("thermal: rockchip: consistently use int for temperatures")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Remove all checkpatch.pl --strict errors, checks, and warnings.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This adds support for the Mediatek thermal controller found on MT8173
and likely other SoCs.
The controller is a bit special. It does not have its own ADC, instead
it controls the on-SoC AUXADC via AHB bus accesses. For this reason
we need the physical address of the AUXADC. Also it controls a mux
using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

In __cpufreq_cooling_register() we allocate the arrays for time_in_idle
and time_in_idle_timestamp to be as big as the number of cpus in this
cpufreq device.  However, in get_load() we access this array using the
cpu number as index, which can result in an out of bound access.

Index time_in_idle{,_timestamp} using the index in the cpufreq_device's
allowed_cpus mask, as we do for the load_cpu array in
cpufreq_get_requested_power()
Reported-by: NNicolas Boichat <drinkcat@chromium.org>
Cc: Amit Daniel Kachhap <amit.kachhap@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Tested-by: NNicolas Boichat <drinkcat@chromium.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

When the thermal subsystem is a loadable module, the u8500 driver
fails to build:

drivers/thermal/built-in.o: In function `db8500_thermal_probe':
db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register'
drivers/thermal/built-in.o: In function `db8500_thermal_work':
db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update'

This changes the symbol to a tristate, so Kconfig can track the
dependency correctly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

When the thermal subsystem is a loadable module, the spear driver
fails to build:

drivers/thermal/built-in.o: In function `spear_thermal_exit':
spear_thermal.c:(.text+0xf8): undefined reference to `thermal_zone_device_unregister'
drivers/thermal/built-in.o: In function `spear_thermal_probe':
spear_thermal.c:(.text+0x230): undefined reference to `thermal_zone_device_register'

This changes the symbol to a tristate, so Kconfig can track the
dependency correctly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The spear thermal driver hides its suspend/resume function conditionally
based on CONFIG_PM, but references them based on CONFIG_PM_SLEEP, so
we get a warning if the former is set but the latter is not:

thermal/spear_thermal.c:58:12: warning: 'spear_thermal_suspend' defined but not used [-Wunused-function]
thermal/spear_thermal.c:75:12: warning: 'spear_thermal_resume' defined but not used [-Wunused-function]

This removes the #ifdef and instead uses a __maybe_uninitialized
annotation to avoid the warning and improve compile-time coverage.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This patch enables to use thermal-zone on DT if it was calles as
"renesas,rcar-thermal-gen2".
Previous style (= non thermal-zone) is still supported by
"renesas,rcar-thermal" to keep compatibility for "git bisect".
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Use for_each_available_child_of_node() for iterating over each
available child instead of iterating over each child and then
checking their status.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

trip_point_temp_store() updates trip temperature. It should call
thermal_zone_device_update() immediately.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Current rcar thermal driver sometimes checks irq possibility when it
calls rcar_thermal_irq_enable/disable(), but sometimes not.
This patch checks it inside rcar_thermal_irq_enable/disable().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Every rcar_thermal_update_temp() return value will be checked.

And also, rcar_thermal_get_temp() always call
rcar_thermal_update_temp() by this patch.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This patch is prepare for of-thermal support.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The RK3399 SoCs have two Temperature Sensors, channel 0 is for CPU.
channel 1 is for GPU.
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The RK3228 SoCs has one Temperature Sensor, channel 0 is for CPU.
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

This patchset trys to dictate unified format for driver.
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

Signed-off-by: NAmy Wiles <amy.l.wiles@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

The pch_dev_ops structure is never modified.  It is only stored in a field
that is already declared as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

When a new cooling device is registered, we need to update the
thermal zone to set the new registered cooling device to a proper
state.

This fixes a problem that the system is cool, while the fan devices
are left running on full speed after boot, if fan device is registered
after thermal zone device.

Here is the history of why current patch looks like this:
https://patchwork.kernel.org/patch/7273041/

CC: <stable@vger.kernel.org> #3.18+
Reference:https://bugzilla.kernel.org/show_bug.cgi?id=92431Tested-by: NManuel Krause <manuelkrause@netscape.net>
Tested-by: Nszegad <szegadlo@poczta.onet.pl>
Tested-by: Nprash <prash.n.rao@gmail.com>
Tested-by: Namish <ammdispose-arch@yahoo.com>
Reviewed-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>

Current thermal code does not handle system sleep well because
1. the cooling device cooling state may be changed during suspend
2. the previous temperature reading becomes invalid after resumed because
   it is got before system sleep
3. updating thermal zone device during suspending/resuming
   is wrong because some devices may have already been suspended
   or may have not been resumed.

Thus, the proper way to do this is to cancel all thermal zone
device update requirements during suspend/resume, and after all
the devices have been resumed, reset and update every registered
thermal zone devices.

This also fixes a regression introduced by:
Commit 19593a1f ("ACPI / fan: convert to platform driver")
Because, with above commit applied, all the fan devices are attached
to the acpi_general_pm_domain, and they are turned on by the pm_domain
automatically after resume, without the awareness of thermal core.

CC: <stable@vger.kernel.org> #3.18+
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78201
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=91411Tested-by: NManuel Krause <manuelkrause@netscape.net>
Tested-by: Nszegad <szegadlo@poczta.onet.pl>
Tested-by: Nprash <prash.n.rao@gmail.com>
Tested-by: Namish <ammdispose-arch@yahoo.com>
Tested-by: NMatthias <morpheusxyz123@yahoo.de>
Reviewed-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>

After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().

Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.

CC: <stable@vger.kernel.org> #3.18+
Tested-by: NManuel Krause <manuelkrause@netscape.net>
Tested-by: Nszegad <szegadlo@poczta.onet.pl>
Tested-by: Nprash <prash.n.rao@gmail.com>
Tested-by: Namish <ammdispose-arch@yahoo.com>
Tested-by: NMatthias <morpheusxyz123@yahoo.de>
Reviewed-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NChen Yu <yu.c.chen@intel.com>

The read and write opcodes are global for all units on SoC and even across
Intel SoCs. Remove duplication of corresponding constants. At the same time
convert all current users.

No functional change.
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NBoon Leong Ong <boon.leong.ong@intel.com>
Acked-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The IMX6Q/IMX6DL SoC's have a 2-bit temperature grade stored in OTP which
is valid for all IMX6 SoC's (despite the fact that the IMXSDLRM and
IMXSXRM do not document this - this has been proven via tests as well as
verified by Freescale FAE).

Instead of assuming a fixed 85C for passive cooling threshold and 105C for
critical use the thermal grade for these configurations.

We will set the critical to maxT - 5C and passive to maxT - 10C.

Cc: Anson Huang <b20788@freescale.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NJon Nettleton <jon@solid-run.com>
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
----
v3:
 - rebase against linux-soc-thermal.git
 - added ack's from Shawn and Jon
v2:
 - remove check for IMX6Q and update comments: The OTP values have been tested
   on IMX6SOLO, IMX6DUALLITE, and IMX6SX and Freescale FAE has shared data with
   me that the OTP settings are the same and that the reference manuals will
   reflect this in their next updates.
 - set critical to max - 5C
 - set passive to max - 10C
 - display max temp in info
 - do not allow passive to be set above critical
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>