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

[Felipe Balbi]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141103/95fa263a/attachment.sig>