[PATCH 2/2] efi/arm64: use UEFI for system reset

[Catalin Marinas]

On Fri, Aug 29, 2014 at 05:12:48PM +0100, Ard Biesheuvel wrote:
> On 29 August 2014 18:04, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Aug 29, 2014 at 04:05:57PM +0100, Ard Biesheuvel wrote:
> >> 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.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  arch/arm64/kernel/process.c | 7 +++++++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> >> index 1309d64aa926..335a93da5eeb 100644
> >> --- a/arch/arm64/kernel/process.c
> >> +++ b/arch/arm64/kernel/process.c
> >> @@ -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).
> >
> 
> 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?

> 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()

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).

-- 
Catalin