linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/10] arm64: UEFI support
Date: Tue, 29 Apr 2014 14:47:28 +0100	[thread overview]
Message-ID: <20140429134726.GH17007@arm.com> (raw)
In-Reply-To: <20140429114356.GK26088@console-pimps.org>

On Tue, Apr 29, 2014 at 12:43:56PM +0100, Matt Fleming wrote:
> (Pulling in Peter and Stephen)
> 
> On Tue, 29 Apr, at 11:28:17AM, Catalin Marinas wrote:
> > 
> > The patches look fine to me, they've been through several rounds of
> > review already. How do we propose these get merged as the series
> > contains both generic and arm64 patches? And there are dependencies
> > already in linux-next.
> > 
> > Are the EFI patches in -next pulled from some non-rebaseable branch?
> 
> Peter suggsted a plan when he took the generic EFI stuff that's in tip
> (and hence currently in linux-next),
> 
>   It doesn't hurt to inform Stephen, although I think it will simply fall
>   out automatically since he uses git to merge and git will recognize the
>   graph.
> 
>   During the merge window, it means they should not push their patches
>   until Linus has accepted the precondition patches from the tip tree.
>   Since Ingo and I try to push most of the tip tree as early as possible
>   in the merge window, this is usually not a problem.
> 
> So we currently have the prerequisites in tip/x86/efi, and assuming that
> this 10-patch series gets merged into a single branch somewhere, things
> should work automatically for linux-next.
> 
> It may be prudent to negotiate a plan now for when the merge window
> opens because, as Peter mentions above, the stuff in tip/x86/efi needs
> to be merged by Linus first to avoid build breakage with the arm64
> stuff.

Waiting for the tip/x86/efi to be merged first is not a problem. We
also need a stable base for testing the arm64 UEFI series, so I assume
this series can be based onto tip/x86/efi (would such branch be rebased
before hitting mainline?).

Given that Leif's series contains both generic efi and arm64 patches,
what's your preference for merging them? I'm happy to add my ack and
they go via your tree (or the other way around).

Thanks.

-- 
Catalin

  reply	other threads:[~2014-04-29 13:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 16:09 [PATCH v2 00/10] arm64: UEFI support Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 01/10] lib: add fdt_empty_tree.c Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 02/10] doc: efi-stub.txt updates for ARM Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 03/10] efi: add helper function to get UEFI params from FDT Leif Lindholm
2014-04-29 11:21   ` Matt Fleming
2014-04-25 16:09 ` [PATCH v2 04/10] arm64: Add function to create identity mappings Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 05/10] efi: Add shared FDT related functions for ARM/ARM64 Leif Lindholm
2014-04-29 11:24   ` Matt Fleming
2014-04-25 16:09 ` [PATCH v2 06/10] arm64: add EFI runtime services Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 07/10] doc: arm: add UEFI support documentation Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 08/10] arm64: efi: add EFI stub Leif Lindholm
2014-04-29 11:27   ` Matt Fleming
2014-04-25 16:09 ` [PATCH v2 09/10] doc: arm64: add description of EFI stub support Leif Lindholm
2014-04-25 16:09 ` [PATCH v2 10/10] efi/arm64: ignore dtb= when UEFI SecureBoot is enabled Leif Lindholm
2014-04-29 11:28   ` Matt Fleming
2014-04-29 10:28 ` [PATCH v2 00/10] arm64: UEFI support Catalin Marinas
2014-04-29 11:43   ` Matt Fleming
2014-04-29 13:47     ` Catalin Marinas [this message]
2014-04-29 14:38       ` H. Peter Anvin
2014-04-29 14:47       ` Matt Fleming
2014-04-29 14:56         ` H. Peter Anvin
2014-04-29 15:27           ` Matt Fleming
2014-04-29 16:41             ` Leif Lindholm
2014-04-29 16:35         ` Catalin Marinas
2014-04-29 14:36     ` H. Peter Anvin

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=20140429134726.GH17007@arm.com \
    --to=catalin.marinas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).