[PATCH v3 00/47] kernel: Add support for power-off handler call chain

[PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means to
remove power from the system.  For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one means
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means to remove power, some of
which may be less desirable.  For example, one mechanism might power off the
entire system through an I/O port or gpio pin, while another might power off
a board by disabling its power controller. Other mechanisms may really just
execute a restart sequence or drop into the ROM monitor, or put the CPU into
sleep mode.  Using pm_power_off can also be racy if the function pointer is
set from a driver built as module, as the driver may be in the process of
being unloaded when pm_power_off is called.  If there are multiple power-off
handlers in the system, removing a module with such a handler may
inadvertently reset the pointer to pm_power_off to NULL, leaving the system
with no means to remove power.

Introduce a system power-off handler call chain to solve the described
problems.  This call chain is expected to be executed from the architecture
specific machine_power_off() function.  Drivers providing system power-off
functionality are expected to register with this call chain.  By using the
priority field in the notifier block, callers can control power-off handler
execution sequence and thus ensure that the power-off handler with the
optimal capabilities to remove power for a given system is called first.
A call chain instead of a single call to the highest priority handler is
used to provide fallback: If multiple power-off handlers are installed,
all handlers will be called until one actually succeeds to power off the
system.

Patch 01/47 implements the power-off handler API.

Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
pm_power_off to a common location.

Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
bindings descriptions.

Patch 08/47 moves the pm_power_off variable from architecture code to
kernel/reboot.c. 

Patches 09/47 to 34/47 convert various drivers to register with the kernel
power-off handler instead of setting pm_power_off directly.

Patches 35/47 to 46/47 do the same for architecture code.

Patch 47/47 finally removes pm_power_off.

For the most part, the individual patches include explanations why specific
priorities were chosen, at least if the selected priority is not the default
priority. Subsystem and architecture maintainers are encouraged to have a look
at the selected priorities and suggest improvements.

I ran the final code through my normal build and qemu tests. Results are
available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
column. I also built all available configurations for arm, mips, powerpc,
m68k, and sh architectures.

The series is available in branch poweroff-handler of my repository at
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
It is based on 3.18-rc2.

A note on Cc: In the initial submission I had way too many Cc:, causing the
patchset to be treated as spam by many mailers and mailing list handlers,
which of course defeated the purpose. This time around I am cutting down
the distribution list down significantly. My apologies to anyone I may have
failed to copy this time around.

Important changes since v2:
- Rebased series to v3.18-rc2.
- Do not hold any locks while executing the power-off call chain.
  This ensures that power-off handlers are executed in the state
  selected by the machine_power_off function for a given architecture,
  ie without changing the current semantics of power-off callbacks and
  machine_power_off functions.
  Power-off handler registration and de-registration is handled in atomic
  context with interrupts disabled to ensure that those functions are not
  interrupted by code which powers off the system.
- Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
  introduced function and variable names.
- Use power-off instead of poweroff in descriptive text and comments.
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
- Use ACPI: instead of acpi: for messages in acpi code.

Important changes since v1:
- Rebased series to v3.18-rc1.
- Use raw notifier with spinlock protection instead of atomic notifiers,
  since some power-off handlers need to have interrupts enabled.
- Renamed API functions from _poweroff to _power_off.
- Added various Acks.
- Build tested all configurations for arm, powerpc, and mips architectures.
- Fixed two compile errors in mips patch.
- Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not
  fatal.
- Provide managed resources API and use where appropriate.
- Provide and use definitions for standard priorities.
- Added patches to convert newly introduced power-off handlers.
- Various minor changes.

Important changes since RFC:
- Move API to new file kernel/power/power_off_handler.c.
- Move pm_power_off pointer to kernel/power/power_off_handler.c. Call
  pm_power_off from do_kernel_power_off, and only call do_kernel_power_off
  from architecture code instead of calling both pm_power_off and
  do_kernel_power_off.
- Provide additional API function register_power_off_handler_simple
  to simplify conversion of architecture code.
- Provide additional API function have_kernel_power_off to check if
  a power-off handler was installed.
- Convert all drivers and architecture code to use the new API.
- Remove pm_power_off as last patch of the series.

Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Alexander Graf <agraf@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Heiko Stuebner <heiko@sntech.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Romain Perier <romain.perier@gmail.com>

[PATCH v3 01/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means to
power off the system.  For the most part, those drivers set the global
variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one scheme
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means remove power, some of
which may be less desirable. For example, some mechanisms may only
power off the CPU or the CPU card, while another may power off the
entire system.  Others may really just execute a restart sequence
or drop into the ROM monitor. Using pm_power_off can also be racy
if the function pointer is set from a driver built as module, as the
driver may be in the process of being unloaded when pm_power_off is
called. If there are multiple power-off handlers in the system, removing
a module with such a handler may inadvertently reset the pointer to
pm_power_off to NULL, leaving the system with no means to remove power.

Introduce a system power-off handler call chain to solve the described
problems.  This call chain is expected to be executed from the
architecture specific machine_power_off() function.  Drivers providing
system power-off functionality are expected to register with this call chain.
By using the priority field in the notifier block, callers can control
power-off handler execution sequence and thus ensure that the power-off
handler with the optimal capabilities to remove power for a given system
is called first.

Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Alexander Graf <agraf@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Heiko Stuebner <heiko@sntech.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Philippe Rétornaz <philippe.retornaz@gmail.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v3:
- Rename new file to power_off_handler.c
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
- Execute power-off handlers without any locks held
v2:
- poweroff -> power_off
- Add defines for default priorities
- Use raw notifiers protected by spinlocks instead of atomic notifiers
- Add register_poweroff_handler_simple
- Add devm_register_power_off_handler

 include/linux/pm.h               |  22 ++++
 kernel/power/Makefile            |   1 +
 kernel/power/power_off_handler.c | 268 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 291 insertions(+)
 create mode 100644 kernel/power/power_off_handler.c

diff --git a/include/linux/pm.h b/include/linux/pm.h
index 383fd68..49b3420 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -34,7 +34,29 @@
 extern void (*pm_power_off)(void);
 extern void (*pm_power_off_prepare)(void);
 
+/*
+ * Callbacks to manage power-off handlers
+ */
+
+struct notifier_block;
 struct device; /* we have a circular dep with device.h */
+
+int register_power_off_handler(struct notifier_block *);
+int devm_register_power_off_handler(struct device *, struct notifier_block *);
+int register_power_off_handler_simple(void (*function)(void), int priority);
+int unregister_power_off_handler(struct notifier_block *);
+void do_kernel_power_off(void);
+bool have_kernel_power_off(void);
+
+/*
+ * Pre-defined power-off handler priorities
+ */
+#define POWER_OFF_PRIORITY_FALLBACK	0
+#define POWER_OFF_PRIORITY_LOW		64
+#define POWER_OFF_PRIORITY_DEFAULT	128
+#define POWER_OFF_PRIORITY_HIGH		192
+#define POWER_OFF_PRIORITY_HIGHEST	255
+
 #ifdef CONFIG_VT_CONSOLE_SLEEP
 extern void pm_vt_switch_required(struct device *dev, bool required);
 extern void pm_vt_switch_unregister(struct device *dev);
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 29472bf..567eda5 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -2,6 +2,7 @@
 ccflags-$(CONFIG_PM_DEBUG)	:= -DDEBUG
 
 obj-y				+= qos.o
+obj-y				+= power_off_handler.o
 obj-$(CONFIG_PM)		+= main.o
 obj-$(CONFIG_VT_CONSOLE_SLEEP)	+= console.o
 obj-$(CONFIG_FREEZER)		+= process.o
diff --git a/kernel/power/power_off_handler.c b/kernel/power/power_off_handler.c
new file mode 100644
index 0000000..f838e63
--- /dev/null
+++ b/kernel/power/power_off_handler.c
@@ -0,0 +1,268 @@
+/*
+ * linux/kernel/power/power_off_handler.c - Power-off handling functions
+ *
+ * Copyright (c) 2014 Guenter Roeck
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt)	"power-off: " fmt
+
+#include <linux/ctype.h>
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/kallsyms.h>
+#include <linux/notifier.h>
+#include <linux/pm.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+/*
+ *	Notifier list for kernel code which wants to be called
+ *	to power off the system.
+ */
+static RAW_NOTIFIER_HEAD(power_off_handler_list);
+static DEFINE_SPINLOCK(power_off_handler_lock);
+
+/*
+ * Internal function to register power-off notifier.
+ * Must be called with power-off spinlock acquired.
+ */
+static int _register_power_off_handler(struct notifier_block *nb)
+{
+	return raw_notifier_chain_register(&power_off_handler_list, nb);
+}
+
+/**
+ *	register_power_off_handler - Register function to be called to power off
+ *				     the system
+ *	@nb: Info about handler function to be called
+ *	@nb->priority:	Handler priority. Handlers should follow the
+ *			following guidelines for setting priorities.
+ *			0:	Power-off handler of last resort,
+ *				with limited power-off capabilities,
+ *				such as power-off handlers which
+ *				do not really power off the system
+ *				but loop forever or stop the CPU.
+ *			128:	Default power-off handler; use if no other
+ *				power-off handler is expected to be available,
+ *				and/or if power-off functionality is
+ *				sufficient to power off the entire system
+ *			255:	Highest priority power-off handler, will
+ *				preempt all other power-off handlers
+ *
+ *	Registers a function with code to be called to power off the
+ *	system.
+ *
+ *	Registered functions will be called from machine_power_off as last
+ *	step of the power-off sequence. Registered functions are expected
+ *	to power off the system immediately. If more than one function is
+ *	registered, the power-off handler priority selects which function
+ *	will be called first.
+ *
+ *	Power-off handlers may be registered from architecture code or from
+ *	drivers. A typical use case would be a system where power off
+ *	functionality is provided through a multi-function chip or through
+ *	a programmable power controller. Multiple power-off handlers may exist;
+ *	for example, one power-off handler might power off the entire system,
+ *	while another only powers off the CPU card. In such cases, the
+ *	power-off handler which only powers off part of the hardware is
+ *	expected to register with low priority to ensure that it only
+ *	runs if no other means to power off the system are available.
+ *
+ *	Always returns zero, as raw_notifier_chain_register() always
+ *	returns zero.
+ */
+int register_power_off_handler(struct notifier_block *nb)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&power_off_handler_lock, flags);
+	ret = _register_power_off_handler(nb);
+	spin_unlock_irqrestore(&power_off_handler_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL(register_power_off_handler);
+
+/**
+ *	unregister_power_off_handler - Unregister previously registered
+ *				       power-off handler
+ *	@nb: Hook to be unregistered
+ *
+ *	Unregisters a previously registered power-off handler function.
+ *
+ *	Returns zero on success, or %-ENOENT on failure.
+ */
+int unregister_power_off_handler(struct notifier_block *nb)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&power_off_handler_lock, flags);
+	ret = raw_notifier_chain_unregister(&power_off_handler_list, nb);
+	spin_unlock_irqrestore(&power_off_handler_lock, flags);
+
+	return ret;
+}
+EXPORT_SYMBOL(unregister_power_off_handler);
+
+struct _power_off_handler_data {
+	void (*handler)(void);
+	struct notifier_block power_off_nb;
+};
+
+static int _power_off_handler(struct notifier_block *this,
+			      unsigned long _unused1, void *_unused2)
+{
+	struct _power_off_handler_data *poh =
+		container_of(this, struct _power_off_handler_data,
+			     power_off_nb);
+
+	poh->handler();
+
+	return NOTIFY_DONE;
+}
+
+static struct _power_off_handler_data power_off_handler_data;
+
+/**
+ *	register_power_off_handler_simple - Register function to be called
+ *					    to power off the system
+ *	@handler:	Function to be called to power off the system
+ *	@priority:	Handler priority. For priority guidelines see
+ *			register_power_off_handler.
+ *
+ *	This is a simplified version of register_power_off_handler. It does
+ *	not take a notifier as argument, but a function pointer. The function
+ *	registers a power-off handler with specified priority. Power-off
+ *	handlers registered with this function can not be unregistered,
+ *	and only a single power-off handler can be installed using it.
+ *
+ *	This function must not be called from modules and is therefore
+ *	not exported.
+ *
+ *	Returns -EBUSY if a power-off handler has already been registered
+ *	using register_power_off_handler_simple. Otherwise returns zero,
+ *	since raw_notifier_chain_register() currently always returns zero.
+ */
+int register_power_off_handler_simple(void (*handler)(void), int priority)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&power_off_handler_lock, flags);
+
+	if (power_off_handler_data.handler) {
+		pr_warn("Power-off function already registered (%ps), cannot register %ps",
+			power_off_handler_data.handler, handler);
+		ret = -EBUSY;
+		goto abort;
+	}
+
+	power_off_handler_data.handler = handler;
+	power_off_handler_data.power_off_nb.notifier_call = _power_off_handler;
+	power_off_handler_data.power_off_nb.priority = priority;
+
+	ret = _register_power_off_handler(&power_off_handler_data.power_off_nb);
+abort:
+	spin_unlock_irqrestore(&power_off_handler_lock, flags);
+	return ret;
+}
+
+/* Device managed power-off handler registration */
+
+static void devm_power_off_release(struct device *dev, void *res)
+{
+	struct notifier_block *nb = *(struct notifier_block **)res;
+
+	unregister_power_off_handler(nb);
+}
+
+/**
+ *	devm_register_power_off_handler - Register function to be called
+ *					  to power off the system
+ *	@dev:		The device registering the power-off handler.
+ *	@handler:	Function to be called to power off the system
+ *	@priority:	Handler priority. For priority guidelines see
+ *			register_power_off_handler.
+ *
+ *	This is the device managed version of register_power_off_handler.
+ *
+ *	Returns -EINVAL if dev is NULL. Returns -ENOMEM if the system is out
+ *	of memory. Otherwise returns zero, since raw_notifier_chain_register()
+ *	currently always returns zero.
+ */
+int devm_register_power_off_handler(struct device *dev,
+				    struct notifier_block *nb)
+{
+	struct notifier_block **ptr;
+	unsigned long flags;
+	int ret;
+
+	if (!dev)
+		return -EINVAL;
+
+	ptr = devres_alloc(devm_power_off_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return -ENOMEM;
+
+	spin_lock_irqsave(&power_off_handler_lock, flags);
+	ret = _register_power_off_handler(nb);
+	spin_unlock_irqrestore(&power_off_handler_lock, flags);
+	if (ret)
+		goto error;
+
+	*ptr = nb;
+	devres_add(dev, ptr);
+	return 0;
+error:
+	devres_free(ptr);
+	return ret;
+}
+EXPORT_SYMBOL(devm_register_power_off_handler);
+
+/**
+ *	do_kernel_power_off - Execute kernel power-off handler call chain
+ *
+ *	Calls functions registered with register_power_off_handler.
+ *
+ *	Expected to be called from machine_power_off as last step of
+ *	the power-off sequence.
+ *
+ *	Powers the system off immediately if a power-off handler function
+ *	has been registered. Otherwise does nothing.
+ */
+void do_kernel_power_off(void)
+{
+	/*
+	 * No locking. This code can be called from both atomic and non-atomic
+	 * context, with interrupts enabled or disabled, depending on the
+	 * architecture and platform.
+	 *
+	 * Power-off handler registration and de-registration are executed in
+	 * atomic context with interrupts disabled, which guarantees that
+	 * do_kernel_power_off() will not be called while a power-off handler
+	 * is installed or removed.
+	 * There is a theoretic risc that a power-off handler is installed or
+	 * removed while the call chain is traversed, but we'll have to carry
+	 * that risk.
+	 */
+	raw_notifier_call_chain(&power_off_handler_list, 0, NULL);
+}
+
+/**
+ * have_kernel_power_off() - Check if kernel power-off handler is available
+ *
+ * Returns true is a kernel power-off handler is available, false otherwise.
+ */
+bool have_kernel_power_off(void)
+{
+	return pm_power_off != NULL || power_off_handler_list.head != NULL;
+}
+EXPORT_SYMBOL(have_kernel_power_off);
-- 
1.9.1

[PATCH v3 02/47] memory: emif: Use API function to determine power-off capability

[Guenter Roeck]

Use have_kernel_power_off() to determine if the kernel is able
to power off the system.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v3:
- Replace poweroff in all newly introduced variables and in text
  with power_off or power-off as appropriate
v2:
- poweroff -> power_off

 drivers/memory/emif.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 04644e7..317d49f 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1053,10 +1053,10 @@ static irqreturn_t emif_threaded_isr(int irq, void *dev_id)
 		dev_emerg(emif->dev, "SDRAM temperature exceeds operating limit.. Needs shut down!!!\n");
 
 		/* If we have Power OFF ability, use it, else try restarting */
-		if (pm_power_off) {
+		if (have_kernel_power_off()) {
 			kernel_power_off();
 		} else {
-			WARN(1, "FIXME: NO pm_power_off!!! trying restart\n");
+			WARN(1, "FIXME: NO kernel power-off capability!!! trying restart\n");
 			kernel_restart("SDRAM Over-temp Emergency restart");
 		}
 		return IRQ_HANDLED;
-- 
1.9.1

[PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means to
remove power from the system.  For the most part, those drivers set the
global variable pm_power_off to point to a function within the driver.

This mechanism has a number of drawbacks.  Typically only one means
to remove power is supported (at least if pm_power_off is used).
At least in theory there can be multiple means to remove power, some of
which may be less desirable.  For example, one mechanism might power off the
entire system through an I/O port or gpio pin, while another might power off
a board by disabling its power controller. Other mechanisms may really just
execute a restart sequence or drop into the ROM monitor, or put the CPU into
sleep mode.  Using pm_power_off can also be racy if the function pointer is
set from a driver built as module, as the driver may be in the process of
being unloaded when pm_power_off is called.  If there are multiple power-off
handlers in the system, removing a module with such a handler may
inadvertently reset the pointer to pm_power_off to NULL, leaving the system
with no means to remove power.

Introduce a system power-off handler call chain to solve the described
problems.  This call chain is expected to be executed from the architecture
specific machine_power_off() function.  Drivers providing system power-off
functionality are expected to register with this call chain.  By using the
priority field in the notifier block, callers can control power-off handler
execution sequence and thus ensure that the power-off handler with the
optimal capabilities to remove power for a given system is called first.
A call chain instead of a single call to the highest priority handler is
used to provide fallback: If multiple power-off handlers are installed,
all handlers will be called until one actually succeeds to power off the
system.

Patch 01/47 implements the power-off handler API.

Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
pm_power_off to a common location.

Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
bindings descriptions.

Patch 08/47 moves the pm_power_off variable from architecture code to
kernel/reboot.c. 

Patches 09/47 to 34/47 convert various drivers to register with the kernel
power-off handler instead of setting pm_power_off directly.

Patches 35/47 to 46/47 do the same for architecture code.

Patch 47/47 finally removes pm_power_off.

For the most part, the individual patches include explanations why specific
priorities were chosen, at least if the selected priority is not the default
priority. Subsystem and architecture maintainers are encouraged to have a look
at the selected priorities and suggest improvements.

I ran the final code through my normal build and qemu tests. Results are
available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
column. I also built all available configurations for arm, mips, powerpc,
m68k, and sh architectures.

The series is available in branch poweroff-handler of my repository at
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
It is based on 3.18-rc2.

A note on Cc: In the initial submission I had way too many Cc:, causing the
patchset to be treated as spam by many mailers and mailing list handlers,
which of course defeated the purpose. This time around I am cutting down
the distribution list down significantly. My apologies to anyone I may have
failed to copy this time around.

Important changes since v2:
- Rebased series to v3.18-rc2.
- Do not hold any locks while executing the power-off call chain.
  This ensures that power-off handlers are executed in the state
  selected by the machine_power_off function for a given architecture,
  ie without changing the current semantics of power-off callbacks and
  machine_power_off functions.
  Power-off handler registration and de-registration is handled in atomic
  context with interrupts disabled to ensure that those functions are not
  interrupted by code which powers off the system.
- Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
  introduced function and variable names.
- Use power-off instead of poweroff in descriptive text and comments.
- Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
- Use ACPI: instead of acpi: for messages in acpi code.

Important changes since v1:
- Rebased series to v3.18-rc1.
- Use raw notifier with spinlock protection instead of atomic notifiers,
  since some power-off handlers need to have interrupts enabled.
- Renamed API functions from _poweroff to _power_off.
- Added various Acks.
- Build tested all configurations for arm, powerpc, and mips architectures.
- Fixed two compile errors in mips patch.
- Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not
  fatal.
- Provide managed resources API and use where appropriate.
- Provide and use definitions for standard priorities.
- Added patches to convert newly introduced power-off handlers.
- Various minor changes.

Important changes since RFC:
- Move API to new file kernel/power/power_off_handler.c.
- Move pm_power_off pointer to kernel/power/power_off_handler.c. Call
  pm_power_off from do_kernel_power_off, and only call do_kernel_power_off
  from architecture code instead of calling both pm_power_off and
  do_kernel_power_off.
- Provide additional API function register_power_off_handler_simple
  to simplify conversion of architecture code.
- Provide additional API function have_kernel_power_off to check if
  a power-off handler was installed.
- Convert all drivers and architecture code to use the new API.
- Remove pm_power_off as last patch of the series.

Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Alexander Graf <agraf@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Heiko Stuebner <heiko@sntech.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Romain Perier <romain.perier@gmail.com>

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 6861 bytes --]

Adding Johan, who's working on RTC power off for AM335x devices

On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> Various drivers implement architecture and/or device specific means to
> remove power from the system.  For the most part, those drivers set the
> global variable pm_power_off to point to a function within the driver.
> 
> This mechanism has a number of drawbacks.  Typically only one means
> to remove power is supported (at least if pm_power_off is used).
> At least in theory there can be multiple means to remove power, some of
> which may be less desirable.  For example, one mechanism might power off the
> entire system through an I/O port or gpio pin, while another might power off
> a board by disabling its power controller. Other mechanisms may really just
> execute a restart sequence or drop into the ROM monitor, or put the CPU into
> sleep mode.  Using pm_power_off can also be racy if the function pointer is
> set from a driver built as module, as the driver may be in the process of
> being unloaded when pm_power_off is called.  If there are multiple power-off
> handlers in the system, removing a module with such a handler may
> inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> with no means to remove power.
> 
> Introduce a system power-off handler call chain to solve the described
> problems.  This call chain is expected to be executed from the architecture
> specific machine_power_off() function.  Drivers providing system power-off
> functionality are expected to register with this call chain.  By using the
> priority field in the notifier block, callers can control power-off handler
> execution sequence and thus ensure that the power-off handler with the
> optimal capabilities to remove power for a given system is called first.
> A call chain instead of a single call to the highest priority handler is
> used to provide fallback: If multiple power-off handlers are installed,
> all handlers will be called until one actually succeeds to power off the
> system.
> 
> Patch 01/47 implements the power-off handler API.
> 
> Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> pm_power_off to a common location.
> 
> Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> bindings descriptions.
> 
> Patch 08/47 moves the pm_power_off variable from architecture code to
> kernel/reboot.c. 
> 
> Patches 09/47 to 34/47 convert various drivers to register with the kernel
> power-off handler instead of setting pm_power_off directly.
> 
> Patches 35/47 to 46/47 do the same for architecture code.
> 
> Patch 47/47 finally removes pm_power_off.
> 
> For the most part, the individual patches include explanations why specific
> priorities were chosen, at least if the selected priority is not the default
> priority. Subsystem and architecture maintainers are encouraged to have a look
> at the selected priorities and suggest improvements.
> 
> I ran the final code through my normal build and qemu tests. Results are
> available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> column. I also built all available configurations for arm, mips, powerpc,
> m68k, and sh architectures.
> 
> The series is available in branch poweroff-handler of my repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> It is based on 3.18-rc2.
> 
> A note on Cc: In the initial submission I had way too many Cc:, causing the
> patchset to be treated as spam by many mailers and mailing list handlers,
> which of course defeated the purpose. This time around I am cutting down
> the distribution list down significantly. My apologies to anyone I may have
> failed to copy this time around.
> 
> Important changes since v2:
> - Rebased series to v3.18-rc2.
> - Do not hold any locks while executing the power-off call chain.
>   This ensures that power-off handlers are executed in the state
>   selected by the machine_power_off function for a given architecture,
>   ie without changing the current semantics of power-off callbacks and
>   machine_power_off functions.
>   Power-off handler registration and de-registration is handled in atomic
>   context with interrupts disabled to ensure that those functions are not
>   interrupted by code which powers off the system.
> - Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
>   introduced function and variable names.
> - Use power-off instead of poweroff in descriptive text and comments.
> - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
> - Use ACPI: instead of acpi: for messages in acpi code.
> 
> Important changes since v1:
> - Rebased series to v3.18-rc1.
> - Use raw notifier with spinlock protection instead of atomic notifiers,
>   since some power-off handlers need to have interrupts enabled.
> - Renamed API functions from _poweroff to _power_off.
> - Added various Acks.
> - Build tested all configurations for arm, powerpc, and mips architectures.
> - Fixed two compile errors in mips patch.
> - Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not
>   fatal.
> - Provide managed resources API and use where appropriate.
> - Provide and use definitions for standard priorities.
> - Added patches to convert newly introduced power-off handlers.
> - Various minor changes.
> 
> Important changes since RFC:
> - Move API to new file kernel/power/power_off_handler.c.
> - Move pm_power_off pointer to kernel/power/power_off_handler.c. Call
>   pm_power_off from do_kernel_power_off, and only call do_kernel_power_off
>   from architecture code instead of calling both pm_power_off and
>   do_kernel_power_off.
> - Provide additional API function register_power_off_handler_simple
>   to simplify conversion of architecture code.
> - Provide additional API function have_kernel_power_off to check if
>   a power-off handler was installed.
> - Convert all drivers and architecture code to use the new API.
> - Remove pm_power_off as last patch of the series.
> 
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Romain Perier <romain.perier@gmail.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

On Mon, Oct 27, 2014 at 11:03:24AM -0500, Felipe Balbi wrote:
> Adding Johan, who's working on RTC power off for AM335x devices
> 
Hi Felipe,

is that the rtc-omap driver ?

I am tracking linux-next for related changes. As new power-off handlers are
introduced, I prepare patches for those as well. I currently have patches for
the following two drivers in the queue:
	drivers/regulator/act8865-regulator.c
	drivers/rtc/rtc-omap.c

I plan to send review requests for those patches in a week or so (I think
there is still some change pending to the power-off function in the rtc-omap
driver, and I want to wait for it).

My current plan is to send a pull request for the series directly to Linus
when the next commit window opens; this is what a number of maintainers
suggested I should do. This pull request would exclude the last patch,
so pm_power_off would still be there. Next steps would then be to submit
another set of patches to update the newly introduced power-off handlers
and then to finally remove pm_power_off; this would probably happen after
the commit window closes.

At least that is the plan unless someone has a better idea ....

There may be some variants; for example, it might make sense to create an
immutable branch with the key patches (1-3 and 8) to enable others to use
the new functions immediately. That would require Acks from affected
maintainers for patch 1, though, so I can not do that yet.

Thanks,
Guenter

> On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> > Various drivers implement architecture and/or device specific means to
> > remove power from the system.  For the most part, those drivers set the
> > global variable pm_power_off to point to a function within the driver.
> > 
> > This mechanism has a number of drawbacks.  Typically only one means
> > to remove power is supported (at least if pm_power_off is used).
> > At least in theory there can be multiple means to remove power, some of
> > which may be less desirable.  For example, one mechanism might power off the
> > entire system through an I/O port or gpio pin, while another might power off
> > a board by disabling its power controller. Other mechanisms may really just
> > execute a restart sequence or drop into the ROM monitor, or put the CPU into
> > sleep mode.  Using pm_power_off can also be racy if the function pointer is
> > set from a driver built as module, as the driver may be in the process of
> > being unloaded when pm_power_off is called.  If there are multiple power-off
> > handlers in the system, removing a module with such a handler may
> > inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> > with no means to remove power.
> > 
> > Introduce a system power-off handler call chain to solve the described
> > problems.  This call chain is expected to be executed from the architecture
> > specific machine_power_off() function.  Drivers providing system power-off
> > functionality are expected to register with this call chain.  By using the
> > priority field in the notifier block, callers can control power-off handler
> > execution sequence and thus ensure that the power-off handler with the
> > optimal capabilities to remove power for a given system is called first.
> > A call chain instead of a single call to the highest priority handler is
> > used to provide fallback: If multiple power-off handlers are installed,
> > all handlers will be called until one actually succeeds to power off the
> > system.
> > 
> > Patch 01/47 implements the power-off handler API.
> > 
> > Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> > pm_power_off to a common location.
> > 
> > Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> > bindings descriptions.
> > 
> > Patch 08/47 moves the pm_power_off variable from architecture code to
> > kernel/reboot.c. 
> > 
> > Patches 09/47 to 34/47 convert various drivers to register with the kernel
> > power-off handler instead of setting pm_power_off directly.
> > 
> > Patches 35/47 to 46/47 do the same for architecture code.
> > 
> > Patch 47/47 finally removes pm_power_off.
> > 
> > For the most part, the individual patches include explanations why specific
> > priorities were chosen, at least if the selected priority is not the default
> > priority. Subsystem and architecture maintainers are encouraged to have a look
> > at the selected priorities and suggest improvements.
> > 
> > I ran the final code through my normal build and qemu tests. Results are
> > available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> > column. I also built all available configurations for arm, mips, powerpc,
> > m68k, and sh architectures.
> > 
> > The series is available in branch poweroff-handler of my repository at
> > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> > It is based on 3.18-rc2.
> > 
> > A note on Cc: In the initial submission I had way too many Cc:, causing the
> > patchset to be treated as spam by many mailers and mailing list handlers,
> > which of course defeated the purpose. This time around I am cutting down
> > the distribution list down significantly. My apologies to anyone I may have
> > failed to copy this time around.
> > 
> > Important changes since v2:
> > - Rebased series to v3.18-rc2.
> > - Do not hold any locks while executing the power-off call chain.
> >   This ensures that power-off handlers are executed in the state
> >   selected by the machine_power_off function for a given architecture,
> >   ie without changing the current semantics of power-off callbacks and
> >   machine_power_off functions.
> >   Power-off handler registration and de-registration is handled in atomic
> >   context with interrupts disabled to ensure that those functions are not
> >   interrupted by code which powers off the system.
> > - Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
> >   introduced function and variable names.
> > - Use power-off instead of poweroff in descriptive text and comments.
> > - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
> > - Use ACPI: instead of acpi: for messages in acpi code.
> > 
> > Important changes since v1:
> > - Rebased series to v3.18-rc1.
> > - Use raw notifier with spinlock protection instead of atomic notifiers,
> >   since some power-off handlers need to have interrupts enabled.
> > - Renamed API functions from _poweroff to _power_off.
> > - Added various Acks.
> > - Build tested all configurations for arm, powerpc, and mips architectures.
> > - Fixed two compile errors in mips patch.
> > - Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not
> >   fatal.
> > - Provide managed resources API and use where appropriate.
> > - Provide and use definitions for standard priorities.
> > - Added patches to convert newly introduced power-off handlers.
> > - Various minor changes.
> > 
> > Important changes since RFC:
> > - Move API to new file kernel/power/power_off_handler.c.
> > - Move pm_power_off pointer to kernel/power/power_off_handler.c. Call
> >   pm_power_off from do_kernel_power_off, and only call do_kernel_power_off
> >   from architecture code instead of calling both pm_power_off and
> >   do_kernel_power_off.
> > - Provide additional API function register_power_off_handler_simple
> >   to simplify conversion of architecture code.
> > - Provide additional API function have_kernel_power_off to check if
> >   a power-off handler was installed.
> > - Convert all drivers and architecture code to use the new API.
> > - Remove pm_power_off as last patch of the series.
> > 
> > Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> > Cc: Alexander Graf <agraf@suse.de>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > cc: Heiko Stuebner <heiko@sntech.de>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Len Brown <len.brown@intel.com>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> > Cc: Romain Perier <romain.perier@gmail.com>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> balbi

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Mon, Oct 27, 2014 at 10:16:17AM -0700, Guenter Roeck wrote:
> On Mon, Oct 27, 2014 at 11:03:24AM -0500, Felipe Balbi wrote:
> > Adding Johan, who's working on RTC power off for AM335x devices
> > 
> Hi Felipe,
> 
> is that the rtc-omap driver ?

yes it is.

> I am tracking linux-next for related changes. As new power-off handlers are
> introduced, I prepare patches for those as well. I currently have patches for
> the following two drivers in the queue:
> 	drivers/regulator/act8865-regulator.c
> 	drivers/rtc/rtc-omap.c
> 
> I plan to send review requests for those patches in a week or so (I think
> there is still some change pending to the power-off function in the rtc-omap
> driver, and I want to wait for it).

yeah, Johan's working on that.

> My current plan is to send a pull request for the series directly to Linus
> when the next commit window opens; this is what a number of maintainers
> suggested I should do. This pull request would exclude the last patch,
> so pm_power_off would still be there. Next steps would then be to submit
> another set of patches to update the newly introduced power-off handlers
> and then to finally remove pm_power_off; this would probably happen after
> the commit window closes.
> 
> At least that is the plan unless someone has a better idea ....

sounds like a good idea to me :-)

> There may be some variants; for example, it might make sense to create an
> immutable branch with the key patches (1-3 and 8) to enable others to use
> the new functions immediately. That would require Acks from affected
> maintainers for patch 1, though, so I can not do that yet.

alright, I think an immutable branch people can merge would be
appreciated nevertheless, but I'd certainly defer that to arch and soc
maintainers.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Johan Hovold]

On Mon, Oct 27, 2014 at 12:33:10PM -0500, Felipe Balbi wrote:
> On Mon, Oct 27, 2014 at 10:16:17AM -0700, Guenter Roeck wrote:
> > On Mon, Oct 27, 2014 at 11:03:24AM -0500, Felipe Balbi wrote:
> > > Adding Johan, who's working on RTC power off for AM335x devices
> > > 
> > Hi Felipe,
> > 
> > is that the rtc-omap driver ?
> 
> yes it is.
> 
> > I am tracking linux-next for related changes. As new power-off handlers are
> > introduced, I prepare patches for those as well. I currently have patches for
> > the following two drivers in the queue:
> > 	drivers/regulator/act8865-regulator.c
> > 	drivers/rtc/rtc-omap.c
> > 
> > I plan to send review requests for those patches in a week or so (I think
> > there is still some change pending to the power-off function in the rtc-omap
> > driver, and I want to wait for it).
> 
> yeah, Johan's working on that.

It's finished. I just sent the final version to akpm this morning
(adding a single mdelay), so you should be fine basing any conversion on
either v2 (in mmotm) or v3.

Johan

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 7066 bytes --]

Hi,

On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> Various drivers implement architecture and/or device specific means to
> remove power from the system.  For the most part, those drivers set the
> global variable pm_power_off to point to a function within the driver.
> 
> This mechanism has a number of drawbacks.  Typically only one means
> to remove power is supported (at least if pm_power_off is used).
> At least in theory there can be multiple means to remove power, some of
> which may be less desirable.  For example, one mechanism might power off the
> entire system through an I/O port or gpio pin, while another might power off
> a board by disabling its power controller. Other mechanisms may really just
> execute a restart sequence or drop into the ROM monitor, or put the CPU into
> sleep mode.  Using pm_power_off can also be racy if the function pointer is
> set from a driver built as module, as the driver may be in the process of
> being unloaded when pm_power_off is called.  If there are multiple power-off
> handlers in the system, removing a module with such a handler may
> inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> with no means to remove power.
> 
> Introduce a system power-off handler call chain to solve the described
> problems.  This call chain is expected to be executed from the architecture
> specific machine_power_off() function.  Drivers providing system power-off
> functionality are expected to register with this call chain.  By using the
> priority field in the notifier block, callers can control power-off handler
> execution sequence and thus ensure that the power-off handler with the
> optimal capabilities to remove power for a given system is called first.
> A call chain instead of a single call to the highest priority handler is
> used to provide fallback: If multiple power-off handlers are installed,
> all handlers will be called until one actually succeeds to power off the
> system.
> 
> Patch 01/47 implements the power-off handler API.
> 
> Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> pm_power_off to a common location.
> 
> Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> bindings descriptions.
> 
> Patch 08/47 moves the pm_power_off variable from architecture code to
> kernel/reboot.c. 
> 
> Patches 09/47 to 34/47 convert various drivers to register with the kernel
> power-off handler instead of setting pm_power_off directly.
> 
> Patches 35/47 to 46/47 do the same for architecture code.
> 
> Patch 47/47 finally removes pm_power_off.
> 
> For the most part, the individual patches include explanations why specific
> priorities were chosen, at least if the selected priority is not the default
> priority. Subsystem and architecture maintainers are encouraged to have a look
> at the selected priorities and suggest improvements.
> 
> I ran the final code through my normal build and qemu tests. Results are
> available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> column. I also built all available configurations for arm, mips, powerpc,
> m68k, and sh architectures.
> 
> The series is available in branch poweroff-handler of my repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> It is based on 3.18-rc2.
> 
> A note on Cc: In the initial submission I had way too many Cc:, causing the
> patchset to be treated as spam by many mailers and mailing list handlers,
> which of course defeated the purpose. This time around I am cutting down
> the distribution list down significantly. My apologies to anyone I may have
> failed to copy this time around.

you touch every single architecture with this patchset, but you didn't
care about Ccing any of the arch-specific mailing lists, like lakml ?

Please resend with proper people in Cc, IIRC RMK had a few very
important comments about the idea behind this series.

> Important changes since v2:
> - Rebased series to v3.18-rc2.
> - Do not hold any locks while executing the power-off call chain.
>   This ensures that power-off handlers are executed in the state
>   selected by the machine_power_off function for a given architecture,
>   ie without changing the current semantics of power-off callbacks and
>   machine_power_off functions.
>   Power-off handler registration and de-registration is handled in atomic
>   context with interrupts disabled to ensure that those functions are not
>   interrupted by code which powers off the system.
> - Use [xxx_]power_off[_xxx] instead of [xxx_]poweroff[_xxx] for newly
>   introduced function and variable names.
> - Use power-off instead of poweroff in descriptive text and comments.
> - Replace POWEROFF_PRIORITY_xxx with POWER_OFF_PRIORITY_xxx
> - Use ACPI: instead of acpi: for messages in acpi code.
> 
> Important changes since v1:
> - Rebased series to v3.18-rc1.
> - Use raw notifier with spinlock protection instead of atomic notifiers,
>   since some power-off handlers need to have interrupts enabled.
> - Renamed API functions from _poweroff to _power_off.
> - Added various Acks.
> - Build tested all configurations for arm, powerpc, and mips architectures.
> - Fixed two compile errors in mips patch.
> - Replaced dev_err and pr_err with dev_warn and pr_warn if an error is not
>   fatal.
> - Provide managed resources API and use where appropriate.
> - Provide and use definitions for standard priorities.
> - Added patches to convert newly introduced power-off handlers.
> - Various minor changes.
> 
> Important changes since RFC:
> - Move API to new file kernel/power/power_off_handler.c.
> - Move pm_power_off pointer to kernel/power/power_off_handler.c. Call
>   pm_power_off from do_kernel_power_off, and only call do_kernel_power_off
>   from architecture code instead of calling both pm_power_off and
>   do_kernel_power_off.
> - Provide additional API function register_power_off_handler_simple
>   to simplify conversion of architecture code.
> - Provide additional API function have_kernel_power_off to check if
>   a power-off handler was installed.
> - Convert all drivers and architecture code to use the new API.
> - Remove pm_power_off as last patch of the series.
> 
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Romain Perier <romain.perier@gmail.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> > Various drivers implement architecture and/or device specific means to
> > remove power from the system.  For the most part, those drivers set the
> > global variable pm_power_off to point to a function within the driver.
> > 
> > This mechanism has a number of drawbacks.  Typically only one means
> > to remove power is supported (at least if pm_power_off is used).
> > At least in theory there can be multiple means to remove power, some of
> > which may be less desirable.  For example, one mechanism might power off the
> > entire system through an I/O port or gpio pin, while another might power off
> > a board by disabling its power controller. Other mechanisms may really just
> > execute a restart sequence or drop into the ROM monitor, or put the CPU into
> > sleep mode.  Using pm_power_off can also be racy if the function pointer is
> > set from a driver built as module, as the driver may be in the process of
> > being unloaded when pm_power_off is called.  If there are multiple power-off
> > handlers in the system, removing a module with such a handler may
> > inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> > with no means to remove power.
> > 
> > Introduce a system power-off handler call chain to solve the described
> > problems.  This call chain is expected to be executed from the architecture
> > specific machine_power_off() function.  Drivers providing system power-off
> > functionality are expected to register with this call chain.  By using the
> > priority field in the notifier block, callers can control power-off handler
> > execution sequence and thus ensure that the power-off handler with the
> > optimal capabilities to remove power for a given system is called first.
> > A call chain instead of a single call to the highest priority handler is
> > used to provide fallback: If multiple power-off handlers are installed,
> > all handlers will be called until one actually succeeds to power off the
> > system.
> > 
> > Patch 01/47 implements the power-off handler API.
> > 
> > Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> > pm_power_off to a common location.
> > 
> > Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> > bindings descriptions.
> > 
> > Patch 08/47 moves the pm_power_off variable from architecture code to
> > kernel/reboot.c. 
> > 
> > Patches 09/47 to 34/47 convert various drivers to register with the kernel
> > power-off handler instead of setting pm_power_off directly.
> > 
> > Patches 35/47 to 46/47 do the same for architecture code.
> > 
> > Patch 47/47 finally removes pm_power_off.
> > 
> > For the most part, the individual patches include explanations why specific
> > priorities were chosen, at least if the selected priority is not the default
> > priority. Subsystem and architecture maintainers are encouraged to have a look
> > at the selected priorities and suggest improvements.
> > 
> > I ran the final code through my normal build and qemu tests. Results are
> > available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> > column. I also built all available configurations for arm, mips, powerpc,
> > m68k, and sh architectures.
> > 
> > The series is available in branch poweroff-handler of my repository at
> > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> > It is based on 3.18-rc2.
> > 
> > A note on Cc: In the initial submission I had way too many Cc:, causing the
> > patchset to be treated as spam by many mailers and mailing list handlers,
> > which of course defeated the purpose. This time around I am cutting down
> > the distribution list down significantly. My apologies to anyone I may have
> > failed to copy this time around.
> 
> you touch every single architecture with this patchset, but you didn't
> care about Ccing any of the arch-specific mailing lists, like lakml ?
> 
What is lakml ? linux-kernel@vger.kernel.org was copied, if that is what you
refer to. I don't find a reference to lakml anywhere, sorry. I'll be happy to
add it manually if you provide the address.

Architecture specific mailing lists were copied on individual patches as long
as those mailing lists are reported by the MAINTAINERS file.

> Please resend with proper people in Cc, IIRC RMK had a few very
> important comments about the idea behind this series.
> 
Felipe,

That doesn't work. I tried with rev 1. The result was that the patch series
was flagged as spam and got dropped by most mailing lists, as explained above,
and I got tagged as spammer by Google and several other mail servers,
preventing me from posting _anything_ for several days.

Please point me to the comments you refer to above in case I missed them.

Thanks,
Guenter

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 5272 bytes --]

Hi,

On Mon, Nov 03, 2014 at 10:22:13AM -0800, Guenter Roeck wrote:
> On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> > > Various drivers implement architecture and/or device specific means to
> > > remove power from the system.  For the most part, those drivers set the
> > > global variable pm_power_off to point to a function within the driver.
> > > 
> > > This mechanism has a number of drawbacks.  Typically only one means
> > > to remove power is supported (at least if pm_power_off is used).
> > > At least in theory there can be multiple means to remove power, some of
> > > which may be less desirable.  For example, one mechanism might power off the
> > > entire system through an I/O port or gpio pin, while another might power off
> > > a board by disabling its power controller. Other mechanisms may really just
> > > execute a restart sequence or drop into the ROM monitor, or put the CPU into
> > > sleep mode.  Using pm_power_off can also be racy if the function pointer is
> > > set from a driver built as module, as the driver may be in the process of
> > > being unloaded when pm_power_off is called.  If there are multiple power-off
> > > handlers in the system, removing a module with such a handler may
> > > inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> > > with no means to remove power.
> > > 
> > > Introduce a system power-off handler call chain to solve the described
> > > problems.  This call chain is expected to be executed from the architecture
> > > specific machine_power_off() function.  Drivers providing system power-off
> > > functionality are expected to register with this call chain.  By using the
> > > priority field in the notifier block, callers can control power-off handler
> > > execution sequence and thus ensure that the power-off handler with the
> > > optimal capabilities to remove power for a given system is called first.
> > > A call chain instead of a single call to the highest priority handler is
> > > used to provide fallback: If multiple power-off handlers are installed,
> > > all handlers will be called until one actually succeeds to power off the
> > > system.
> > > 
> > > Patch 01/47 implements the power-off handler API.
> > > 
> > > Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> > > pm_power_off to a common location.
> > > 
> > > Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> > > bindings descriptions.
> > > 
> > > Patch 08/47 moves the pm_power_off variable from architecture code to
> > > kernel/reboot.c. 
> > > 
> > > Patches 09/47 to 34/47 convert various drivers to register with the kernel
> > > power-off handler instead of setting pm_power_off directly.
> > > 
> > > Patches 35/47 to 46/47 do the same for architecture code.
> > > 
> > > Patch 47/47 finally removes pm_power_off.
> > > 
> > > For the most part, the individual patches include explanations why specific
> > > priorities were chosen, at least if the selected priority is not the default
> > > priority. Subsystem and architecture maintainers are encouraged to have a look
> > > at the selected priorities and suggest improvements.
> > > 
> > > I ran the final code through my normal build and qemu tests. Results are
> > > available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> > > column. I also built all available configurations for arm, mips, powerpc,
> > > m68k, and sh architectures.
> > > 
> > > The series is available in branch poweroff-handler of my repository at
> > > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> > > It is based on 3.18-rc2.
> > > 
> > > A note on Cc: In the initial submission I had way too many Cc:, causing the
> > > patchset to be treated as spam by many mailers and mailing list handlers,
> > > which of course defeated the purpose. This time around I am cutting down
> > > the distribution list down significantly. My apologies to anyone I may have
> > > failed to copy this time around.
> > 
> > you touch every single architecture with this patchset, but you didn't
> > care about Ccing any of the arch-specific mailing lists, like lakml ?
> > 
> What is lakml ? linux-kernel@vger.kernel.org was copied, if that is what you

only the greatest mailing list of all time.

heh, Linux ARM Kernel Mailing List.

> refer to. I don't find a reference to lakml anywhere, sorry. I'll be happy to
> add it manually if you provide the address.
> 
> Architecture specific mailing lists were copied on individual patches as long
> as those mailing lists are reported by the MAINTAINERS file.
> 
> > Please resend with proper people in Cc, IIRC RMK had a few very
> > important comments about the idea behind this series.
> > 
> Felipe,
> 
> That doesn't work. I tried with rev 1. The result was that the patch series
> was flagged as spam and got dropped by most mailing lists, as explained above,
> and I got tagged as spammer by Google and several other mail servers,
> preventing me from posting _anything_ for several days.

heh, that sucks.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain

[Guenter Roeck]

On Mon, Nov 03, 2014 at 12:28:29PM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Nov 03, 2014 at 10:22:13AM -0800, Guenter Roeck wrote:
> > On Mon, Nov 03, 2014 at 11:59:35AM -0600, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Mon, Oct 27, 2014 at 08:55:07AM -0700, Guenter Roeck wrote:
> > > > Various drivers implement architecture and/or device specific means to
> > > > remove power from the system.  For the most part, those drivers set the
> > > > global variable pm_power_off to point to a function within the driver.
> > > > 
> > > > This mechanism has a number of drawbacks.  Typically only one means
> > > > to remove power is supported (at least if pm_power_off is used).
> > > > At least in theory there can be multiple means to remove power, some of
> > > > which may be less desirable.  For example, one mechanism might power off the
> > > > entire system through an I/O port or gpio pin, while another might power off
> > > > a board by disabling its power controller. Other mechanisms may really just
> > > > execute a restart sequence or drop into the ROM monitor, or put the CPU into
> > > > sleep mode.  Using pm_power_off can also be racy if the function pointer is
> > > > set from a driver built as module, as the driver may be in the process of
> > > > being unloaded when pm_power_off is called.  If there are multiple power-off
> > > > handlers in the system, removing a module with such a handler may
> > > > inadvertently reset the pointer to pm_power_off to NULL, leaving the system
> > > > with no means to remove power.
> > > > 
> > > > Introduce a system power-off handler call chain to solve the described
> > > > problems.  This call chain is expected to be executed from the architecture
> > > > specific machine_power_off() function.  Drivers providing system power-off
> > > > functionality are expected to register with this call chain.  By using the
> > > > priority field in the notifier block, callers can control power-off handler
> > > > execution sequence and thus ensure that the power-off handler with the
> > > > optimal capabilities to remove power for a given system is called first.
> > > > A call chain instead of a single call to the highest priority handler is
> > > > used to provide fallback: If multiple power-off handlers are installed,
> > > > all handlers will be called until one actually succeeds to power off the
> > > > system.
> > > > 
> > > > Patch 01/47 implements the power-off handler API.
> > > > 
> > > > Patches 02/47 to 04/47 are cleanup patches to prepare for the move of
> > > > pm_power_off to a common location.
> > > > 
> > > > Patches 05/47 to 07/47 remove references to pm_power_off from devicetree
> > > > bindings descriptions.
> > > > 
> > > > Patch 08/47 moves the pm_power_off variable from architecture code to
> > > > kernel/reboot.c. 
> > > > 
> > > > Patches 09/47 to 34/47 convert various drivers to register with the kernel
> > > > power-off handler instead of setting pm_power_off directly.
> > > > 
> > > > Patches 35/47 to 46/47 do the same for architecture code.
> > > > 
> > > > Patch 47/47 finally removes pm_power_off.
> > > > 
> > > > For the most part, the individual patches include explanations why specific
> > > > priorities were chosen, at least if the selected priority is not the default
> > > > priority. Subsystem and architecture maintainers are encouraged to have a look
> > > > at the selected priorities and suggest improvements.
> > > > 
> > > > I ran the final code through my normal build and qemu tests. Results are
> > > > available at http://server.roeck-us.net:8010/builders in the 'poweroff-handler'
> > > > column. I also built all available configurations for arm, mips, powerpc,
> > > > m68k, and sh architectures.
> > > > 
> > > > The series is available in branch poweroff-handler of my repository at
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.
> > > > It is based on 3.18-rc2.
> > > > 
> > > > A note on Cc: In the initial submission I had way too many Cc:, causing the
> > > > patchset to be treated as spam by many mailers and mailing list handlers,
> > > > which of course defeated the purpose. This time around I am cutting down
> > > > the distribution list down significantly. My apologies to anyone I may have
> > > > failed to copy this time around.
> > > 
> > > you touch every single architecture with this patchset, but you didn't
> > > care about Ccing any of the arch-specific mailing lists, like lakml ?
> > > 
> > What is lakml ? linux-kernel@vger.kernel.org was copied, if that is what you
> 
> only the greatest mailing list of all time.
> 
> heh, Linux ARM Kernel Mailing List.
> 

Similar to linux-omap, linux-arm-kernel was copied on individual patches
if get_maintainer.pl suggested it. I'll be happy to add both lists manually
to the entire series for the next version of the patch set if the respective
maintainers (Tony and Russell) ask me to do so.

Note that this doesn't mean that the patches will actually be accepted by
those lists, especially if the lists are moderated for non-subscribers.

Guenter