All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm: psci: don't call CPU_OFF blindly
Date: Mon, 8 Sep 2014 11:22:45 +0100	[thread overview]
Message-ID: <20140908102245.GA12081@leverpostej> (raw)
In-Reply-To: <alpine.DEB.2.02.1409052132450.2334@kaball.uk.xensource.com>

On Fri, Sep 05, 2014 at 09:48:46PM +0100, Stefano Stabellini wrote:
> On Fri, 5 Sep 2014, Mark Rutland wrote:
> > The generic PSCI operations for arm check the presence of a CPU_OFF ID
> > far too late, and in the absence of an ID will panic(), rather than
> > producing a warning.
> > 
> > This patch adds a psci_cpu_disable callback which tests the presence of
> > a CPU_OFF id. As this is called earlier than psci_cpu_die, the failure
> > can be handled gracefully without brining down the system. Additionally
> > a check is added for a UP trusted OS in the presence of PSCI 0.2+. Full
> > support will require the use of MIGRATE, but for now rejecting hotplug
> > will prevent psci_cpu_die from brining down the system.
> > 
> > The now redundant check for scpi_ops.cpu_off is removed from
> > psci_cpu_die. At the same time, the whitespace is corrected from seven
> > spaces to tabs.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Christoffer Dall <christoffer.dall@linaro.org>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> >  arch/arm/kernel/psci_smp.c | 36 +++++++++++++++++++++++++++++-------
> >  1 file changed, 29 insertions(+), 7 deletions(-)
> > 
> > Stefano, I've followed your lead with the __ref annotation here, but I couldn't
> > figure out why they exist on cpu_die and cpu_kill; it feels rather dodgy. Do
> > you know why they were added, or if they are superfluous?
> 
> I don't think that __ref is needed.
> That particular snipped of code came from Rob Herring, maybe he knows
> why it was added in the first place.

I've traced that back, but can't see any rationale. Perhaps that had
something to do with __cpuinit/__cpuexit, but there doesn't seem to be
any reason for them now. I guess the __ref annotation on cpu_die in
arch/arm/kernel/smp.c can go too given __cpuinit and __cpuexit are gone.

Rob, do you have any idea either way?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/158570.html

  reply	other threads:[~2014-09-08 10:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 11:22 [PATCH 0/2] PSCI: don't call CPU_OFF when it might fail Mark Rutland
2014-09-05 11:22 ` [PATCH 1/2] arm64: psci: respect MIGRATE_INFO_TYPE Mark Rutland
2014-09-05 11:58   ` Sergei Shtylyov
2014-09-05 12:39     ` Mark Rutland
2014-09-05 11:22 ` [PATCH 2/2] arm: psci: don't call CPU_OFF blindly Mark Rutland
2014-09-05 20:48   ` Stefano Stabellini
2014-09-08 10:22     ` Mark Rutland [this message]
2014-09-05 20:53 ` [PATCH 0/2] PSCI: don't call CPU_OFF when it might fail Stefano Stabellini
2014-09-08 10:24   ` Mark Rutland
2014-09-08 21:44     ` Stefano Stabellini

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=20140908102245.GA12081@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.