From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied
Date: Tue, 09 Sep 2014 15:39:38 -0400 [thread overview]
Message-ID: <540F577A.4040709@redhat.com> (raw)
In-Reply-To: <20140820173528.GH21734@leverpostej>
On 08/20/2014 01:35 PM, Mark Rutland wrote:
> On Wed, Aug 20, 2014 at 06:10:57PM +0100, Matt Fleming wrote:
>> On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote:
>>> On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
>>>> If we cannot relocate the kernel Image to its preferred offset of base of DRAM
>>>> plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
>>>> TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
>>>> proceed normally otherwise.
>>>>
>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>
>> Ard, who's picking this up?
>
> Will's already taken this into arm64/devel [1,2] with the intention of
> waiting for v3.18 [3]. Per Leif's comment [4] that might have to be
> bumped.
So what's the plan with this series? Waiting for 3.18? The problem is
that this patch series needs to be pulled for any platform with an EFI
firmware located at DRAM base (e.g. AMD Seattle) as was noted before.
Jon.
next prev parent reply other threads:[~2014-09-09 19:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 10:59 [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling Ard Biesheuvel
2014-07-30 10:59 ` [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Ard Biesheuvel
2014-07-30 11:30 ` Will Deacon
2014-07-30 12:00 ` Ard Biesheuvel
2014-07-30 12:05 ` Ard Biesheuvel
2014-07-30 12:30 ` Mark Rutland
2014-07-30 12:42 ` Will Deacon
2014-07-30 12:49 ` Mark Rutland
2014-07-30 13:10 ` Ard Biesheuvel
2014-07-30 13:28 ` Ard Biesheuvel
2014-07-30 19:17 ` Ard Biesheuvel
2014-07-31 9:45 ` Will Deacon
2014-07-31 9:58 ` Mark Rutland
2014-07-31 10:04 ` Will Deacon
2014-07-31 10:16 ` Ard Biesheuvel
2014-07-31 10:39 ` Mark Rutland
2014-08-01 11:35 ` Ard Biesheuvel
2014-07-31 14:41 ` Mark Salter
2014-07-31 10:01 ` Ard Biesheuvel
2014-07-30 10:59 ` [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text Ard Biesheuvel
2014-08-14 11:31 ` Mark Rutland
2014-07-30 10:59 ` [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied Ard Biesheuvel
2014-08-14 11:32 ` Mark Rutland
2014-08-20 17:10 ` Matt Fleming
2014-08-20 17:35 ` Mark Rutland
2014-08-21 8:00 ` Ard Biesheuvel
2014-08-21 9:22 ` Matt Fleming
2014-09-09 19:39 ` Jon Masters [this message]
2014-09-10 8:39 ` Will Deacon
2014-08-13 17:29 ` [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling Leif Lindholm
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=540F577A.4040709@redhat.com \
--to=jcm@redhat.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).