From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain Date: Wed, 17 Jun 2015 18:04:54 -0700 Message-ID: <55821936.4040704@codeaurora.org> References: <1412659726-29957-1-git-send-email-linux@roeck-us.net> <1412659726-29957-2-git-send-email-linux@roeck-us.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1412659726-29957-2-git-send-email-linux@roeck-us.net> Sender: linux-hexagon-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Guenter Roeck , linux-kernel@vger.kernel.org Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org, linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org, Heiko Stuebner , Len Brown , linux-xtensa@linux-xtensa.org, Pavel Machek , devel@driverdev.osuosl.org, linux-s390@vger.kernel.org, lguest@lists.ozlabs.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org, Alexander Graf , linux-acpi@vger.kernel.org, Geert Uytterhoeven , xen-devel@lists.xenproject.org, devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net, linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead On 10/06/2014 10:28 PM, 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 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 poweroff 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 poweroff 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 poweroff functionality are expected to register with this call chain. > By using the priority field in the notifier block, callers can control > poweroff handler execution sequence and thus ensure that the poweroff > handler with the optimal capabilities to remove power for a given system > is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I'm also considering putting the PMIC configuration part into the reboot notifier chain, because it only does things to change the configuration and not actually any shutdown/restart itself. That removes any requirement to get the priority of notifiers right. This series will still be useful for the MMIO register that needs to be toggled though. Right now I have to assign pm_power_off or hook the reboot notifier with a different priority to make this work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Date: Thu, 18 Jun 2015 01:04:54 +0000 Subject: Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain Message-Id: <55821936.4040704@codeaurora.org> List-Id: References: <1412659726-29957-1-git-send-email-linux@roeck-us.net> <1412659726-29957-2-git-send-email-linux@roeck-us.net> In-Reply-To: <1412659726-29957-2-git-send-email-linux@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Guenter Roeck , linux-kernel@vger.kernel.org Cc: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org, linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org, Heiko Stuebner , Len Brown , linux-xtensa@linux-xtensa.org, Pavel Machek , devel@driverdev.osuosl.org, linux-s390@vger.kernel.org, lguest@lists.ozlabs.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org, Alexander Graf , linux-acpi@vger.kernel.org, Geert Uytterhoeven , xen-devel@lists.xenproject.org, devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net, linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead On 10/06/2014 10:28 PM, 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 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 poweroff 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 poweroff 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 poweroff functionality are expected to register with this call chain. > By using the priority field in the notifier block, callers can control > poweroff handler execution sequence and thus ensure that the poweroff > handler with the optimal capabilities to remove power for a given system > is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I'm also considering putting the PMIC configuration part into the reboot notifier chain, because it only does things to change the configuration and not actually any shutdown/restart itself. That removes any requirement to get the priority of notifiers right. This series will still be useful for the MMIO register that needs to be toggled though. Right now I have to assign pm_power_off or hook the reboot notifier with a different priority to make this work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 18 Jun 2015 03:05:01 +0200 (CEST) Received: from smtp.codeaurora.org ([198.145.29.96]:55164 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27008768AbbFRBFACjPb5 (ORCPT ); Thu, 18 Jun 2015 03:05:00 +0200 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id E4BDB1400CD; Thu, 18 Jun 2015 01:04:57 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id C7C511400D8; Thu, 18 Jun 2015 01:04:57 +0000 (UTC) Received: from [10.134.64.202] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 4E0BF1400CD; Thu, 18 Jun 2015 01:04:55 +0000 (UTC) Message-ID: <55821936.4040704@codeaurora.org> Date: Wed, 17 Jun 2015 18:04:54 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Guenter Roeck , linux-kernel@vger.kernel.org CC: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org, linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org, Heiko Stuebner , Len Brown , linux-xtensa@linux-xtensa.org, Pavel Machek , devel@driverdev.osuosl.org, linux-s390@vger.kernel.org, lguest@lists.ozlabs.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org, Alexander Graf , linux-acpi@vger.kernel.org, Geert Uytterhoeven , xen-devel@lists.xenproject.org, devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net, linux-m68k@lists.linux-m68k.org, linux-am33-list@redhat.com, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com, "Rafael J. Wysocki" , linux-alpha@vger.kernel.org, Andrew Morton , Romain Perier , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain References: <1412659726-29957-1-git-send-email-linux@roeck-us.net> <1412659726-29957-2-git-send-email-linux@roeck-us.net> In-Reply-To: <1412659726-29957-2-git-send-email-linux@roeck-us.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 47962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sboyd@codeaurora.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On 10/06/2014 10:28 PM, 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 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 poweroff 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 poweroff 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 poweroff functionality are expected to register with this call chain. > By using the priority field in the notifier block, callers can control > poweroff handler execution sequence and thus ensure that the poweroff > handler with the optimal capabilities to remove power for a given system > is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I'm also considering putting the PMIC configuration part into the reboot notifier chain, because it only does things to change the configuration and not actually any shutdown/restart itself. That removes any requirement to get the priority of notifiers right. This series will still be useful for the MMIO register that needs to be toggled though. Right now I have to assign pm_power_off or hook the reboot notifier with a different priority to make this work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: sboyd@codeaurora.org (Stephen Boyd) Date: Wed, 17 Jun 2015 18:04:54 -0700 Subject: [PATCH 01/44] kernel: Add support for poweroff handler call chain In-Reply-To: <1412659726-29957-2-git-send-email-linux@roeck-us.net> References: <1412659726-29957-1-git-send-email-linux@roeck-us.net> <1412659726-29957-2-git-send-email-linux@roeck-us.net> Message-ID: <55821936.4040704@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/06/2014 10:28 PM, 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 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 poweroff 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 poweroff 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 poweroff functionality are expected to register with this call chain. > By using the priority field in the notifier block, callers can control > poweroff handler execution sequence and thus ensure that the poweroff > handler with the optimal capabilities to remove power for a given system > is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I'm also considering putting the PMIC configuration part into the reboot notifier chain, because it only does things to change the configuration and not actually any shutdown/restart itself. That removes any requirement to get the priority of notifiers right. This series will still be useful for the MMIO register that needs to be toggled though. Right now I have to assign pm_power_off or hook the reboot notifier with a different priority to make this work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbbFRBFH (ORCPT ); Wed, 17 Jun 2015 21:05:07 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:39062 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753968AbbFRBE7 (ORCPT ); Wed, 17 Jun 2015 21:04:59 -0400 Message-ID: <55821936.4040704@codeaurora.org> Date: Wed, 17 Jun 2015 18:04:54 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Guenter Roeck , linux-kernel@vger.kernel.org CC: linux-m32r-ja@ml.linux-m32r.org, linux-mips@linux-mips.org, linux-efi@vger.kernel.org, linux-ia64@vger.kernel.org, Heiko Stuebner , Len Brown , linux-xtensa@linux-xtensa.org, Pavel Machek , devel@driverdev.osuosl.org, linux-s390@vger.kernel.org, lguest@lists.ozlabs.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org, Alexander Graf , linux-acpi@vger.kernel.org, Geert Uytterhoeven , xen-devel@lists.xenproject.org, devicetree@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net, linux-pm@vger.kernel.org, adi-buildroot-devel@lists.sourceforge.net, linux-m68k@vger.kernel.org, linux-am33-list@redhat.com, linux-tegra@vger.kernel.org, openipmi-developer@lists.sourceforge.net, linux-metag@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, linux-cris-kernel@axis.com, "Rafael J. Wysocki" , linux-alpha@vger.kernel.org, Andrew Morton , Romain Perier , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain References: <1412659726-29957-1-git-send-email-linux@roeck-us.net> <1412659726-29957-2-git-send-email-linux@roeck-us.net> In-Reply-To: <1412659726-29957-2-git-send-email-linux@roeck-us.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/06/2014 10:28 PM, 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 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 poweroff 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 poweroff 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 poweroff functionality are expected to register with this call chain. > By using the priority field in the notifier block, callers can control > poweroff handler execution sequence and thus ensure that the poweroff > handler with the optimal capabilities to remove power for a given system > is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I'm also considering putting the PMIC configuration part into the reboot notifier chain, because it only does things to change the configuration and not actually any shutdown/restart itself. That removes any requirement to get the priority of notifiers right. This series will still be useful for the MMIO register that needs to be toggled though. Right now I have to assign pm_power_off or hook the reboot notifier with a different priority to make this work. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project