public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Salter <msalter@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: support reboot and power off via EFI runtime
Date: Wed, 18 Jun 2014 09:52:05 -0400	[thread overview]
Message-ID: <1403099525.32688.28.camel@deneb.redhat.com> (raw)
In-Reply-To: <20140618132623.GF26461@leverpostej>

On Wed, 2014-06-18 at 14:26 +0100, Mark Rutland wrote:
> Hi Mark,
> 
> On Tue, Jun 17, 2014 at 05:45:14PM +0100, Mark Salter wrote:
> > Add handlers for arm_pm_resestart and pm_power_off which use EFI
> > runtime services ResetSystem call to perform the functions. These
> > handlers are only installed if no handler currently exists. This
> > allows PSCI to take priority over EFI for these functions.
> > 
> > Signed-off-by: Mark Salter <msalter@redhat.com>
> > ---
> >  arch/arm64/kernel/efi.c | 40 ++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 40 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> > index 14db1f6..e8c0476 100644
> > --- a/arch/arm64/kernel/efi.c
> > +++ b/arch/arm64/kernel/efi.c
> > @@ -19,11 +19,14 @@
> >  #include <linux/of_fdt.h>
> >  #include <linux/sched.h>
> >  #include <linux/slab.h>
> > +#include <linux/reboot.h>
> > +#include <linux/pm.h>
> >  
> >  #include <asm/cacheflush.h>
> >  #include <asm/efi.h>
> >  #include <asm/tlbflush.h>
> >  #include <asm/mmu_context.h>
> > +#include <asm/system_misc.h>
> >  
> >  struct efi_memory_map memmap;
> >  
> > @@ -467,3 +470,40 @@ static int __init arm64_enter_virtual_mode(void)
> >  	return 0;
> >  }
> >  early_initcall(arm64_enter_virtual_mode);
> > +
> > +static void efi_restart(enum reboot_mode reboot_mode, const char *cmd)
> > +{
> > +	int efi_mode;
> > +
> > +	switch (reboot_mode) {
> > +	case REBOOT_WARM:
> > +	case REBOOT_SOFT:
> > +		efi_mode = EFI_RESET_WARM;
> > +		break;
> > +	default:
> > +		efi_mode = EFI_RESET_COLD;
> > +		break;
> > +	}
> > +	efi.reset_system(efi_mode, 0, 0, NULL);
> > +}
> > +
> > +static void efi_power_off(void)
> > +{
> > +	efi.reset_system(EFI_RESET_SHUTDOWN, 0, 0, NULL);
> > +}
> > +
> > +static int __init setup_efi_reset(void)
> > +{
> > +	if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > +		/*
> > +		 * If something (psci, etc) hasn't already registered
> > +		 * a handler, use EFI.
> > +		 */
> > +		if (arm_pm_restart == NULL)
> > +			arm_pm_restart = efi_restart;
> > +		if (pm_power_off == NULL)
> > +			pm_power_off = efi_power_off;
> > +	}
> > +	return 0;
> > +}
> > +pure_initcall(setup_efi_reset);
> 
> This doesn't seem to match the definition of a pure initcall, given that
> it depends on the state of EFI runtime services and
> arm_{pm_restart,power_off}.
> 
> Is there any reason this needs to run so early? Can this not be
> called later, when we have more of a guarantee of other reboot /
> shutdown mechanisms having been registered?
> 

I used pure_initcall because that was the earliest EFI runtime services
would be available (runtime services set up with early_initcall). I was
thinking this was after psci would have a chance to set handlers and
other hw specific drivers could come later and override. But now that
you mention it, there is no reason this couldn't come much later in boot
so that the EFI handlers are a last resort.



  reply	other threads:[~2014-06-18 13:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 16:45 [PATCH] arm64: support reboot and power off via EFI runtime Mark Salter
2014-06-18 13:26 ` Mark Rutland
2014-06-18 13:52   ` Mark Salter [this message]
2014-06-18 14:09 ` Rob Herring
2014-06-18 14:41   ` Mark Salter
2014-06-18 15:53     ` Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1403099525.32688.28.camel@deneb.redhat.com \
    --to=msalter@redhat.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox