Noemi Alvarez | 29 Jul 10:23 2014


I want to keep up with you with hope for friendship if you are interested.
If you don't mind i will like you to write me back. I am waiting to read
from you, because i have something important and urgent to discuss with
you. I will also send some of my beautiful photos to you.

To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at>
More majordomo info at

Prarit Bhargava | 29 Jul 13:46 2014

[PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[v2]: Fixed wording of commit, and added additional testing information.

A while ago we added a test to mimic some of our users' userspace governor
programs which monitor system behaviour and will switch governors on the
fly.  The decision process for this includes looking at time of day,
expected system load, etc.  For some time now we have had reports of
system panics in the cpufreq code when using the userspace governor

The userspace utility writes
/sys/devices/system/cpu/cpuX/cpufreq/scaling_governor and sets the
governor.  In some cases this can happen rapidly, and under heavy load
there are occasions where the changes are delayed.  This can mean that
several governor changes may occur within a short period of time.

This has exposed a bug in the store_scaling_governor path.  When the sysfs
file is written to,

		-> cpufreq_set_policy()
			__cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT);

The release of the policy->rwsem results in a situation where another
write to the scaling_governor file can now start and overwrite pointers
and cause corruption.

(Continue reading)

Thomas Abraham | 29 Jul 07:28 2014

[PATCH v8 0/6] cpufreq: use generic cpufreq drivers for exynos platforms

Changes since v7:
- Fixes suggested by Tomasz Figa.

This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq
drivers and enables the use of cpufreq-cpu0 driver for these platforms. This
series also enables cpufreq support for Exynos5420 using arm_big_little cpufreq

This patch series is dependent on two other patches
1. ARM: dts: add CPU nodes for Exynos4 SoCs
2. ARM: dts: smdk5250: Specify MAX77686 pmic interrupt

Since there are significant changes since v7, the Tested-by and Acked-by tags
for all the patches in this series have been dropped.

Thomas Abraham (6):
  clk: samsung: add infrastructure to register cpu clocks
  clk: samsung: add cpu clock configuration data and instantiate cpu clock
  ARM: dts: Exynos: add CPU OPP and regulator supply property
  ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
  cpufreq: exynos: remove exynos4210/5250 specific cpufreq driver support
  clk: samsung: remove unused clock aliases and update clock flags

 arch/arm/boot/dts/exynos4210-origen.dts         |    6 +
 arch/arm/boot/dts/exynos4210-trats.dts          |    6 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts |    6 +
 arch/arm/boot/dts/exynos4210.dtsi               |   12 +
 arch/arm/boot/dts/exynos5250-arndale.dts        |    6 +
(Continue reading)

weiyj_lk | 28 Jul 15:14 2014

[PATCH -next] ipaq_micro_battery: fix sparse non static symbol warning

From: Wei Yongjun <yongjun_wei <at>>

Fixes the following sparse warnings:

drivers/power/ipaq_micro_battery.c:278:24: warning:
 symbol 'micro_batt_device_driver' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <yongjun_wei <at>>
 drivers/power/ipaq_micro_battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/ipaq_micro_battery.c b/drivers/power/ipaq_micro_battery.c
index 54632ea..9d69460 100644
--- a/drivers/power/ipaq_micro_battery.c
+++ b/drivers/power/ipaq_micro_battery.c
 <at>  <at>  -275,7 +275,7  <at>  <at>  static const struct dev_pm_ops micro_batt_dev_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(micro_batt_suspend, micro_batt_resume)

-struct platform_driver micro_batt_device_driver = {
+static struct platform_driver micro_batt_device_driver = {
 	.driver		= {
 		.name	= "ipaq-micro-battery",
 		.pm	= &micro_batt_dev_pm_ops,

To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at>
More majordomo info at
(Continue reading)

Paul Bolle | 28 Jul 14:47 2014



Your commit 78c5e0bb145d ("PM / OPP: Remove ARCH_HAS_OPP") landed in
today's linux-next (ie, next-20140728). It removes the Kconfig symbol
ARCH_HAS_OPP and ten select statements for that symbol.

After that commit there are still nine select statements for that symbol
left in linux-next. (These select statements are now actually NOPs.) The
peculiar thing is that these nine statements are all found in Kconfig
files also touched by that commit.

Anyhow, are patches to remove these pointless select statements queued

Paul Bolle

To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at>
More majordomo info at

Sachin Kamat | 28 Jul 06:58 2014

[PATCH 1/1] cpuidle: big_little: Fix build error

big_little CPU idle driver references functions defined in MCPM driver.
Thus make it depend on MCPM to avoid the following errors:

drivers/built-in.o: In function `bl_enter_powerdown':
drivers/cpuidle/cpuidle-big_little.c:134: undefined reference to `mcpm_cpu_powered_up'
drivers/built-in.o: In function `bl_powerdown_finisher':
drivers/cpuidle/cpuidle-big_little.c:104: undefined reference to `mcpm_set_entry_vector'
drivers/cpuidle/cpuidle-big_little.c:111: undefined reference to `mcpm_cpu_suspend'
make: *** [vmlinux] Error 1

Reported-by: Andreas Färber <afaerber <at>>
Signed-off-by: Sachin Kamat <sachin.kamat <at>>
 drivers/cpuidle/Kconfig.arm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index 33fc0ff..38cff69 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
 <at>  <at>  -4,6 +4,7  <at>  <at> 
 	bool "Support for ARM big.LITTLE processors"
+	depends on MCPM

(Continue reading)

Randy Dunlap | 28 Jul 01:17 2014

[PATCH] PM: fix kernel-doc warnings in drivers/base/power/main.c

From: Randy Dunlap <rdunlap <at>>

Fix kernel-doc warnings in drivers/base/power/main.c:

Warning(..//drivers/base/power/main.c:473): No description found for parameter 'async'
Warning(..//drivers/base/power/main.c:601): No description found for parameter 'async'
Warning(..//drivers/base/power/main.c:1012): No description found for parameter 'async'
Warning(..//drivers/base/power/main.c:1151): No description found for parameter 'async'
Warning(..//drivers/base/power/main.c:1305): No description found for parameter 'info'

Signed-off-by: Randy Dunlap <rdunlap <at>>
Cc:	"Rafael J. Wysocki" <rjw <at>>
Cc:	Len Brown <len.brown <at>>
Cc:	Pavel Machek <pavel <at>>
Cc:	linux-pm <at>
 drivers/base/power/main.c |    5 +++++
 1 file changed, 5 insertions(+)

Index: lnx-316-rc7/drivers/base/power/main.c
--- lnx-316-rc7.orig/drivers/base/power/main.c
+++ lnx-316-rc7/drivers/base/power/main.c
 <at>  <at>  -465,6 +465,7  <at>  <at>  static void dpm_watchdog_clear(struct dp
  * device_resume_noirq - Execute an "early resume" callback for given device.
  *  <at> dev: Device to handle.
  *  <at> state: PM transition of the system being carried out.
+ *  <at> async: If true, the device is being resumed asynchronously.
  * The driver of  <at> dev will not receive interrupts while this function is being
(Continue reading)

Rafael J. Wysocki | 28 Jul 01:13 2014

[RFC][PATCH] PM / sleep: Rename symbols, functions and variables related to sleep

From: Rafael J. Wysocki <rafael.j.wysocki <at>>

The names of several symbols, data types, functions and variables
related to system sleep states are confusing and don't reflect the
real behavior of those states correctly.

First of all, there generally are two sleep states that require
platform support and one sleep state that is platform-independent.
The first two of them are currently known as MEM and STANDBY,
although these names really only match what the states do on full
hardware ACPI compliant systems.  MEM in particular is supposed
to mean "suspend-to-RAM", but in fact it means "the deepest sleep
state available with platform support".  The definition of STANDBY
is even more arbitrary.

Moreover, the remaining sleep state that doesn't need platform support
is currently called FREEZE, which leads to double confusion with the
process freezer (used during transitions to all sleep states) and
with the freeze stage of processing devices during hibernation.

For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
everywhere and rename data types, functions and variables related to
those states to match the new names of the symbols.

This is a semi-mechanical replacement of names and it should not lead
to any functional differences.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki <at>>
(Continue reading)

Lina Iyer | 25 Jul 18:55 2014

[RFC] [PATCH 0/3] IRQ affinity notifier and per-cpu PM QoS

This series of patches adds a new feature to allow per-cpu PM QoS.

The first of the patch, modifies the irq manager to allow multiple clients for
IRQ SMP affinity change notification. Today, only one client can register a
notification per IRQ. The PM QoS framework is also now interested in knowing
when the SMP affinity changes for an IRQ. With the current implementation, a
second registration on the change notification releases the current
notification callbacks and registers the new one. Modify the notification
mechanism to use a list for notification instead of single data structure.
Also, a client that wants to de-register from the notification will now need to
call a separate API instead of the overloaded function call with a NULL

The next two patches re-organize PM QoS framework to allow QoS and the Dev PM
QoS frameworks to specify a request type. Most requestors of PM QoS do not know
or care about the CPU(s) the QoS needs to be effected. In many cases, it is
still desirable to have the QoS apply on all available cpus. However, in
conjunction with an IRQ balancer or a driver that has specific cpu(s)
requirement for its use, can specify a QoS request only for that set of cpus.
For example in a case, where a certain IRQ might need a performance QoS, but
does not want to affect the general power consumption of all the cpus in the
system, can specify an QoS request thats affine only to that cpu(s), where the
IRQ can be triggered.

The change adds ability to specify the PM QoS request types and two new PM QoS
request types in addition to the default that applies to all cpus.

PM_QOS_REQ_AFFINE_CORES: This allows drivers to specify a certain set of cpus
that the request should be applied on.

(Continue reading)

Laxman Dewangan | 25 Jul 12:01 2014

[PATCH] thermal: add support to disable thermal zone from DTS

Add support to check status of the thermal zone before registering the
zone. This will help on disabling some non-existing thermal zone from
the top level DTS file out of common dtsi thermalzone file.

For example,
we have 3 platforms almost same but thermal zones on this platform are
little bit different. Platform 1 and 2 have three thermal zones and
platform 3 has two thermal zones. To avoid duplication of the thermal
zones entries on each DTS file of platforms,we created one common
dtsi file for thermal zone and included this dtsi file from these
3 platform's top level dts file.

On common thermal zone com dtsi file, all thermal zone are enabled and
need to disable one of thermal zone on platform 3 dts file. For this, we
just added entry status = "disabled" for that thermal zone on platform 3
dts file and along with this change to make it work.

This way, we reuse the common file and control the enable/disable of the
thermal zone from top level dts file.

Signed-off-by: Laxman Dewangan <ldewangan <at>>
 drivers/thermal/of-thermal.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 4b2b999..f8eb625 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
 <at>  <at>  -401,6 +401,10  <at>  <at>  thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
(Continue reading)

Laxman Dewangan | 25 Jul 11:19 2014

[PATCH-REPOST] thermal: of: look for sensor driver parent node if device node missing

There are some mfd devices which supports junction thermal interrupt
like ams,AS3722. The DT binding of these devices are defined as the
flat and drivers for sub module of such devices are registered as
the mfd_add_devices. In this method, the sub devices registered as
platform driver and these do not have the of_node pointer on their
device structure. In this case, use the parent of_node pointer to
get the required of_node pointer.

Signed-off-by: Laxman Dewangan <ldewangan <at>>
I typed differnet email ID for Eduardo and so it did not reach to him.
Resending the patch with correct ID.

 drivers/thermal/of-thermal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 04b1be7..85a7d71 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
 <at>  <at>  -396,6 +396,8  <at>  <at>  thermal_zone_of_sensor_register(struct device *dev, int sensor_id,
 		return ERR_PTR(-EINVAL);

 	sensor_np = dev->of_node;
+	if (!sensor_np && dev->parent)
+		sensor_np = dev->parent->of_node;

 	for_each_child_of_node(np, child) {
 		struct of_phandle_args sensor_specs;

(Continue reading)