Re: [PATCH] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

[Matt Fleming]

On Fri, 19 May, at 04:45:49PM, Ard Biesheuvel wrote:
> 
> This does not look unreasonable to me, but this is more Matt's turf so
> I will let him handle this one.

I was hoping that either Len or Rafael would have chimed in by now,
but they were probably waiting for me...

Doesn't ACPI reduced require that EFI power off be supported? I can't
find anything in the spec that makes that connection.

Unless the ACPI folks provide a reason that falling back to ACPI
poweroff doesn't make sense for ACPI reduced hardware, I think we
should apply this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

[Ard Biesheuvel]

On 23 April 2017 at 13:36, Hans de Goede  wrote:
> Commit 44be28e9dd98 ("x86/reboot: Add EFI reboot quirk for ACPI Hardware
> Reduced flag") sets pm_power_off to efi_power_off() when the
> acpi_gbl_reduced_hardware flag is set.
>
> According to its commit message this is necessary because: "BayTrail-T
> class of hardware requires EFI in order to powerdown and reboot and no
> other reliable method exists"
>
> But I have a Bay Trail CR tablet where the EFI_RESET_SHUTDOWN call does
> not work, it simply returns without doing anything (AFAICT).
>
> So it seems that some Bay Trail devices must use EFI for power-off, while
> for others only ACPI works.
>
> Note that efi_power_off() only gets used if the platform code defines
> efi_poweroff_required() and that returns true, this currently only ever
> happens on x86.
>
> Since on the devices which need ACPI for power-off the EFI_RESET_SHUTDOWN
> call simply returns, this patch makes the efi-reboot code remember the
> old pm_power_off handler and if EFI_RESET_SHUTDOWN returns it falls back
> to calling that.
>
> This seems preferable to dmi-quirking our way out of this, since there
> are likely quite a few devices suffering from this.
>
> Cc: Mark Salter 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/firmware/efi/reboot.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/reboot.c b/drivers/firmware/efi/reboot.c
> index 62ead9b..7117e2d 100644
> --- a/drivers/firmware/efi/reboot.c
> +++ b/drivers/firmware/efi/reboot.c
> @@ -5,6 +5,8 @@
>  #include 
>  #include 
>
> +void (*orig_pm_power_off)(void);
> +
>  int efi_reboot_quirk_mode = -1;
>
>  void efi_reboot(enum reboot_mode reboot_mode, const char *__unused)
> @@ -51,6 +53,12 @@ bool __weak efi_poweroff_required(void)
>  static void efi_power_off(void)
>  {
> efi.reset_system(EFI_RESET_SHUTDOWN, EFI_SUCCESS, 0, NULL);
> +   /*
> +* The above call should not return, if it does fall back to
> +* the original power off method (typically ACPI poweroff).
> +*/
> +   if (orig_pm_power_off)
> +   orig_pm_power_off();
>  }
>
>  static int __init efi_shutdown_init(void)
> @@ -58,8 +66,10 @@ static int __init efi_shutdown_init(void)
> if (!efi_enabled(EFI_RUNTIME_SERVICES))
> return -ENODEV;
>
> -   if (efi_poweroff_required())
> +   if (efi_poweroff_required()) {
> +   orig_pm_power_off = pm_power_off;
> pm_power_off = efi_power_off;
> +   }
>
> return 0;
>  }

This does not look unreasonable to me, but this is more Matt's turf so
I will let him handle this one.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] efi/reboot: Fall back to original power-off method if EFI_RESET_SHUTDOWN returns

[Hans de Goede]

Commit 44be28e9dd98 ("x86/reboot: Add EFI reboot quirk for ACPI Hardware
Reduced flag") sets pm_power_off to efi_power_off() when the
acpi_gbl_reduced_hardware flag is set.

According to its commit message this is necessary because: "BayTrail-T
class of hardware requires EFI in order to powerdown and reboot and no
other reliable method exists"

But I have a Bay Trail CR tablet where the EFI_RESET_SHUTDOWN call does
not work, it simply returns without doing anything (AFAICT).

So it seems that some Bay Trail devices must use EFI for power-off, while
for others only ACPI works.

Note that efi_power_off() only gets used if the platform code defines
efi_poweroff_required() and that returns true, this currently only ever
happens on x86.

Since on the devices which need ACPI for power-off the EFI_RESET_SHUTDOWN
call simply returns, this patch makes the efi-reboot code remember the
old pm_power_off handler and if EFI_RESET_SHUTDOWN returns it falls back
to calling that.

This seems preferable to dmi-quirking our way out of this, since there
are likely quite a few devices suffering from this.

Cc: Mark Salter 
Signed-off-by: Hans de Goede 
---
 drivers/firmware/efi/reboot.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/reboot.c b/drivers/firmware/efi/reboot.c
index 62ead9b..7117e2d 100644
--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -5,6 +5,8 @@
 #include 
 #include 
 
+void (*orig_pm_power_off)(void);
+
 int efi_reboot_quirk_mode = -1;
 
 void efi_reboot(enum reboot_mode reboot_mode, const char *__unused)
@@ -51,6 +53,12 @@ bool __weak efi_poweroff_required(void)
 static void efi_power_off(void)
 {
efi.reset_system(EFI_RESET_SHUTDOWN, EFI_SUCCESS, 0, NULL);
+   /*
+* The above call should not return, if it does fall back to
+* the original power off method (typically ACPI poweroff).
+*/
+   if (orig_pm_power_off)
+   orig_pm_power_off();
 }
 
 static int __init efi_shutdown_init(void)
@@ -58,8 +66,10 @@ static int __init efi_shutdown_init(void)
if (!efi_enabled(EFI_RUNTIME_SERVICES))
return -ENODEV;
 
-   if (efi_poweroff_required())
+   if (efi_poweroff_required()) {
+   orig_pm_power_off = pm_power_off;
pm_power_off = efi_power_off;
+   }
 
return 0;
 }
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html