From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Fleming Subject: Re: [PATCH 03/11] efi: Refactor efi_memmap_init_early() into arch-neutral code Date: Mon, 4 Jul 2016 13:19:52 +0100 Message-ID: <20160704121952.GK8415@codeblueprint.co.uk> References: <1466681690-5850-1-git-send-email-matt@codeblueprint.co.uk> <1466681690-5850-4-git-send-email-matt@codeblueprint.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ard Biesheuvel Cc: Dave Young , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Leif Lindholm , Peter Jones , Borislav Petkov , Mark Rutland List-Id: linux-efi@vger.kernel.org On Fri, 24 Jun, at 01:44:48PM, Ard Biesheuvel wrote: > > This assignment breaks the calculation of mapsize in > arm_enable_runtime_services(), so you should probably fold the > following hunk into this patch. > > diff --git a/drivers/firmware/efi/arm-runtime.c > b/drivers/firmware/efi/arm-runtime.c > index ce1424672d89..1884347a3ef6 100644 > --- a/drivers/firmware/efi/arm-runtime.c > +++ b/drivers/firmware/efi/arm-runtime.c > @@ -109,7 +109,7 @@ static int __init arm_enable_runtime_services(void) > > pr_info("Remapping and enabling EFI services.\n"); > > - mapsize = efi.memmap.map_end - efi.memmap.map; > + mapsize = efi.memmap.desc_size * efi.memmap.nr_map; > > if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { > pr_err("Failed to remap EFI memory map\n"); Thanks Ard, I folded this in. > With that change (or an equivalent one): > > Tested-by: Ard Biesheuvel > Reviewed-by: Ard Biesheuvel Are those tags for just this patch or the entire series? FYI, my plan right now is to queue this for v4.9 because it's fairly invasive and I expect some fallout. If anyone has a problem with that and knows of a reason it should be queued sooner, please let me know. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753598AbcGDMT6 (ORCPT ); Mon, 4 Jul 2016 08:19:58 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:37950 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753427AbcGDMTz (ORCPT ); Mon, 4 Jul 2016 08:19:55 -0400 Date: Mon, 4 Jul 2016 13:19:52 +0100 From: Matt Fleming To: Ard Biesheuvel Cc: Dave Young , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , Leif Lindholm , Peter Jones , Borislav Petkov , Mark Rutland Subject: Re: [PATCH 03/11] efi: Refactor efi_memmap_init_early() into arch-neutral code Message-ID: <20160704121952.GK8415@codeblueprint.co.uk> References: <1466681690-5850-1-git-send-email-matt@codeblueprint.co.uk> <1466681690-5850-4-git-send-email-matt@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 24 Jun, at 01:44:48PM, Ard Biesheuvel wrote: > > This assignment breaks the calculation of mapsize in > arm_enable_runtime_services(), so you should probably fold the > following hunk into this patch. > > diff --git a/drivers/firmware/efi/arm-runtime.c > b/drivers/firmware/efi/arm-runtime.c > index ce1424672d89..1884347a3ef6 100644 > --- a/drivers/firmware/efi/arm-runtime.c > +++ b/drivers/firmware/efi/arm-runtime.c > @@ -109,7 +109,7 @@ static int __init arm_enable_runtime_services(void) > > pr_info("Remapping and enabling EFI services.\n"); > > - mapsize = efi.memmap.map_end - efi.memmap.map; > + mapsize = efi.memmap.desc_size * efi.memmap.nr_map; > > if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { > pr_err("Failed to remap EFI memory map\n"); Thanks Ard, I folded this in. > With that change (or an equivalent one): > > Tested-by: Ard Biesheuvel > Reviewed-by: Ard Biesheuvel Are those tags for just this patch or the entire series? FYI, my plan right now is to queue this for v4.9 because it's fairly invasive and I expect some fallout. If anyone has a problem with that and knows of a reason it should be queued sooner, please let me know.