efi/arm64: use UEFI for system poweroff
PATCH 1/2 efi/arm64: use UEFI for system poweroff
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to power down the system.
Enable the existing efi_reboot() code by supplying a definition of efi_poweroff_required() that returns true.
--- arch/arm64/kernel/efi.c | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arm64/kernel/efi.c +8 -0
@@ -475,3 +475,11 @@ err_unmap:return -1 ; }early_initcall (arm64_enter_virtual_mode); + +/* +* Override the weak definition in drivers/firmware/efi/reboot.c +*/ +bool efi_poweroff_required (void ) +{ +return true; +}
Signature · 1 line
1.8.3.2
PATCH 2/2 efi/arm64: use UEFI for system reset
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into machine_restart(), as the arm_pm_restart function pointer may be overwritten by modules.
--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm64/kernel/process.c +7 -0
@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop (); +/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ +if (IS_ENABLED (CONFIG_EFI ) &&efi_enabled (EFI_RUNTIME_SERVICES )) +efi_reboot (REBOOT_WARM ,NULL ); +/* Now call the architecture specific reboot code. */ if (arm_pm_restart)arm_pm_restart (reboot_mode, cmd);
Signature · 1 line
1.8.3.2
PATCH 2/2 efi/arm64: use UEFI for system reset
arch/arm64/kernel/process.c
Quoted 15 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0
I get:
arch/arm64/kernel/process.c: In function ?machine_restart?:
arch/arm64/kernel/process.c:188:2: error: implicit declaration of function ?efi_reboot?
unless I add
#include <linux/efi.h>
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 184
Quoted 9 lines
arch/arm64/kernel/process.c +5
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop (); +/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ +if (IS_ENABLED (CONFIG_EFI ) &&efi_enabled (EFI_RUNTIME_SERVICES ))
This test isn't necessary.
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 185
Quoted 1 line
arch/arm64/kernel/process.c +1
-0+efi_reboot (REBOOT_WARM ,NULL );
Why not pass reboot_mode instead?
Quoted 4 lines
arch/arm64/kernel/process.c +1
-0+/* Now call the architecture specific reboot code. */ if (arm_pm_restart)arm_pm_restart (reboot_mode, cmd);
Catalin Marinas
maintainerPATCH 2/2 efi/arm64: use UEFI for system reset
In reply to Ard BiesheuvelQuoted 16 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 183
Quoted 7 lines
arch/arm64/kernel/process.c +4
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop (); +/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/
Why do you make this the preferred method? Is there a risk that UEFI is broken and we want to override it with a SoC-specific driver (I wouldn't like it but it's still an option).
There are also some patches here that try to get rid of arm_pm_restart:
https://lkml.org/lkml/2014/8/19/665
Once there are no drivers for arm64 setting arm_pm_restart explicitly I'll remove it.
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 184
Quoted 1 line
arch/arm64/kernel/process.c +1
-0+if (IS_ENABLED (CONFIG_EFI ) &&efi_enabled (EFI_RUNTIME_SERVICES ))
efi_enabled always returns false if !IS_ENABLED(CONFIG_EFI).
Quoted 9 lines
arch/arm64/kernel/process.c +2
-0+efi_reboot (REBOOT_WARM ,NULL ); +/* Now call the architecture specific reboot code. */ if (arm_pm_restart)arm_pm_restart (reboot_mode, cmd);Signature · 1 line
1.8.3.2
Signature · 1 line
Catalin
PATCH 2/2 efi/arm64: use UEFI for system reset
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop ();
Quoted 9 lines
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 183
Quoted 4 lines
arch/arm64/kernel/process.c +4
-0+/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ Why do you make this the preferred method? Is there a risk that UEFI is broken and we want to override it with a SoC-specific driver (I wouldn't like it but it's still an option).
For poweroff (the other patch), it may not make a huge difference, but the SBBR does state it explicitly.
For reboot, we *have* to use EFI reboot in order to support capsules:
when using capsules (for instance, for updating the firmware), you need to use EFI reboot as you need to pass the return code of UpdateCapsule() (a runtime service) to ResetSystem()
Quoted 7 lines
There are also some patches here that try to get rid of
arm_pm_restart:https://lkml.org/lkml/2014/8/19/665
Once there are no drivers for arm64 setting
arm_pm_restartexplicitly I'll remove it.
OK, good to know. I will revisit this once that stuff is in.
Signature · 1 line
Ard.
Quoted 16 lines
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 184
Quoted 1 line
arch/arm64/kernel/process.c +1
-0+if (IS_ENABLED (CONFIG_EFI ) &&efi_enabled (EFI_RUNTIME_SERVICES ))
efi_enabledalways returns false if !IS_ENABLED(CONFIG_EFI).Quoted 9 lines
arch/arm64/kernel/process.c +2
-1+efi_reboot (REBOOT_WARM ,NULL ); +/* Now call the architecture specific reboot code. */ if (arm_pm_restart)arm_pm_restart (reboot_mode, cmd); --1.8.3.2
--
Catalin
Catalin Marinas
maintainerPATCH 2/2 efi/arm64: use UEFI for system reset
Quoted 31 lines · Ard Biesheuvel
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop ();Quoted 9 lines
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 183
Quoted 4 lines
arch/arm64/kernel/process.c +4
-0+/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ Why do you make this the preferred method? Is there a risk that UEFI is broken and we want to override it with a SoC-specific driver (I wouldn't like it but it's still an option).
Quoted 2 lines
For poweroff (the other patch), it may not make a huge difference, but the SBBR does state it explicitly.
The SBBR scope reads like this:
This document defines the boot and Runtime Services that are expected by an enterprise platform Operating System or hypervisor, for an ARM AArch64 server, which is SBSA-compliant and follows the UEFI and ACPI specifications.
Which means that it does not apply to non-SBSA or SBSA systems that use UEFI but not ACPI?
Quoted 4 lines
For reboot, we *have* to use EFI reboot in order to support capsules:
when using capsules (for instance, for updating the firmware), you need to use EFI reboot as you need to pass the return code ofUpdateCapsule()(a runtime service) toResetSystem()
That's a better argument ;). But I think with the restart patches you could set some priority and if absolutely needed on a platform as workaround we could register a driver with a higher priority (and losing the above features).
Signature · 1 line
Catalin
PATCH 2/2 efi/arm64: use UEFI for system reset
Quoted 37 lines · Catalin Marinas
Quoted 31 lines · Ard Biesheuvel
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop ();Quoted 9 lines
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 183
Quoted 4 lines
arch/arm64/kernel/process.c +4
-0+/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ Why do you make this the preferred method? Is there a risk that UEFI is broken and we want to override it with a SoC-specific driver (I wouldn't like it but it's still an option).
Quoted 2 lines
For poweroff (the other patch), it may not make a huge difference, but the SBBR does state it explicitly.
The SBBR scope reads like this:
Quoted 8 lines
This document defines the boot and Runtime Services that are expected by an enterprise platform Operating System or hypervisor, for an ARM AArch64 server, which is SBSA-compliant and follows the UEFI and ACPI specifications.
Which means that it does not apply to non-SBSA or SBSA systems that use UEFI but not ACPI?
Good question.
Quoted 10 lines
Quoted 4 lines
For reboot, we *have* to use EFI reboot in order to support capsules:
when using capsules (for instance, for updating the firmware), you need to use EFI reboot as you need to pass the return code ofUpdateCapsule()(a runtime service) toResetSystem()That's a better argument ;). But I think with the restart patches you could set some priority and if absolutely needed on a platform as workaround we could register a driver with a higher priority (and losing the above features).
I will wait for those patches to land then.
Signature · 1 line
Ard.
PATCH 2/2 efi/arm64: use UEFI for system reset
In reply to Catalin MarinasQuoted 5 lines · Catalin Marinas
Quoted 2 lines
For poweroff (the other patch), it may not make a huge difference, but the SBBR does state it explicitly.
The SBBR scope reads like this:
Quoted 7 lines
This document defines the boot and Runtime Services that are expected by an enterprise platform Operating System or hypervisor, for an ARM AArch64 server, which is SBSA-compliant and follows the UEFI and ACPI specifications.
Which means that it does not apply to non-SBSA or SBSA systems that use UEFI but not ACPI?
It applies to all UEFI systems, really. But the SBBR explicitly enumerates certain features already covered by the spec, to reduce risk of misinterpretation (i.e. not reading the whole UEFI spec when implementing).
Quoted 9 lines
Quoted 4 lines
For reboot, we *have* to use EFI reboot in order to support capsules:
when using capsules (for instance, for updating the firmware), you need to use EFI reboot as you need to pass the return code ofUpdateCapsule()(a runtime service) toResetSystem()That's a better argument ;). But I think with the restart patches you could set some priority and if absolutely needed on a platform as workaround we could register a driver with a higher priority (and losing the above features).
That sounds sensible to me.
But the kernel should probably be very noisy on the console if that override was done. And we would also want to store that fact somwehere, to prevent any capsule runtime service calls being made.
/
Leif
Mark Rutland
reviewerPATCH 2/2 efi/arm64: use UEFI for system reset
In reply to Ard BiesheuvelQuoted 31 lines · Ard Biesheuvel
Quoted 20 lines · Catalin Marinas
Quoted 19 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +0
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop ();Quoted 9 lines
arch/arm64/kernel/process.c void machine_restart(char *cmd) · line 183
Quoted 4 lines
arch/arm64/kernel/process.c +4
-0+/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ Why do you make this the preferred method? Is there a risk that UEFI is broken and we want to override it with a SoC-specific driver (I wouldn't like it but it's still an option).
Quoted 7 lines
For poweroff (the other patch), it may not make a huge difference, but the SBBR does state it explicitly.
For reboot, we *have* to use EFI reboot in order to support capsules:
when using capsules (for instance, for updating the firmware), you need to use EFI reboot as you need to pass the return code ofUpdateCapsule()(a runtime service) toResetSystem()
Ah. Could you drop that in the commit message next time around? That's a far clearer (and stronger) argument than saying that the runtime services are preferred.
Cheers,
Mark.
Mark Rutland
reviewerPATCH 2/2 efi/arm64: use UEFI for system reset
In reply to Ard BiesheuvelHi Ard,
Quoted 5 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to reset the system.
For the reset case, we need to hook into
machine_restart(), as thearm_pm_restartfunction pointer may be overwritten by modules.
This is changing with the restart handler callchain series [1]. I think you need to rework this atop of that.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280519.html
Quoted 33 lines
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/process.c | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm64/kernel/process.c +7
-0@@ -177,6 +177,13 @@ void machine_restart(char *cmd)local_irq_disable ();smp_send_stop (); +/* +* arm_pm_restart is exported to modules, so the only way to supersede +* it with efi_reboot() is to call it here. +*/ +if (IS_ENABLED (CONFIG_EFI ) &&efi_enabled (EFI_RUNTIME_SERVICES )) +efi_reboot (REBOOT_WARM ,NULL ); +/* Now call the architecture specific reboot code. */ if (arm_pm_restart)arm_pm_restart (reboot_mode, cmd);Signature · 7 lines
1.8.3.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Mark Rutland
reviewerPATCH 1/2 efi/arm64: use UEFI for system poweroff
In reply to Ard BiesheuvelHi Ard,
Quoted 2 lines · Ard Biesheuvel
If UEFI Runtime Services are available, they are preferred over direct PSCI calls or other methods to power down the system.
Could you elaborate on why they should be preferred?
Mark.
Quoted 33 lines
Enable the existing
efi_reboot()code by supplying a definition ofefi_poweroff_required()that returns true.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/kernel/efi.c | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/kernel/efi.c +8
-0@@ -475,3 +475,11 @@ err_unmap:return -1 ; }early_initcall (arm64_enter_virtual_mode); + +/* +* Override the weak definition in drivers/firmware/efi/reboot.c +*/ +bool efi_poweroff_required (void ) +{ +return true; +}Signature · 7 lines
1.8.3.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel