All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	"Alan Cox" <gnomes@lxorguk.ukuu.org.uk>,
	"Alexander Graf" <agraf@suse.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Philippe Rétornaz" <philippe.retornaz@gmail.com>,
	"Romain Perier" <romain.perier@gmail.com>
Subject: Re: [PATCH v5 01/48] kernel: Add support for power-off handler call chain
Date: Thu, 6 Nov 2014 14:27:03 -0800	[thread overview]
Message-ID: <20141106222703.GA6377@roeck-us.net> (raw)
In-Reply-To: <3183593.9HaIZKjCKr@vostro.rjw.lan>

On Thu, Nov 06, 2014 at 11:30:59PM +0100, Rafael J. Wysocki wrote:
> On Thursday, November 06, 2014 08:42:45 AM Guenter Roeck wrote:
> > 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 and architeceture code
> > providing system power-off functionality are expected to register with
> > this call chain.  When registering a power-off handler, callers can
> > provide a priority to 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>
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > Acked-by: Heiko Stuebner <heiko@sntech.de>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> > v5:
> > - Rebase to v3.18-rc3
> > v4:
> > - Do not use notifiers but internal functions and data structures to manage
> >   the list of power-off handlers. Drop unused parameters from callbacks, and
> >   make the power-off function type void.
> >   Code to manage and walk the list of callbacks is derived from notifier.c.
> > 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               |  28 ++++
> >  kernel/power/Makefile            |   1 +
> >  kernel/power/power_off_handler.c | 293 +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 322 insertions(+)
> >  create mode 100644 kernel/power/power_off_handler.c
> > 
> > diff --git a/include/linux/pm.h b/include/linux/pm.h
> > index 383fd68..a4d6bf8 100644
> > --- a/include/linux/pm.h
> > +++ b/include/linux/pm.h
> > @@ -35,6 +35,34 @@ extern void (*pm_power_off)(void);
> >  extern void (*pm_power_off_prepare)(void);
> >  
> >  struct device; /* we have a circular dep with device.h */
> > +
> > +/*
> > + * Data structures and callbacks to manage power-off handlers
> > + */
> > +
> > +struct power_off_handler_block {
> > +	void (*handler)(struct power_off_handler_block *);
> > +	struct power_off_handler_block __rcu *next;
> > +	int priority;
> > +};
> > +
> > +int register_power_off_handler(struct power_off_handler_block *);
> > +int devm_register_power_off_handler(struct device *,
> > +				    struct power_off_handler_block *);
> > +int register_power_off_handler_simple(void (*function)(void), int priority);
> > +int unregister_power_off_handler(struct power_off_handler_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
> 
> I'm not sure why we need these gaps in the priority space.
> 
> I guess it might be possible to use
> 
> enum power_off_priority {
> 	POWER_OFF_PRIORITY_FALLBACK = 0,
> 	POWER_OFF_PRIORITY_LOW,
> 	POWER_OFF_PRIORITY_DEFAULT,
> 	POWER_OFF_PRIORITY_HIGH,
> 	POWER_OFF_PRIORITY_HIGHEST,
> 	POWER_OFF_PRIORITY_LIMIT,
> };

I retained the large number space on purpose, specifically to permit in-between
priorities. In other words, I want people to be able to say "priority for this
handler is higher than low but lower than default". After all, the defines were
intended as hints, not as a "Thou shall use those and only those priorities".

Having said that, the important part is to get the series accepted, so I won't
argue if that is what it takes to get an Ack. Let me know.

Thanks,
Guenter

> 
> and then make register_ complain if priority is POWER_OFF_PRIORITY_LIMIT
> or greater.
> 
> But I'm OK with the rest, so if no one else sees a problem here,
> I'm not going to make a fuss about it.
> 
> Rafael
> 

  reply	other threads:[~2014-11-06 22:27 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 16:42 [PATCH v5 00/48] kernel: Add support for power-off handler call chain Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 01/48] " Guenter Roeck
2014-11-06 22:30   ` Rafael J. Wysocki
2014-11-06 22:27     ` Guenter Roeck [this message]
2014-11-07  0:16       ` Rafael J. Wysocki
2014-11-07  3:00         ` Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 02/48] memory: emif: Use API function to determine power-off capability Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 03/48] hibernate: Call have_kernel_power_off instead of checking pm_power_off Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 04/48] m68k: Replace mach_power_off with pm_power_off Guenter Roeck
2014-11-06 16:42 ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 05/48] mfd: as3722: Drop reference to pm_power_off from devicetree bindings Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 06/48] gpio-poweroff: " Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 07/48] qnap-poweroff: " Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 08/48] kernel: Move pm_power_off to common code Guenter Roeck
2014-11-06 16:42 ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42 ` Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 09/48] mfd: palmas: Register with kernel power-off handler Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 10/48] mfd: axp20x: " Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 11/48] mfd: retu: " Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 12/48] mfd: ab8500-sysctrl: " Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42   ` Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 13/48] mfd: max8907: " Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 14/48] mfd: tps80031: " Guenter Roeck
2014-11-06 16:42 ` [PATCH v5 15/48] mfd: dm355evm_msp: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 16/48] mfd: tps6586x: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 17/48] mfd: tps65910: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 18/48] mfd: twl4030-power: " Guenter Roeck
2014-11-10  8:46   ` Pavel Machek
2014-11-10 14:09     ` Guenter Roeck
2014-11-10 14:49       ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 19/48] mfd: rk808: Register power-off handler " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 20/48] mfd: rn5t618: " Guenter Roeck
2014-11-07 21:00   ` Beniamino Galvani
2014-11-08  4:19     ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 21/48] ipmi: Register " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 22/48] power/reset: restart-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 23/48] power/reset: gpio-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 24/48] power/reset: as3722-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 25/48] power/reset: qnap-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 26/48] power/reset: msm-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 27/48] power/reset: vexpress-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 28/48] power/reset: at91-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 29/48] power/reset: ltc2952-poweroff: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 30/48] x86: iris: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 31/48] x86: apm: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 32/48] x86: olpc: Register xo1 power-off handler " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 33/48] staging: nvec: Register " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
     [not found]   ` <1415292213-28652-34-git-send-email-linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2014-11-09 21:41     ` Marc Dietrich
2014-11-09 21:41       ` Marc Dietrich
2014-11-09 23:06       ` Andreas Färber
2014-11-09 23:06         ` Andreas Färber
2014-11-09 23:54       ` Guenter Roeck
2014-11-09 23:54         ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 34/48] acpi: Register power-off handler " Guenter Roeck
2014-11-06 22:32   ` Rafael J. Wysocki
2014-11-07 19:47     ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 35/48] arm: Register " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 16:43 ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 36/48] arm64: psci: " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 17:22   ` Mark Rutland
2014-11-06 17:22     ` Mark Rutland
2014-11-06 17:22     ` Mark Rutland
2014-11-06 18:51     ` Guenter Roeck
2014-11-06 18:51       ` Guenter Roeck
2014-11-06 18:51       ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 37/48] avr32: atngw100: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 38/48] ia64: " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 39/48] m68k: " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 16:43 ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 40/48] mips: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 41/48] powerpc: " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 42/48] sh: " Guenter Roeck
2014-11-06 16:43   ` Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 43/48] x86: lguest: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 44/48] x86: ce4100: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 45/48] x86: intel-mid: Drop registration of dummy power-off handlers Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 46/48] x86: pmc_atom: Register power-off handler with kernel power-off handler Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 47/48] efi: " Guenter Roeck
2014-11-06 16:43 ` [PATCH v5 48/48] kernel: Remove pm_power_off Guenter Roeck
2014-11-06 17:08 ` [PATCH v5 00/48] kernel: Add support for power-off handler call chain Guenter Roeck
2014-11-06 17:08   ` Guenter Roeck
2014-11-06 18:02   ` Linus Torvalds
2014-11-06 18:48     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141106222703.GA6377@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=agraf@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=heiko@sntech.de \
    --cc=lee.jones@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=philippe.retornaz@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=romain.perier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.