Amit Daniel Kachhap | 30 Oct 13:24 2014

[PATCH v2] arm64: psci: fix cpu_suspend to check idle state type for index

This fix rectifies the psci cpu_suspend implementation to check the
PSCI power state parameter type field associated with the requested idle
state index.

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi <at> arm.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel <at> samsung.com>
---
 arch/arm64/kernel/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 866c1c8..663da77 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
 <at>  <at>  -528,7 +528,7  <at>  <at>  static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
 	if (WARN_ON_ONCE(!index))
 		return -EINVAL;

-	if (state->type == PSCI_POWER_STATE_TYPE_STANDBY)
+	if (state[index - 1].type == PSCI_POWER_STATE_TYPE_STANDBY)
 		ret = psci_ops.cpu_suspend(state[index - 1], 0);
 	else
 		ret = __cpu_suspend(index, psci_suspend_finisher);
--

-- 
1.9.1

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

Amit Daniel Kachhap | 30 Oct 04:55 2014

[PATCH 1/3] arm64: psci: warn if psci_power_state variable is not initialised

Without this cpu_suspend may cause crash dump when psci cpuidle
is not initialised and cpu_suspend is called.

Signed-off-by: Amit Daniel Kachhap <amit.daniel <at> samsung.com>
---
 arch/arm64/kernel/psci.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 866c1c8..2178d6e 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
 <at>  <at>  -523,9 +523,11  <at>  <at>  static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
 	struct psci_power_state *state = __get_cpu_var(psci_power_state);
 	/*
 	 * idle state index 0 corresponds to wfi, should never be called
-	 * from the cpu_suspend operations
+	 * from the cpu_suspend operations.
+	 * Also psci_power_state variable should have been populated by
+	 * above init idle routine.
 	 */
-	if (WARN_ON_ONCE(!index))
+	if (WARN_ON_ONCE(!index || !state))
 		return -EINVAL;

 	if (state->type == PSCI_POWER_STATE_TYPE_STANDBY)
--

-- 
1.9.1

--
(Continue reading)

Marek Szyprowski | 29 Oct 14:13 2014

[PATCH 1/2] power: reset: add driver for Hardkernel's Odroid boards

This patch adds a driver implementing correct reboot and poweroff
procedures for Exynos4412-based Hardkernel's Odroid X/X2/U2/U3/U3+
boards.

Signed-off-by: Marek Szyprowski <m.szyprowski <at> samsung.com>
---
 .../bindings/power/reset/odroid-reset.txt          |  18 ++++
 drivers/power/reset/Kconfig                        |   6 ++
 drivers/power/reset/Makefile                       |   1 +
 drivers/power/reset/odroid-reboot.c                | 119 +++++++++++++++++++++
 4 files changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/reset/odroid-reset.txt
 create mode 100644 drivers/power/reset/odroid-reboot.c

diff --git a/Documentation/devicetree/bindings/power/reset/odroid-reset.txt b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
new file mode 100644
index 000000000000..86471a463518
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
 <at>  <at>  -0,0 +1,18  <at>  <at> 
+* Device tree bindings for Hardkernel's Exynos4412 based Odroid boards
+
+This node is intended to allow proper system reboot and power off of
+Odroid X/X2/U2/U3/U3+ boards with eMMC storage. Without this node, board
+hangs during standard reset procedure.
+
+Required properties:
+- compatible:			hardkernel,odroid-reboot
+- samsung,pmureg-phandle:	phandle to Exynos PMU node
+- reset-gpios:			phandle and gpio-specifier to the GPIO pin
(Continue reading)

Romain Perier | 29 Oct 08:35 2014
Picon

[PATCH 0/4] poweroff-source DT property renaming

The goal of this serie is to rename the property "poweroff-source" to 
"system-power-controller" and to fix things incrementally.

Changes and explanations since v1:

  - The first patch defines "of_is_system_power_controller" which is compatible
    with both "vendor,system-power-controller" and "system-power-controller"
    properties. Also, It keeps the old helper function of_system_has_poweroff_source
    for source compatibility until everything is renamed (in this way, bisections
    are not broken and change is made "atomically" between each commit)

    Note: the property "poweroff-source" itself is not used in dts files yet.
    Before this patch tps65910 was broken due to missing backward compatibility
    with "vendor,system-power-controller". As the old helper uses the new one,
    it works again.

  - act8865 and tps65910 are ported to the new helper function

  - The last commit removes the olf helper which was only used for source compatibility

Romain Perier (4):
  of: Rename "poweroff-source" property to "system-power-controller"
  regulator: act8865: Convert poweroff-source DT property to
    system-power-controller
  mfd: tps65910: Convert poweroff-source DT property to
    system-power-controller
  of: Remove of_system_has_poweroff_source helper function

 .../devicetree/bindings/power/power-controller.txt | 18 ++++++++++++
 .../devicetree/bindings/power/poweroff.txt         | 18 ------------
(Continue reading)

Yao Dongdong | 28 Oct 08:40 2014

[PATCH 1/2 resend] Thermal:Fix memory leak if occur goto unregister

Signed-off-by: Yao Dongdong <yaodongdong <at> huawei.com>
Acked-by: Eduardo Valentin <edubezval <at> gmail.com>
---
 drivers/thermal/thermal_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9bf10aa..d358605 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
 <at>  <at>  -1581,6 +1581,7  <at>  <at>  struct thermal_zone_device *thermal_zone_device_register(const char *type,
 unregister:
 	release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);
 	device_unregister(&tz->device);
+	kfree(tz);
 	return ERR_PTR(result);
 }
 EXPORT_SYMBOL_GPL(thermal_zone_device_register);
--

-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sebastian Reichel | 27 Oct 19:32 2014

Re: [PATCH v2 2/2] power: charger-manager: Avoid recursive thermal get_temp call

Hi,

On Tue, Oct 07, 2014 at 05:47:37PM +0200, Krzysztof Kozlowski wrote:
> The charger manager supports POWER_SUPPLY_PROP_TEMP property and acts
> as a thermal zone if any of these conditions match:
> 1. Fuel gauge used by charger manager supports POWER_SUPPLY_PROP_TEMP.
> 2. 'cm-thermal-zone' property is present in DTS (then it will supersede
>    the fuel gauge temperature property).
> 
> However in case 1 (fuel gauge reports temperature and 'cm-thermal-zone'
> is not set) the charger manager forwards its get_temp calls to fuel
> gauge thermal zone.
> 
> This leads to reporting by lockdep a false positive deadlock for thermal
> zone's mutex because of nested calls to thermal_zone_get_temp(). This is
> false positive because these are different mutexes: one for charger
> manager thermal zone and second for fuel gauge thermal zone.
> 
> Get rid of false lockdep alert and recursive call by setting
> 'no_thermal' property for this power supply class. The thermal zone for
> charger manager won't be created (user space does not use it anyway).

also pulled into next, will also be included in 3.18-rc pull request.

-- Sebastian
Romain Perier | 27 Oct 17:26 2014
Picon

[PATCH v1 01/10] of: Rename "poweroff-source" property to "system-power-controller"

As discussed on the mailing list, it makes more sense to rename this property
to "system-power-controller". Problem being that the word "source" usually tends
to be used for inputs and that is out of control of the OS. The poweroff
capability is an output which simply turns the system-power off. Also, this
property might be used by drivers which power-off the system and power back on
subsequent RTC alarms. This seems to suggest to remove "poweroff" from the
property name and to choose "system-power-controller" as the more generic name.
This patchs adds the required renaming changes and defines an helper function
which is compatible with both properties, the old one prefixed by a vendor name
and the new one without any prefix.

Signed-off-by: Romain Perier <romain.perier <at> gmail.com>
---
 include/linux/of.h | 27 +++++++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 27b3ba1..c1ed2a5 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
 <at>  <at>  -867,14 +867,33  <at>  <at>  static inline int of_changeset_update_property(struct of_changeset *ocs,
 extern int of_resolve_phandles(struct device_node *tree);

 /**
- * of_system_has_poweroff_source - Tells if poweroff-source is found for device_node
+ * of_is_system_power_controller - Tells if the property for controlling system
+ * power is found in device_node.
  *  <at> np: Pointer to the given device_node
  *
  * return true if present false otherwise
(Continue reading)

Toralf Förster | 27 Oct 17:14 2014
Picon
Picon

v3.18-rc2 compilation under a x86 KVM failed in drivers/thermal/thermal_core.c:

Is this an already known issue ? :

  CC      drivers/thermal/thermal_core.o
drivers/thermal/thermal_core.c: In function ‘handle_critical_trips’:
drivers/thermal/thermal_core.c:374:2: error: implicit declaration of function
‘trace_thermal_zone_trip’ [-Werror=implicit-function-declaration]
drivers/thermal/thermal_core.c: In function ‘update_temperature’:
drivers/thermal/thermal_core.c:471:2: error: implicit declaration of function
‘trace_thermal_temperature’ [-Werror=implicit-function-declaration]
drivers/thermal/thermal_core.c: In function ‘thermal_cdev_update’:
drivers/thermal/thermal_core.c:1296:2: error: implicit declaration of function
‘trace_cdev_update’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
scripts/Makefile.build:257: recipe for target 'drivers/thermal/thermal_core.o' failed
make[2]: *** [drivers/thermal/thermal_core.o] Error 1
scripts/Makefile.build:402: recipe for target 'drivers/thermal' failed
make[1]: *** [drivers/thermal] Error 2
Makefile:936: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....

--

-- 
Toralf
pgp key: 0076 E94E

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Lina Iyer | 25 Oct 01:40 2014

[PATCH v9 0/9] cpuidle driver for QCOM SoCs: 8064, 8074, 8084

Changes since v8:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11473.html ]
- Flatten out the file structure - merge pm.c into spm.c after discussions
- Add a new function to set warm boot address, in scm-boot.c
- Support for 8064 (New)
- Tested on 8074, 8084. 8064 was tested with a WIP tree
- Address review comments from v8
- Looking into possiblility of  initializing the cpuidle device for a cpu,
only when the corresponding spm device is probed successfully.

Changes since v7:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11199.html ]
- Address review comments
- Tested on 8974 but not 8084
- WFI renamed to Standby
- Update commit text with original author and link to the downstream tree

Changes since v6:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg11012.html ]
- SPM device nodes merged with existing SAW DT nodes
- SPM register information is handled within the driver
- Clean up from using 'msm' to 'qcom'
        - Shorten some enumerations as well
- Review comments from v6 addressed
- New: Support for 8084 SoC
        - Not tested. I do not have a board with this SoC, but the SPM
        configuration should be identical for WFI and SPC

Changes since v5:
[ https://www.mail-archive.com/linux-arm-msm <at> vger.kernel.org/msg10559.html ]
(Continue reading)

Lucas Stach | 24 Oct 15:05 2014
Picon

[PATCH v3] cpufreq: dt: disable unsupported OPPs

If the regulator connected to the CPU voltage plane doesn't
support an OPP specified voltage with the acceptable tolerance
it's better to just disable the OPP instead of constantly
failing the voltage scaling later on.

Includes as fix to move initialization of opp_freq outside
the loop in order to avoid an endless loop.
Signed-off-by: Geert Uytterhoeven <geert+renesas <at> glider.be>

Signed-off-by: Lucas Stach <l.stach <at> pengutronix.de>
Acked-by: Viresh Kumar <viresh.kumar <at> linaro.org>
---
v3:
- squash in fix from Geert Uytterhoeven
resend 2:
- no functional change, rebase against latest Linus tree
- added Viresh's ack
resend:
- no functional change, split out from the imx5 cpufreq series
v2:
- rebase on top of pm/linux-next
---
 drivers/cpufreq/cpufreq-dt.c | 66 +++++++++++++++++++++++++++-----------------
 1 file changed, 41 insertions(+), 25 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 92c162af5045..7789affa7eb8 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
 <at>  <at>  -187,6 +187,7  <at>  <at>  static int cpufreq_init(struct cpufreq_policy *policy)
(Continue reading)

Imre Deak | 24 Oct 09:43 2014
Picon

[PATCH] PM / Sleep: fix recovery during s2ram/hibernation

Atm, if one of the dev_pm_ops::freeze callbacks fails during the QUIESCE
phase we don't rollback things correctly calling the thaw and complete
callbacks. This could leave some devices in a suspended state in case of
an error during resuming from hibernation.

Also if an asynchronous suspend_late or freeze_late callback fails
during the SUSPEND, FREEZE or QUIESCE phases we don't propagate the
corresponding error correctly, in effect ignoring the error and
continuing the suspend-to-ram/hibernation. During suspend-to-ram this
could leave some devices without a valid saved context, leading to a
failure to reinitialize them during resume. During hibernation this
could leave some devices active interfeering with the creation /
restoration of the hibernation image. Also this could leave the
corresponding devices without a valid saved context and failure to
reinitialize them during resume.

Signed-off-by: Imre Deak <imre.deak <at> intel.com>
---
 drivers/base/power/main.c | 2 ++
 kernel/power/hibernate.c  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 4497319..9717d5f 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
 <at>  <at>  -1266,6 +1266,8  <at>  <at>  int dpm_suspend_late(pm_message_t state)
 	}
 	mutex_unlock(&dpm_list_mtx);
 	async_synchronize_full();
(Continue reading)


Gmane