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@xxxxxxxxxxxxxxx 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:
signature.asc
Description: Digital signature
