<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/cpufreq/Kconfig, branch v4.4.35</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>cpufreq: qoriq: rename the driver</title>
<updated>2015-03-18T21:35:16+00:00</updated>
<author>
<name>Tang Yuantian</name>
<email>Yuantian.Tang@freescale.com</email>
</author>
<published>2015-03-13T04:39:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2f249358eedaf81cede7fb0927ed0bd9c1ae2de7'/>
<id>2f249358eedaf81cede7fb0927ed0bd9c1ae2de7</id>
<content type='text'>
This driver works on all QorIQ platforms which include
ARM-based cores and PPC-based cores.
Rename it in order to represent better.

Signed-off-by: Tang Yuantian &lt;Yuantian.Tang@freescale.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver works on all QorIQ platforms which include
ARM-based cores and PPC-based cores.
Rename it in order to represent better.

Signed-off-by: Tang Yuantian &lt;Yuantian.Tang@freescale.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rcu: Make SRCU optional by using CONFIG_SRCU</title>
<updated>2015-01-06T19:04:29+00:00</updated>
<author>
<name>Pranith Kumar</name>
<email>bobby.prani@gmail.com</email>
</author>
<published>2014-12-05T16:24:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=83fe27ea531161a655f02dc7732d14cfaa27fd5d'/>
<id>83fe27ea531161a655f02dc7732d14cfaa27fd5d</id>
<content type='text'>
SRCU is not necessary to be compiled by default in all cases. For tinification
efforts not compiling SRCU unless necessary is desirable.

The current patch tries to make compiling SRCU optional by introducing a new
Kconfig option CONFIG_SRCU which is selected when any of the components making
use of SRCU are selected.

If we do not select CONFIG_SRCU, srcu.o will not be compiled at all.

   text    data     bss     dec     hex filename
   2007       0       0    2007     7d7 kernel/rcu/srcu.o

Size of arch/powerpc/boot/zImage changes from

   text    data     bss     dec     hex filename
 831552   64180   23944  919676   e087c arch/powerpc/boot/zImage : before
 829504   64180   23952  917636   e0084 arch/powerpc/boot/zImage : after

so the savings are about ~2000 bytes.

Signed-off-by: Pranith Kumar &lt;bobby.prani@gmail.com&gt;
CC: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
CC: Josh Triplett &lt;josh@joshtriplett.org&gt;
CC: Lai Jiangshan &lt;laijs@cn.fujitsu.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
[ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SRCU is not necessary to be compiled by default in all cases. For tinification
efforts not compiling SRCU unless necessary is desirable.

The current patch tries to make compiling SRCU optional by introducing a new
Kconfig option CONFIG_SRCU which is selected when any of the components making
use of SRCU are selected.

If we do not select CONFIG_SRCU, srcu.o will not be compiled at all.

   text    data     bss     dec     hex filename
   2007       0       0    2007     7d7 kernel/rcu/srcu.o

Size of arch/powerpc/boot/zImage changes from

   text    data     bss     dec     hex filename
 831552   64180   23944  919676   e087c arch/powerpc/boot/zImage : before
 829504   64180   23952  917636   e0084 arch/powerpc/boot/zImage : after

so the savings are about ~2000 bytes.

Signed-off-by: Pranith Kumar &lt;bobby.prani@gmail.com&gt;
CC: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
CC: Josh Triplett &lt;josh@joshtriplett.org&gt;
CC: Lai Jiangshan &lt;laijs@cn.fujitsu.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
[ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: Kconfig: Remove architecture specific menu entries</title>
<updated>2014-11-18T01:47:42+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2014-11-15T03:20:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f41f4815f8e81e8745fca8396d842adb74689c88'/>
<id>f41f4815f8e81e8745fca8396d842adb74689c88</id>
<content type='text'>
CPUFreq driver's Kconfig entries are added in Kconfig.&lt;arch&gt; files and they are
all included from the main Kconfig file using a menu entry. This creates another
level of (unnecessary) hierarchy within the menuconfig entries.

The problem occurs when there are drivers usable across architectures. Either
their config entry is duplicated in all the supported architectures or is put
into the main Kconfig entry. With the later one, we have menuconfig entries for
drivers at two levels then.

Fix these issues by getting rid of another level of menuconfig hierarchy and
populate all drivers within the main cpufreq menu. To clearly distinguish where
the drivers start from, also add a comment that will appear in menuconfig.

Reported-by: Tang Yuantian &lt;Yuantian.Tang@freescale.com&gt;
Suggested-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CPUFreq driver's Kconfig entries are added in Kconfig.&lt;arch&gt; files and they are
all included from the main Kconfig file using a menu entry. This creates another
level of (unnecessary) hierarchy within the menuconfig entries.

The problem occurs when there are drivers usable across architectures. Either
their config entry is duplicated in all the supported architectures or is put
into the main Kconfig entry. With the later one, we have menuconfig entries for
drivers at two levels then.

Fix these issues by getting rid of another level of menuconfig hierarchy and
populate all drivers within the main cpufreq menu. To clearly distinguish where
the drivers start from, also add a comment that will appear in menuconfig.

Reported-by: Tang Yuantian &lt;Yuantian.Tang@freescale.com&gt;
Suggested-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: Loongson1: Add cpufreq driver for Loongson1B</title>
<updated>2014-11-06T00:23:44+00:00</updated>
<author>
<name>Kelvin Cheung</name>
<email>keguang.zhang@gmail.com</email>
</author>
<published>2014-10-17T10:23:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a0a22cf14472fa5cd44c8d107eba1a827df9549c'/>
<id>a0a22cf14472fa5cd44c8d107eba1a827df9549c</id>
<content type='text'>
This patch adds cpufreq driver for Loongson1B which
is capable of changing the CPU frequency dynamically.

Signed-off-by: Kelvin Cheung &lt;keguang.zhang@gmail.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds cpufreq driver for Loongson1B which
is capable of changing the CPU frequency dynamically.

Signed-off-by: Kelvin Cheung &lt;keguang.zhang@gmail.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: allow powersave governor as the default without expert mode</title>
<updated>2014-11-05T23:44:28+00:00</updated>
<author>
<name>James Geboski</name>
<email>jgeboski@gmail.com</email>
</author>
<published>2014-10-16T11:37:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b3a826c05bd96122fd54c297062c495dbcc7511e'/>
<id>b3a826c05bd96122fd54c297062c495dbcc7511e</id>
<content type='text'>
The intel_pstate driver only supports the performance and the powersave
governors. With the performance governor ensuring the highest possible
performance settings, userspace tools fail to make any lasting changes.
In order to allow userspace tools to make modifications to the settings,
the powersave governor must be in use. This makes having the powersave
governor as the default convenient for systems where the intel_pstate
driver is being employed. Having to enable expert mode in the kernel
configuration is just a headache for such a trivial task.

This patch applies to all kernel versions 2.6.38 or greater after the
migration from CONFIG_EMBEDDED to CONFIG_EXPERT (6a108a14fa35). Most
importantly, this applies to kernel versions 3.9 or greater when the
intel_pstate driver was introduced.

Signed-off-by: James Geboski &lt;jgeboski@gmail.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The intel_pstate driver only supports the performance and the powersave
governors. With the performance governor ensuring the highest possible
performance settings, userspace tools fail to make any lasting changes.
In order to allow userspace tools to make modifications to the settings,
the powersave governor must be in use. This makes having the powersave
governor as the default convenient for systems where the intel_pstate
driver is being employed. Having to enable expert mode in the kernel
configuration is just a headache for such a trivial task.

This patch applies to all kernel versions 2.6.38 or greater after the
migration from CONFIG_EMBEDDED to CONFIG_EXPERT (6a108a14fa35). Most
importantly, this applies to kernel versions 3.9 or greater when the
intel_pstate driver was introduced.

Signed-off-by: James Geboski &lt;jgeboski@gmail.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'</title>
<updated>2014-10-03T13:37:54+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2014-09-09T14:28:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bbcf071969b20f356877c8067986be0a2dcaa2aa'/>
<id>bbcf071969b20f356877c8067986be0a2dcaa2aa</id>
<content type='text'>
The naming convention of this driver was always under the scanner, people
complained that it should have a more generic name than cpu0, as it manages all
CPUs that are sharing clock lines.

Also, in future it will be modified to support any number of clusters with
separate clock/voltage lines.

Lets rename it to 'cpufreq_dt' from 'cpufreq_cpu0'.

Tested-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The naming convention of this driver was always under the scanner, people
complained that it should have a more generic name than cpu0, as it manages all
CPUs that are sharing clock lines.

Also, in future it will be modified to support any number of clusters with
separate clock/voltage lines.

Lets rename it to 'cpufreq_dt' from 'cpufreq_cpu0'.

Tested-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency</title>
<updated>2014-06-16T20:33:38+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2014-06-13T08:40:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=217886d3f3191f1f052e987740ee2bb32a4fd316'/>
<id>217886d3f3191f1f052e987740ee2bb32a4fd316</id>
<content type='text'>
5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
REGULATOR") was a little too quick in completely removing the dependency
on the THERMAL driver.

The problem is that while there are inline wrappers to turn the thermal
API calls into empty functions, those do not help if the cpu-thermal
driver is a loadable module and cpufreq-cpu0 is builtin.

Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
code is built into the thermal module or not, we have to use a dependency
on the thermal driver itself. However, if CPU_THERMAL is disabled, we
don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
construct.

Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Tested-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
REGULATOR") was a little too quick in completely removing the dependency
on the THERMAL driver.

The problem is that while there are inline wrappers to turn the thermal
API calls into empty functions, those do not help if the cpu-thermal
driver is a loadable module and cpufreq-cpu0 is builtin.

Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
code is built into the thermal module or not, we have to use a dependency
on the thermal driver itself. However, if CPU_THERMAL is disabled, we
don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
construct.

Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Tested-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR</title>
<updated>2014-06-10T20:52:35+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2014-06-10T05:09:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5fbfbcd3e842ddfe9dbbe8865feba909963a87ec'/>
<id>5fbfbcd3e842ddfe9dbbe8865feba909963a87ec</id>
<content type='text'>
cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't
depend on it as there are dummy calls provided by thermal layer when
CONFIG_THERMAL=n. And when these calls fail, the driver is still usable.

Similar explanation is valid for regulators as well. We do have dummy calls
available for regulator APIs and the driver can work even when those calls
fail.

So, we don't really need to mention thermal and regulators as a dependency for
cpufreq-cpu0 in Kconfig as platforms without support for thermal/regulator can
also use this driver. Remove this dependency.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't
depend on it as there are dummy calls provided by thermal layer when
CONFIG_THERMAL=n. And when these calls fail, the driver is still usable.

Similar explanation is valid for regulators as well. We do have dummy calls
available for regulator APIs and the driver can work even when those calls
fail.

So, we don't really need to mention thermal and regulators as a dependency for
cpufreq-cpu0 in Kconfig as platforms without support for thermal/regulator can
also use this driver. Remove this dependency.

Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpufreq: enable ARM drivers on arm64</title>
<updated>2014-02-28T15:03:17+00:00</updated>
<author>
<name>Rob Herring</name>
<email>rob.herring@calxeda.com</email>
</author>
<published>2014-02-24T02:27:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=addea9ef055bf5a10f9ec967b1e0443ceb44bd83'/>
<id>addea9ef055bf5a10f9ec967b1e0443ceb44bd83</id>
<content type='text'>
Enable cpufreq and power kconfig menus on arm64 along with arm cpufreq
drivers. The power menu is needed for OPP support. At least on Calxeda
systems, the same cpufreq driver is used for arm and arm64 based
systems.

Signed-off-by: Rob Herring &lt;rob.herring@calxeda.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable cpufreq and power kconfig menus on arm64 along with arm cpufreq
drivers. The power menu is needed for OPP support. At least on Calxeda
systems, the same cpufreq driver is used for arm and arm64 based
systems.

Signed-off-by: Rob Herring &lt;rob.herring@calxeda.com&gt;
Acked-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux</title>
<updated>2014-01-25T01:13:49+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-01-25T01:13:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=91466574be1a3701fab4abf5ac1539b556575a81'/>
<id>91466574be1a3701fab4abf5ac1539b556575a81</id>
<content type='text'>
Pull thermal management updates from Zhang Rui:
 "This time, the biggest change is the work of representing hardware
  thermal properties in device tree infrastructure.

  This work includes the introduction of a device tree bindings for
  describing the hardware thermal behavior and limits, and also a parser
  to read and interpret the data, and build thermal zones and thermal
  binding parameters.  It also contains three examples on how to use the
  new representation on sensor devices, using three different drivers to
  accomplish it.  One driver is in thermal subsystem, the TI SoC
  thermal, and the other two drivers are in hwmon subsystem.

  Actually, this would be the first step of the complete work because we
  still need to check other potential drivers to be converted and then
  validate the proposed API.  But the reason why I include it in this
  pull request is that, first, this change does not hurt any others
  without using this approach, second, the principle and concept of this
  change would not break after converting the remaining drivers.  BTW,
  as you can see, there are several points in this change that do not
  belong to thermal subsystem.  Because it has been suggested by Guenter
  R that in such cases, it is recommended to send the complete series
  via one single subsystem.

  Specifics:

   - representing hardware thermal properties in device tree
     infrastructure

   - fix a regression that the imx thermal driver breaks system suspend.

   - introduce ACPI INT3403 thermal driver to retrieve temperature data
     from the INT3403 ACPI device object present on some systems.

   - introduce debug statement for thermal core and step_wise governor.

   - assorted fixes and cleanups for thermal core, cpu cooling, exynos
     thrmal, intel powerclamp and imx thermal driver"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (34 commits)
  thermal: remove const flag from .ops of imx thermal
  Thermal: update thermal zone device after setting emul_temp
  intel_powerclamp: Fix cstate counter detection.
  thermal: imx: add necessary clk operation
  Thermal cpu cooling: return error if no valid cpu frequency entry
  thermal: fix cpu_cooling max_level behavior
  thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST
  thermal: debug: add debug statement for core and step_wise
  thermal: imx_thermal: add module device table
  drivers: thermal: Mark function as static in x86_pkg_temp_thermal.c
  thermal:samsung: fix compilation warning
  thermal: imx: correct suspend/resume flow
  thermal: exynos: fix error return code
  Thermal: ACPI INT3403 thermal driver
  MAINTAINERS: add thermal bindings entry in thermal domain
  arm: dts: make OMAP4460 bandgap node to belong to OCP
  arm: dts: make OMAP443x bandgap node to belong to OCP
  arm: dts: add cooling properties on omap5 cpu node
  arm: dts: add omap5 thermal data
  arm: dts: add omap5 CORE thermal data
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull thermal management updates from Zhang Rui:
 "This time, the biggest change is the work of representing hardware
  thermal properties in device tree infrastructure.

  This work includes the introduction of a device tree bindings for
  describing the hardware thermal behavior and limits, and also a parser
  to read and interpret the data, and build thermal zones and thermal
  binding parameters.  It also contains three examples on how to use the
  new representation on sensor devices, using three different drivers to
  accomplish it.  One driver is in thermal subsystem, the TI SoC
  thermal, and the other two drivers are in hwmon subsystem.

  Actually, this would be the first step of the complete work because we
  still need to check other potential drivers to be converted and then
  validate the proposed API.  But the reason why I include it in this
  pull request is that, first, this change does not hurt any others
  without using this approach, second, the principle and concept of this
  change would not break after converting the remaining drivers.  BTW,
  as you can see, there are several points in this change that do not
  belong to thermal subsystem.  Because it has been suggested by Guenter
  R that in such cases, it is recommended to send the complete series
  via one single subsystem.

  Specifics:

   - representing hardware thermal properties in device tree
     infrastructure

   - fix a regression that the imx thermal driver breaks system suspend.

   - introduce ACPI INT3403 thermal driver to retrieve temperature data
     from the INT3403 ACPI device object present on some systems.

   - introduce debug statement for thermal core and step_wise governor.

   - assorted fixes and cleanups for thermal core, cpu cooling, exynos
     thrmal, intel powerclamp and imx thermal driver"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (34 commits)
  thermal: remove const flag from .ops of imx thermal
  Thermal: update thermal zone device after setting emul_temp
  intel_powerclamp: Fix cstate counter detection.
  thermal: imx: add necessary clk operation
  Thermal cpu cooling: return error if no valid cpu frequency entry
  thermal: fix cpu_cooling max_level behavior
  thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST
  thermal: debug: add debug statement for core and step_wise
  thermal: imx_thermal: add module device table
  drivers: thermal: Mark function as static in x86_pkg_temp_thermal.c
  thermal:samsung: fix compilation warning
  thermal: imx: correct suspend/resume flow
  thermal: exynos: fix error return code
  Thermal: ACPI INT3403 thermal driver
  MAINTAINERS: add thermal bindings entry in thermal domain
  arm: dts: make OMAP4460 bandgap node to belong to OCP
  arm: dts: make OMAP443x bandgap node to belong to OCP
  arm: dts: add cooling properties on omap5 cpu node
  arm: dts: add omap5 thermal data
  arm: dts: add omap5 CORE thermal data
  ...
</pre>
</div>
</content>
</entry>
</feed>
