Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934854AbcCJCRB (ORCPT ); Wed, 9 Mar 2016 21:17:01 -0500 Received: from mga03.intel.com ([134.134.136.65]:15063 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934818AbcCJCQu (ORCPT ); Wed, 9 Mar 2016 21:16:50 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,313,1455004800"; d="scan'208";a="930617169" From: "Chen, Yu C" To: "Rafael J. Wysocki" CC: "Rafael J. Wysocki" , ACPI Devel Maling List , "x86@kernel.org" , "linux-efi@vger.kernel.org" , "Linux Kernel Mailing List" , "linux-pm@vger.kernel.org" , Len Brown , Matt Fleming , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "Zhang, Rui" Subject: RE: [PATCH][RFC v3] ACPI / PM: Fix poweroff issue on HW-full platforms without _S5 Thread-Topic: [PATCH][RFC v3] ACPI / PM: Fix poweroff issue on HW-full platforms without _S5 Thread-Index: AQHReBtTuYTrZFDLZkGy2iiQCJLNIJ9NcY+AgACwtaCAACIcAIABZrTQ///6MgCAAk9ZkA== Date: Thu, 10 Mar 2016 02:16:44 +0000 Message-ID: <36DF59CE26D8EE47B0655C516E9CE640286D3E69@shsmsx102.ccr.corp.intel.com> References: <1457319045-25434-1-git-send-email-yu.c.chen@intel.com> <2414254.VhAiD01BTS@vostro.rjw.lan> <36DF59CE26D8EE47B0655C516E9CE640286D370A@shsmsx102.ccr.corp.intel.com> <1867318.3ivAYsjD7D@vostro.rjw.lan> In-Reply-To: <1867318.3ivAYsjD7D@vostro.rjw.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGNiZjBjMDYtNDI2Mi00OGIwLTgxZWQtMTkxMTBlNjQwODdhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InVCYTBiNkhxa1BkcXZSRzhKRFRjdVBTOGs4UUtUaHpVOFhidWpDWnhqdms9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u2A2HDWs005597 Content-Length: 4067 Lines: 103 > -----Original Message----- > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net] > Sent: Wednesday, March 09, 2016 6:57 AM > To: Chen, Yu C > Cc: Rafael J. Wysocki; ACPI Devel Maling List; x86@kernel.org; linux- > efi@vger.kernel.org; Linux Kernel Mailing List; linux-pm@vger.kernel.org; > Len Brown; Matt Fleming; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; > Zhang, Rui > Subject: Re: [PATCH][RFC v3] ACPI / PM: Fix poweroff issue on HW-full > platforms without _S5 > > On Tuesday, March 08, 2016 04:25:30 PM Chen, Yu C wrote: > > > -----Original Message----- > > > From: linux-pm-owner@vger.kernel.org [mailto:linux-pm- > > > owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki > > > Sent: Tuesday, March 08, 2016 9:54 AM > > > To: Chen, Yu C > > > Cc: Rafael J. Wysocki; ACPI Devel Maling List; x86@kernel.org; > > > linux- efi@vger.kernel.org; Linux Kernel Mailing List; > > > linux-pm@vger.kernel.org; Len Brown; Matt Fleming; Thomas Gleixner; > > > Ingo Molnar; H. Peter Anvin; Zhang, Rui > > > Subject: Re: [PATCH][RFC v3] ACPI / PM: Fix poweroff issue on > > > HW-full platforms without _S5 > > > > > > On Monday, March 07, 2016 03:53:13 PM Chen, Yu C wrote: > > > > Hi Rafael, > > > > (resend for broken content) > > > > > > > > > -----Original Message----- > > > > > From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf > > > > > Of Rafael J. Wysocki > > > > > Sent: Monday, March 07, 2016 9:19 PM > > > > > To: Chen, Yu C > > > > > Cc: ACPI Devel Maling List; x86@kernel.org; > > > > > linux-efi@vger.kernel.org; Linux Kernel Mailing List; > > > > > linux-pm@vger.kernel.org; Rafael J. Wysocki; Len Brown; Matt > > > > > Fleming; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Zhang, > > > > > Rui > > > > > Subject: Re: [PATCH][RFC v3] ACPI / PM: Fix poweroff issue on > > > > > HW-full platforms without _S5 > > > > > > > > > [cut] > > > > > > bool efi_poweroff_required(void) { > > > > > > - return !!acpi_gbl_reduced_hardware; > > > > > > + return acpi_gbl_reduced_hardware || (acpi_no_s5 && > > > > > > + !pm_power_off); > > > > > > > > > > What if CONFIG_ACPI is not set here? > > > > If CONFIG_ACPI is not set, this file would not be compiled, > > > > because CONFIG_EFI depends on CONFIG_ACPI. > > > > > > OK > > > > > > So the next question will be if efi_poweroff_required() is > > > guaranteed to run after all of the other code that may register alternative > power off handling. > > Hum. unfortunately it is not guaranteed to run after all of the other > > code, because other components who register pm_power_off may be > built as modules, and > > we can not predict/control the sequence registration. So this patch may > > break the EFI platforms who use non-efi poweroff due to unstable EFI > > service , not sure if there are any released-products of this kind. > > > > Currently I'm thinking of 3 possible solutions, could you please give some > advices on them: > > > > 1. Introduce bootopt of 'poweroff=efi' > > Set the pm_power_off to efi_power_off no matter whether there is > > _S5 or not > > > > 2. Introduce /sys/power/poweroff > > Allow the user to choose which pm_power_off, for example: > > > > # cat /sys/power/poweroff > > *acpi acpi_power_off > > efi efi_power_off > > gpio gpio_poweroff_do_poweroff > > user can echo string to enable which one. > > > > And two APIs: > > register_power_off(char *name, power_off func) > > unregister_power_off(char *name) > > > > > > 3. replace all the codes of pm_power_off() with > > reliable_pm_power_off() > > > > void reliable_pm_power_off(void) > > { > > if (!pm_power_off) { > > if (acpi_no_s5) > > pm_power_off = efi_power_off; > > /* Other conditions added in the future. */ > > } > > pm_power_off(); > > } > > What about something like adding something like default_power_off that > would be used by pm_power_off if nothing else is available? OK, I'll try another version, in which other components can set its default_power_off, then pm_power_off has a chance to be set to default_power_off if pm_power_off is NULL.