From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
Date: Thu, 11 Feb 2016 16:29:20 +0000 [thread overview]
Message-ID: <20160211162920.GN4134@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu-kZrcLYhF7i0u8F2TOMqEVKp==jNoBc+Rfk61cwSkDhQ@mail.gmail.com>
On Thu, 11 Feb, at 05:18:12PM, Ard Biesheuvel wrote:
> On 11 February 2016 at 17:16, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> >> I merged two EFI/ARM related series, whose v1's I sent out last week:
> >>
> >> Changes since v1:
> >> - added various tags from various people
> >> - new patch #3 to undefine __init
> >>
> >> @Matt: are you happy with all of this going through the arm64 tree? I don't
> >> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
> >
> > How come this is going through the arm64 tree? Are there other patch
> > series that this depends on or that depend on it?
> >
> > If it makes the most sense to take it through that tree, then I'm fine
> > with it but I'd like to hear a rationale.
>
> I simply thought it would be most convenient, since it touches
> ARM-specific files only. But if you feel it should go via the EFI tree
> instead, that is also fine by me.
Since the diff stat is heavily weighted towards drivers/firmware/efi I
think it should go via the EFI tree. So I'll pick this up (the changes
look fine) unless Will or Catalin complain otherwise.
I'm also keen to allay any concerns that the EFI tree is somehow
x86-specific.
next prev parent reply other threads:[~2016-02-11 16:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 1/7] arm64: efistub: drop __init annotation from handle_kernel_image() Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 2/7] arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 3/7] efi: efistub: prevent __init annotations from being used Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 4/7] efi: arm-init: use read-only early mappings Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 5/7] ARM: efistub: check for LPAE support before booting a LPAE kernel Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 6/7] arm64: efistub: check for h/w support before booting a >4 KB granule kernel Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility check Ard Biesheuvel
2016-02-04 16:13 ` [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Mark Rutland
2016-02-11 16:16 ` Matt Fleming
2016-02-11 16:18 ` Ard Biesheuvel
2016-02-11 16:29 ` Matt Fleming [this message]
2016-02-11 16:32 ` 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=20160211162920.GN4134@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--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).