On Wed, 16 Mar, at 05:59:29AM, Chen, Yu C wrote: > Hi Matt, > > > -----Original Message----- > > From: Matt Fleming [mailto:matt@xxxxxxxxxxxxxxxxxxx] > > Sent: Tuesday, March 15, 2016 4:01 AM > > To: Chen, Yu C > > Cc: linux-acpi@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; Rafael J. Wysocki; > > Len Brown; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Zhang, Rui; linux- > > efi@xxxxxxxxxxxxxxx; x86@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Ard > > Biesheuvel; Mark Salter > > Subject: Re: [PATCH][RFC,v4] ACPI / PM: Introduce efi poweroff for HW-full > > platforms without _S5 > > > > On Fri, 11 Mar, at 04:33:46PM, Chen, Yu C wrote: > > > > > > There is a future Base-IA platform, we are planning to skip > > > implementing the SLP_TYP register and the S5 object. (already there > > > will be no S3 and no S4) > > > > Cool. This is really valuable information that should go into the commit > > message. > > > > Because if this is the rationale for the change, I don't see why we'd need to > > provide the default stuff. Instead we should just enforce EFI reboot, and > > only add the pm_poweroff_default hook if there is an explicit user in the > > future, IMO. > > Do you mean the patch v3 make sense > https://patchwork.kernel.org/patch/8514751/ > and we should use efi power off as our first choice, if there is no _S5 available(no acpi_power_off), > even there is a customized poweroff(driver provided, eg)? Unless someone can point to a platform driver that is in the upstream kernel where this is actually a problem, the answer is: yes. For that matter, unless someone can do the same for pm_power_off overriding efi_reboot() (which on x86 would only happen for ACPI HW-reduced platforms), I would be much prefer the original patch, where you had, bool efi_poweroff_reqired(voi) { return acpi_gbl_reduced_hardware || acpi_no_s5; } since you've already explained that this change won't break legacy platforms that are missing _S5 (if any even exist in the wild). -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
