| Message ID | 1457319045-25434-1-git-send-email-yu.c.chen@intel.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Mon, Mar 7, 2016 at 3:50 AM, Chen Yu <yu.c.chen@intel.com> wrote: > The problem is Linux registers pm_power_off = efi_power_off > only if we are in hardware reduced mode. Actually, what we also > want is to do this when ACPI S5 is simply not supported on > non-legacy platforms. That should handle both the HW reduced mode, > and the HW-full mode where the DSDT fails to supply an _S5 object. > > This patch fixes this issue by introducing a new flag acpi_no_s5 which > indicates the non-existence of _S5. The initial state of acpi_no_s5 is > false and probed in acpi_sleep_init, then we'll later see the updated > value in efi_poweroff_required, according to which we can set pm_power_off > to efi_power_off in efi_shutdown_init, if no other pm_power_off available. > > Suggested-by: Len Brown <len.brown@intel.com> > Signed-off-by: Chen Yu <yu.c.chen@intel.com> > --- > v3: > - Only assign pm_power_off to efi_power_off when there are no > other pm_power_off registered at that time, in case other > commponents would like to customize their own implementation. > --- > v2: > - Convert the acpi_no_s5 to a global bool variable in sleep.c and > add a declaration to include/linux/acpi.h. > --- > arch/x86/platform/efi/quirks.c | 2 +- > drivers/acpi/sleep.c | 8 ++++++++ > include/linux/acpi.h | 1 + > 3 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c > index 2d66db8..0d4186b 100644 > --- a/arch/x86/platform/efi/quirks.c > +++ b/arch/x86/platform/efi/quirks.c > @@ -295,5 +295,5 @@ bool efi_reboot_required(void) > > 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? > } Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGkgUmFmYWVsLA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcmp3 eXNvY2tpQGdtYWlsLmNvbSBbbWFpbHRvOnJqd3lzb2NraUBnbWFpbC5jb21dIE9uIEJlaGFsZiBP Zg0KPiBSYWZhZWwgSi4gV3lzb2NraQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDk6 MTkgUE0NCj4gVG86IENoZW4sIFl1IEMNCj4gQ2M6IEFDUEkgRGV2ZWwgTWFsaW5nIExpc3Q7IHg4 NkBrZXJuZWwub3JnOyBsaW51eC1lZmlAdmdlci5rZXJuZWwub3JnOyBMaW51eA0KPiBLZXJuZWwg TWFpbGluZyBMaXN0OyBsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmc7IFJhZmFlbCBKLiBXeXNvY2tp OyBMZW4gQnJvd247DQo+IE1hdHQgRmxlbWluZzsgVGhvbWFzIEdsZWl4bmVyOyBJbmdvIE1vbG5h cjsgSC4gUGV0ZXIgQW52aW47IFpoYW5nLCBSdWkNCj4gU3ViamVjdDogUmU6IFtQQVRDSF1bUkZD IHYzXSBBQ1BJIC8gUE06IEZpeCBwb3dlcm9mZiBpc3N1ZSBvbiBIVy1mdWxsDQo+IHBsYXRmb3Jt cyB3aXRob3V0IF9TNQ0KPiANCj4gT24gTW9uLCBNYXIgNywgMjAxNiBhdCAzOjUwIEFNLCBDaGVu IFl1IDx5dS5jLmNoZW5AaW50ZWwuY29tPiB3cm90ZToNCj4gPiBUaGUgcHJvYmxlbSBpcyBMaW51 eCByZWdpc3RlcnMgcG1fcG93ZXJfb2ZmID0gZWZpX3Bvd2VyX29mZiBvbmx5IGlmIHdlDQo+ID4g YXJlIGluIGhhcmR3YXJlIHJlZHVjZWQgbW9kZS4gQWN0dWFsbHksIHdoYXQgd2UgYWxzbyB3YW50 IGlzIHRvIGRvDQo+ID4gdGhpcyB3aGVuIEFDUEkgUzUgaXMgc2ltcGx5IG5vdCBzdXBwb3J0ZWQg b24gbm9uLWxlZ2FjeSBwbGF0Zm9ybXMuDQo+ID4gVGhhdCBzaG91bGQgaGFuZGxlIGJvdGggdGhl IEhXIHJlZHVjZWQgbW9kZSwgYW5kIHRoZSBIVy1mdWxsIG1vZGUNCj4gPiB3aGVyZSB0aGUgRFNE VCBmYWlscyB0byBzdXBwbHkgYW4gX1M1IG9iamVjdC4NCj4gPg0KPiA+IFRoaXMgcGF0Y2ggZml4 ZXMgdGhpcyBpc3N1ZSBieSBpbnRyb2R1Y2luZyBhIG5ldyBmbGFnIGFjcGlfbm9fczUgd2hpY2gN Cj4gPiBpbmRpY2F0ZXMgdGhlIG5vbi1leGlzdGVuY2Ugb2YgX1M1LiBUaGUgaW5pdGlhbCBzdGF0 ZSBvZiBhY3BpX25vX3M1IGlzDQo+ID4gZmFsc2UgYW5kIHByb2JlZCBpbiBhY3BpX3NsZWVwX2lu aXQsIHRoZW4gd2UnbGwgbGF0ZXIgc2VlIHRoZSB1cGRhdGVkDQo+ID4gdmFsdWUgaW4gZWZpX3Bv d2Vyb2ZmX3JlcXVpcmVkLCBhY2NvcmRpbmcgdG8gd2hpY2ggd2UgY2FuIHNldA0KPiA+IHBtX3Bv d2VyX29mZiB0byBlZmlfcG93ZXJfb2ZmIGluIGVmaV9zaHV0ZG93bl9pbml0LCBpZiBubyBvdGhl cg0KPiBwbV9wb3dlcl9vZmYgYXZhaWxhYmxlLg0KPiA+DQo+ID4gU3VnZ2VzdGVkLWJ5OiBMZW4g QnJvd24gPGxlbi5icm93bkBpbnRlbC5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogQ2hlbiBZdSA8 eXUuYy5jaGVuQGludGVsLmNvbT4NCj4gPiAtLS0NCj4gPiB2MzoNCj4gPiAgLSBPbmx5IGFzc2ln biBwbV9wb3dlcl9vZmYgdG8gZWZpX3Bvd2VyX29mZiB3aGVuIHRoZXJlIGFyZSBubw0KPiA+ICAg IG90aGVyIHBtX3Bvd2VyX29mZiByZWdpc3RlcmVkIGF0IHRoYXQgdGltZSwgaW4gY2FzZSBvdGhl cg0KPiA+ICAgIGNvbW1wb25lbnRzIHdvdWxkIGxpa2UgdG8gY3VzdG9taXplIHRoZWlyIG93biBp bXBsZW1lbnRhdGlvbi4NCj4gPiAtLS0NCj4gPiB2MjoNCj4gPiAgLSBDb252ZXJ0IHRoZSBhY3Bp X25vX3M1IHRvIGEgZ2xvYmFsIGJvb2wgdmFyaWFibGUgaW4gc2xlZXAuYyBhbmQNCj4gPiAgICBh ZGQgYSBkZWNsYXJhdGlvbiB0byBpbmNsdWRlL2xpbnV4L2FjcGkuaC4NCj4gPiAtLS0NCj4gPiAg YXJjaC94ODYvcGxhdGZvcm0vZWZpL3F1aXJrcy5jIHwgMiArLQ0KPiA+ICBkcml2ZXJzL2FjcGkv c2xlZXAuYyAgICAgICAgICAgfCA4ICsrKysrKysrDQo+ID4gIGluY2x1ZGUvbGludXgvYWNwaS5o ICAgICAgICAgICB8IDEgKw0KPiA+ICAzIGZpbGVzIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyks IDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9wbGF0Zm9ybS9l ZmkvcXVpcmtzLmMNCj4gPiBiL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9xdWlya3MuYyBpbmRleCAy ZDY2ZGI4Li4wZDQxODZiIDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9x dWlya3MuYw0KPiA+ICsrKyBiL2FyY2gveDg2L3BsYXRmb3JtL2VmaS9xdWlya3MuYw0KPiA+IEBA IC0yOTUsNSArMjk1LDUgQEAgYm9vbCBlZmlfcmVib290X3JlcXVpcmVkKHZvaWQpDQo+ID4NCj4g PiAgYm9vbCBlZmlfcG93ZXJvZmZfcmVxdWlyZWQodm9pZCkNCj4gPiAgew0KPiA+IC0gICAgICAg cmV0dXJuICEhYWNwaV9nYmxfcmVkdWNlZF9oYXJkd2FyZTsNCj4gPiArICAgICAgIHJldHVybiBh Y3BpX2dibF9yZWR1Y2VkX2hhcmR3YXJlIHx8IChhY3BpX25vX3M1ICYmDQo+ID4gKyAhcG1fcG93 ZXJfb2ZmKTsNCj4gDQo+IFdoYXQgaWYgQ09ORklHX0FDUEkgaXMgbm90IHNldCBoZXJlPw0KPiAN CklmIENPTkZJR19BQ1BJIGlzIG5vdCBzZXQsIHRoaXMgZmlsZSB3b3VsZCBub3QgYmUgY29tcGls ZWQsDQpiZWNhdXNlIENPTkZJR19FRkkgZGVwZW5kcyBvbiBDT05GSUdfQUNQSS4NCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. thanks, yu
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. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----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(); } thanks, yu
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? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 08 Mar, at 04:25:30PM, Chen, Yu C wrote: > 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. Certainly the majority of x86 client machines do not use EFI power off, because it hardly ever functions correctly. > 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(); > } Be wary of adding all these control knobs. People just want their machines to reboot properly without having to mess with boot parameters. Let's go back to the start. What prompted this patch? Do Intel have (or are planning) machines that do not have _S5 and are expected to use EFI to reset the system? Or is this some new configuration discussed in the ACPI spec that Linux needs to be support? Can we remove the ambiguity and options to force EFI reset if _S5 is missing? Afterall, that's why the function is called efi_poweroff_*required*. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhZWwgSi4gV3lzb2NraSBb bWFpbHRvOnJqd0Byand5c29ja2kubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA5LCAy MDE2IDY6NTcgQU0NCj4gVG86IENoZW4sIFl1IEMNCj4gQ2M6IFJhZmFlbCBKLiBXeXNvY2tpOyBB Q1BJIERldmVsIE1hbGluZyBMaXN0OyB4ODZAa2VybmVsLm9yZzsgbGludXgtDQo+IGVmaUB2Z2Vy Lmtlcm5lbC5vcmc7IExpbnV4IEtlcm5lbCBNYWlsaW5nIExpc3Q7IGxpbnV4LXBtQHZnZXIua2Vy bmVsLm9yZzsNCj4gTGVuIEJyb3duOyBNYXR0IEZsZW1pbmc7IFRob21hcyBHbGVpeG5lcjsgSW5n byBNb2xuYXI7IEguIFBldGVyIEFudmluOw0KPiBaaGFuZywgUnVpDQo+IFN1YmplY3Q6IFJlOiBb UEFUQ0hdW1JGQyB2M10gQUNQSSAvIFBNOiBGaXggcG93ZXJvZmYgaXNzdWUgb24gSFctZnVsbA0K PiBwbGF0Zm9ybXMgd2l0aG91dCBfUzUNCj4gDQo+IE9uIFR1ZXNkYXksIE1hcmNoIDA4LCAyMDE2 IDA0OjI1OjMwIFBNIENoZW4sIFl1IEMgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gRnJvbTogbGludXgtcG0tb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWls dG86bGludXgtcG0tDQo+ID4gPiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBS YWZhZWwgSi4gV3lzb2NraQ0KPiA+ID4gU2VudDogVHVlc2RheSwgTWFyY2ggMDgsIDIwMTYgOTo1 NCBBTQ0KPiA+ID4gVG86IENoZW4sIFl1IEMNCj4gPiA+IENjOiBSYWZhZWwgSi4gV3lzb2NraTsg QUNQSSBEZXZlbCBNYWxpbmcgTGlzdDsgeDg2QGtlcm5lbC5vcmc7DQo+ID4gPiBsaW51eC0gZWZp QHZnZXIua2VybmVsLm9yZzsgTGludXggS2VybmVsIE1haWxpbmcgTGlzdDsNCj4gPiA+IGxpbnV4 LXBtQHZnZXIua2VybmVsLm9yZzsgTGVuIEJyb3duOyBNYXR0IEZsZW1pbmc7IFRob21hcyBHbGVp eG5lcjsNCj4gPiA+IEluZ28gTW9sbmFyOyBILiBQZXRlciBBbnZpbjsgWmhhbmcsIFJ1aQ0KPiA+ ID4gU3ViamVjdDogUmU6IFtQQVRDSF1bUkZDIHYzXSBBQ1BJIC8gUE06IEZpeCBwb3dlcm9mZiBp c3N1ZSBvbg0KPiA+ID4gSFctZnVsbCBwbGF0Zm9ybXMgd2l0aG91dCBfUzUNCj4gPiA+DQo+ID4g PiBPbiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDAzOjUzOjEzIFBNIENoZW4sIFl1IEMgd3JvdGU6 DQo+ID4gPiA+IEhpIFJhZmFlbCwNCj4gPiA+ID4gKHJlc2VuZCBmb3IgYnJva2VuIGNvbnRlbnQp DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiBGcm9tOiByand5c29ja2lAZ21haWwuY29tIFttYWlsdG86cmp3eXNvY2tpQGdtYWlsLmNvbV0g T24gQmVoYWxmDQo+ID4gPiA+ID4gT2YgUmFmYWVsIEouIFd5c29ja2kNCj4gPiA+ID4gPiBTZW50 OiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDk6MTkgUE0NCj4gPiA+ID4gPiBUbzogQ2hlbiwgWXUg Qw0KPiA+ID4gPiA+IENjOiBBQ1BJIERldmVsIE1hbGluZyBMaXN0OyB4ODZAa2VybmVsLm9yZzsN Cj4gPiA+ID4gPiBsaW51eC1lZmlAdmdlci5rZXJuZWwub3JnOyBMaW51eCBLZXJuZWwgTWFpbGlu ZyBMaXN0Ow0KPiA+ID4gPiA+IGxpbnV4LXBtQHZnZXIua2VybmVsLm9yZzsgUmFmYWVsIEouIFd5 c29ja2k7IExlbiBCcm93bjsgTWF0dA0KPiA+ID4gPiA+IEZsZW1pbmc7IFRob21hcyBHbGVpeG5l cjsgSW5nbyBNb2xuYXI7IEguIFBldGVyIEFudmluOyBaaGFuZywNCj4gPiA+ID4gPiBSdWkNCj4g PiA+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIXVtSRkMgdjNdIEFDUEkgLyBQTTogRml4IHBvd2Vy b2ZmIGlzc3VlIG9uDQo+ID4gPiA+ID4gSFctZnVsbCBwbGF0Zm9ybXMgd2l0aG91dCBfUzUNCj4g PiA+ID4gPg0KPiA+ID4gPiBbY3V0XQ0KPiA+ID4gPiA+ID4gIGJvb2wgZWZpX3Bvd2Vyb2ZmX3Jl cXVpcmVkKHZvaWQpICB7DQo+ID4gPiA+ID4gPiAtICAgICAgIHJldHVybiAhIWFjcGlfZ2JsX3Jl ZHVjZWRfaGFyZHdhcmU7DQo+ID4gPiA+ID4gPiArICAgICAgIHJldHVybiBhY3BpX2dibF9yZWR1 Y2VkX2hhcmR3YXJlIHx8IChhY3BpX25vX3M1ICYmDQo+ID4gPiA+ID4gPiArICFwbV9wb3dlcl9v ZmYpOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gV2hhdCBpZiBDT05GSUdfQUNQSSBpcyBub3Qgc2V0 IGhlcmU/DQo+ID4gPiA+IElmIENPTkZJR19BQ1BJIGlzIG5vdCBzZXQsIHRoaXMgZmlsZSB3b3Vs ZCBub3QgYmUgY29tcGlsZWQsDQo+ID4gPiA+IGJlY2F1c2UgQ09ORklHX0VGSSBkZXBlbmRzIG9u IENPTkZJR19BQ1BJLg0KPiA+ID4NCj4gPiA+IE9LDQo+ID4gPg0KPiA+ID4gU28gdGhlIG5leHQg cXVlc3Rpb24gd2lsbCBiZSBpZiBlZmlfcG93ZXJvZmZfcmVxdWlyZWQoKSBpcw0KPiA+ID4gZ3Vh cmFudGVlZCB0byBydW4gYWZ0ZXIgYWxsIG9mIHRoZSBvdGhlciBjb2RlIHRoYXQgbWF5IHJlZ2lz dGVyIGFsdGVybmF0aXZlDQo+IHBvd2VyIG9mZiBoYW5kbGluZy4NCj4gPiBIdW0uIHVuZm9ydHVu YXRlbHkgaXQgaXMgbm90IGd1YXJhbnRlZWQgdG8gcnVuIGFmdGVyIGFsbCBvZiB0aGUgb3RoZXIN Cj4gPiBjb2RlLCBiZWNhdXNlIG90aGVyIGNvbXBvbmVudHMgd2hvIHJlZ2lzdGVyIHBtX3Bvd2Vy X29mZiBtYXkgYmUNCj4gYnVpbHQgYXMgbW9kdWxlcywgYW5kDQo+ID4gd2UgY2FuIG5vdCBwcmVk aWN0L2NvbnRyb2wgdGhlIHNlcXVlbmNlIHJlZ2lzdHJhdGlvbi4gICBTbyB0aGlzIHBhdGNoIG1h eQ0KPiA+IGJyZWFrIHRoZSBFRkkgcGxhdGZvcm1zIHdobyB1c2Ugbm9uLWVmaSBwb3dlcm9mZiBk dWUgdG8gdW5zdGFibGUgRUZJDQo+ID4gc2VydmljZSAsICBub3Qgc3VyZSBpZiB0aGVyZSBhcmUg YW55IHJlbGVhc2VkLXByb2R1Y3RzIG9mIHRoaXMga2luZC4NCj4gPg0KPiA+IEN1cnJlbnRseSBJ J20gdGhpbmtpbmcgb2YgMyBwb3NzaWJsZSBzb2x1dGlvbnMsICBjb3VsZCB5b3UgcGxlYXNlIGdp dmUgc29tZQ0KPiBhZHZpY2VzIG9uIHRoZW06DQo+ID4NCj4gPiAxLiBJbnRyb2R1Y2UgYm9vdG9w dCBvZiAncG93ZXJvZmY9ZWZpJw0KPiA+ICAgICAgU2V0IHRoZSBwbV9wb3dlcl9vZmYgdG8gZWZp X3Bvd2VyX29mZiBubyBtYXR0ZXIgd2hldGhlciB0aGVyZSBpcw0KPiA+IF9TNSBvciBub3QNCj4g Pg0KPiA+IDIuIEludHJvZHVjZSAvc3lzL3Bvd2VyL3Bvd2Vyb2ZmDQo+ID4gICAgIEFsbG93IHRo ZSB1c2VyIHRvIGNob29zZSB3aGljaCAgcG1fcG93ZXJfb2ZmLCBmb3IgZXhhbXBsZToNCj4gPg0K PiA+ICMgY2F0IC9zeXMvcG93ZXIvcG93ZXJvZmYNCj4gPiAqYWNwaQkJYWNwaV9wb3dlcl9vZmYN Cj4gPiBlZmkJCWVmaV9wb3dlcl9vZmYNCj4gPiBncGlvCQlncGlvX3Bvd2Vyb2ZmX2RvX3Bvd2Vy b2ZmDQo+ID4gdXNlciBjYW4gZWNobyBzdHJpbmcgdG8gZW5hYmxlIHdoaWNoIG9uZS4NCj4gPg0K PiA+IEFuZCB0d28gQVBJczoNCj4gPiByZWdpc3Rlcl9wb3dlcl9vZmYoY2hhciAqbmFtZSwgcG93 ZXJfb2ZmIGZ1bmMpDQo+ID4gdW5yZWdpc3Rlcl9wb3dlcl9vZmYoY2hhciAqbmFtZSkNCj4gPg0K PiA+DQo+ID4gMy4gcmVwbGFjZSBhbGwgdGhlIGNvZGVzIG9mICBwbV9wb3dlcl9vZmYoKSB3aXRo DQo+ID4gcmVsaWFibGVfcG1fcG93ZXJfb2ZmKCkNCj4gPg0KPiA+IHZvaWQgcmVsaWFibGVfcG1f cG93ZXJfb2ZmKHZvaWQpDQo+ID4gew0KPiA+IAlpZiAoIXBtX3Bvd2VyX29mZikgew0KPiA+IAkJ aWYgKGFjcGlfbm9fczUpDQo+ID4gCQkJcG1fcG93ZXJfb2ZmID0gZWZpX3Bvd2VyX29mZjsNCj4g PiAJLyogT3RoZXIgY29uZGl0aW9ucyBhZGRlZCBpbiB0aGUgZnV0dXJlLiAqLw0KPiA+IAl9DQo+ ID4gCXBtX3Bvd2VyX29mZigpOw0KPiA+IH0NCj4gDQo+IFdoYXQgYWJvdXQgc29tZXRoaW5nIGxp a2UgYWRkaW5nIHNvbWV0aGluZyBsaWtlIGRlZmF1bHRfcG93ZXJfb2ZmIHRoYXQNCj4gd291bGQg YmUgdXNlZCBieSBwbV9wb3dlcl9vZmYgaWYgbm90aGluZyBlbHNlIGlzIGF2YWlsYWJsZT8NCk9L LCAgSSdsbCB0cnkgYW5vdGhlciB2ZXJzaW9uLCBpbiB3aGljaCBvdGhlciBjb21wb25lbnRzIGNh biBzZXQgIGl0cyBkZWZhdWx0X3Bvd2VyX29mZiwNCnRoZW4gcG1fcG93ZXJfb2ZmIGhhcyBhIGNo YW5jZSB0byBiZSBzZXQgdG8gZGVmYXVsdF9wb3dlcl9vZmYgaWYgcG1fcG93ZXJfb2ZmIGlzIE5V TEwuDQoNCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Matt, > -----Original Message----- > From: Matt Fleming [mailto:matt@codeblueprint.co.uk] > Sent: Wednesday, March 09, 2016 11:35 PM > To: Chen, Yu C > Cc: Rafael J. Wysocki; 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; 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 Tue, 08 Mar, at 04:25:30PM, Chen, Yu C wrote: > > 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. > > Certainly the majority of x86 client machines do not use EFI power off, > because it hardly ever functions correctly. > > > 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(); > > } > > Be wary of adding all these control knobs. People just want their machines to > reboot properly without having to mess with boot parameters. > > Let's go back to the start. What prompted this patch? Do Intel have (or are > planning) machines that do not have _S5 and are expected to use EFI to reset > the system? Yes, there might be a new platform without _S5, and might need EFI poweroff for a backup. > Or is this some new configuration discussed in the ACPI spec > that Linux needs to be support? > > Can we remove the ambiguity and options to force EFI reset if _S5 is missing? > Afterall, that's why the function is called efi_poweroff_*required*. OK, the boot option is obsoleted, I'll try another version of default_power_off per Rafael's suggestion, thanks. yu -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c index 2d66db8..0d4186b 100644 --- a/arch/x86/platform/efi/quirks.c +++ b/arch/x86/platform/efi/quirks.c @@ -295,5 +295,5 @@ bool efi_reboot_required(void) bool efi_poweroff_required(void) { - return !!acpi_gbl_reduced_hardware; + return acpi_gbl_reduced_hardware || (acpi_no_s5 && !pm_power_off); } diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index 9cb9752..94099a4 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -25,6 +25,12 @@ #include "internal.h" #include "sleep.h" +/* + * Some HW-full platforms do not have _S5, they may have + * to leverage efi rather than acpi for a shutdown, if no + * other pm_power_off available. + */ +bool acpi_no_s5; static u8 sleep_states[ACPI_S_STATE_COUNT]; static void acpi_sleep_tts_switch(u32 acpi_state) @@ -846,6 +852,8 @@ int __init acpi_sleep_init(void) sleep_states[ACPI_STATE_S5] = 1; pm_power_off_prepare = acpi_power_off_prepare; pm_power_off = acpi_power_off; + } else { + acpi_no_s5 = true; } supported[0] = 0; diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 06ed7e5..4d2e67f 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -278,6 +278,7 @@ void acpi_irq_stats_init(void); extern u32 acpi_irq_handled; extern u32 acpi_irq_not_handled; extern unsigned int acpi_sci_irq; +extern bool acpi_no_s5; #define INVALID_ACPI_IRQ ((unsigned)-1) static inline bool acpi_sci_irq_valid(void) {
The problem is Linux registers pm_power_off = efi_power_off only if we are in hardware reduced mode. Actually, what we also want is to do this when ACPI S5 is simply not supported on non-legacy platforms. That should handle both the HW reduced mode, and the HW-full mode where the DSDT fails to supply an _S5 object. This patch fixes this issue by introducing a new flag acpi_no_s5 which indicates the non-existence of _S5. The initial state of acpi_no_s5 is false and probed in acpi_sleep_init, then we'll later see the updated value in efi_poweroff_required, according to which we can set pm_power_off to efi_power_off in efi_shutdown_init, if no other pm_power_off available. Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> --- v3: - Only assign pm_power_off to efi_power_off when there are no other pm_power_off registered at that time, in case other commponents would like to customize their own implementation. --- v2: - Convert the acpi_no_s5 to a global bool variable in sleep.c and add a declaration to include/linux/acpi.h. --- arch/x86/platform/efi/quirks.c | 2 +- drivers/acpi/sleep.c | 8 ++++++++ include/linux/acpi.h | 1 + 3 files changed, 10 insertions(+), 1 deletion(-)