[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu_zjJ08HwwrtL5Mqd5AzHTVwDG2VxJv2DdX1+Jk8vyuow@mail.gmail.com>
Date: Wed, 13 Apr 2016 10:12:56 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Matt Fleming <matt@...eblueprint.co.uk>
Cc: "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tony Luck <tony.luck@...il.com>,
"Luck, Tony" <tony.luck@...el.com>
Subject: Re: [PATCH 2/2] efi: Remove global 'memmap'
On 12 April 2016 at 22:01, Matt Fleming <matt@...eblueprint.co.uk> wrote:
> On Mon, 11 Apr, at 03:17:55PM, Ard Biesheuvel wrote:
>> > diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
>> > index 1cfbfaf57a2d..0416d5d33e74 100644
>> > --- a/drivers/firmware/efi/arm-runtime.c
>> > +++ b/drivers/firmware/efi/arm-runtime.c
>> > @@ -89,6 +89,7 @@ static bool __init efi_virtmap_init(void)
>> > */
>> > static int __init arm_enable_runtime_services(void)
>> > {
>> > + phys_addr_t phys_map;
>>
>> Is the sole purpose of this variable to prevent breaking the 80-column rule?
>
> Indeed it is.
>
>> If so, please be aware that I intend to propose a patch that replaces
>> the ioremap_cache() below with a call to memremap(), but this is
>> another change that is gated by Russell merging my memremap patches
>> for ARM
>
> OK. Would you like me to drop this particular hunk and just go with,
>
> efi.memmap.map = (__force void *)ioremap_cache(efi.memmap.phys_map,
> mapsize);
>
> if you're going to rewrite it soon anyway?
Yes, please. Russell seems to be dragging his feet a bit, but I should
still be able to get that patch out in time for v4.7 (and the memattr
stuff for ARM relies on it anyway)
Powered by blists - more mailing lists