Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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.
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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, >
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 signature.asc Description: Digital signature
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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,
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 signature.asc Description: Digital signature
Re: [PATCH v3 00/47] kernel: Add support for power-off handler call chain
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
