All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 0/5] arm/arm64: Unify PSCI client support
Date: Mon, 3 Aug 2015 15:37:03 +0100	[thread overview]
Message-ID: <20150803143703.GH10501@arm.com> (raw)
In-Reply-To: <1438353980-7611-1-git-send-email-mark.rutland@arm.com>

Hi all,

On Fri, Jul 31, 2015 at 03:46:15PM +0100, Mark Rutland wrote:
> This series unifies the 32-bit and 64-bit PSCI client code, moving the bulk of
> the FW invocation and probing out to a common location in drivers/firmware. The
> bulk of the PSCI 0.2 cleanups have hit mainline now, so this is just the
> unification portion.
> 
> This results in a reasonable saving in terms of lines of code, and will allow
> for PSCI 1.0 support to be unified form the beginning, avoiding further
> duplication.
> 
> Since v4 [1]:
> * Apply Rob Herring's ack
> * Rebase to v4.2-rc2 to handle a trivial conflict
> * Reorder the series to keep arch/arm patches together
> Since v3 [2]:
> * Drop the PSCI 0.2 patches as they're in mainline
> * s/__pa/virt_to_idmap/ from Grygorii Strashko
> * Use macros for Calxeda CPU_SUSPEND parameters
> 
> Russell, are you happy with the arch/arm patches? If so, are you happy for them
> to go via another tree, or would you prefer that I set up a stable branch for
> merging?
> 
> I was under the impression that you had already taken Grygorii's patch but I
> couldn't spot it in any branches. I can drop that if you already have it.

I've been looking at merging this, but it's a tad fiddly touching all of
arm, arm64 and drivers. One way to do it would be:

  (1) I create a branch containing patches 1,2 and 5 based on -rc2 and
      merge that into the arm64/for-next/core branch. There's a minor
      conflict, but it's easy to resolve.

  (2) I create another branch, which is just the branch merged in (1) +
      patches 3 and 4 on top. I send a pull request for that to rmk.

  (3) Torvalds will get the minor conflict resolved in (1) when he merges
      the arm and arm64 trees.

If we're not comfortable with (3), then the whole lot could go via
arm-soc instead (including the conflict resolution).

Russell, Olof, any preferences?

Will

  parent reply	other threads:[~2015-08-03 14:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 14:46 [PATCHv5 0/5] arm/arm64: Unify PSCI client support Mark Rutland
2015-07-31 14:46 ` [PATCHv5 1/5] arm64: psci: factor invocation code to drivers Mark Rutland
2015-07-31 14:46 ` [PATCHv5 2/5] drivers: psci: support native SMC{32,64} calls Mark Rutland
2015-07-31 14:46 ` [PATCHv5 3/5] ARM: psci: boot_secondary: replace __pa with virt_to_idmap Mark Rutland
2015-07-31 14:46 ` [PATCHv5 4/5] ARM: migrate to common PSCI client code Mark Rutland
2015-07-31 14:46 ` [PATCHv5 5/5] MAINTAINERS: add PSCI entry Mark Rutland
2015-08-03 14:37 ` Will Deacon [this message]
2015-08-05  7:41   ` [PATCHv5 0/5] arm/arm64: Unify PSCI client support Olof Johansson
2015-08-05 11:09     ` Will Deacon

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=20150803143703.GH10501@arm.com \
    --to=will.deacon@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.