* [PATCH v2 1/7] arm64: efistub: drop __init annotation from handle_kernel_image()
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 ` 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
` (7 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
After moving arm64-stub.c to libstub/, all of its sections are emitted
as .init.xxx sections automatically, and the __init annotation of
handle_kernel_image() causes it to end up in .init.init.text, which is
not recognized as an __init section by the linker scripts. So drop the
annotation.
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm64-stub.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 78dfbd34b6bf..9e0342745e4f 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -13,13 +13,13 @@
#include <asm/efi.h>
#include <asm/sections.h>
-efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
- unsigned long *image_addr,
- unsigned long *image_size,
- unsigned long *reserve_addr,
- unsigned long *reserve_size,
- unsigned long dram_base,
- efi_loaded_image_t *image)
+efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
+ unsigned long *image_addr,
+ unsigned long *image_size,
+ unsigned long *reserve_addr,
+ unsigned long *reserve_size,
+ unsigned long dram_base,
+ efi_loaded_image_t *image)
{
efi_status_t status;
unsigned long kernel_size, kernel_memsize = 0;
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 2/7] arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
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 ` Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 3/7] efi: efistub: prevent __init annotations from being used Ard Biesheuvel
` (6 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
The EFI stub is typically built into the decompressor (x86, ARM) so none
of its symbols are annotated as __init. However, on arm64, the stub is
linked into the kernel proper, and the code is __init annotated at the
section level by prepending all names of SHF_ALLOC sections with '.init'.
This results in section names like .init.rodata.str1.8 (for string literals)
and .init.bss (which is tiny), both of which can be moved into the .init.data
output section.
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e3928f578891..cbf4db440e9c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -134,6 +134,7 @@ SECTIONS
CON_INITCALL
SECURITY_INITCALL
INIT_RAM_FS
+ *(.init.rodata.* .init.bss) /* from the EFI stub */
}
.exit.data : {
ARM_EXIT_KEEP(EXIT_DATA)
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 3/7] efi: efistub: prevent __init annotations from being used
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 ` Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 4/7] efi: arm-init: use read-only early mappings Ard Biesheuvel
` (5 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
__init annotations should not be used in the EFI stub, since the code is
either included in the decompressor (x86, ARM) where they have no effect,
or the whole stub is __init annotated at the section level (arm64), by
renaming the sections, in which case the __init annotations will be
redundant, and will result in section names like .init.init.text, and our
linker script does not expect that. So un-#define __init so that its
inadvertent use will force a build error.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/efistub.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548fda089..275f395c886d 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -5,6 +5,16 @@
/* error code which can't be mistaken for valid address */
#define EFI_ERROR (~0UL)
+/*
+ * __init annotations should not be used in the EFI stub, since the code is
+ * either included in the decompressor (x86, ARM) where they have no effect,
+ * or the whole stub is __init annotated at the section level (arm64), by
+ * renaming the sections, in which case the __init annotation will be
+ * redundant, and will result in section names like .init.init.text, and our
+ * linker script does not expect that.
+ */
+#undef __init
+
void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 4/7] efi: arm-init: use read-only early mappings
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (2 preceding siblings ...)
2016-02-04 15:50 ` [PATCH v2 3/7] efi: efistub: prevent __init annotations from being used Ard Biesheuvel
@ 2016-02-04 15:50 ` Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 5/7] ARM: efistub: check for LPAE support before booting a LPAE kernel Ard Biesheuvel
` (4 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
The early mappings of the EFI system table contents and the UEFI memory
map are read-only from the OS point of view. So map them read-only to
protect them from inadvertent modification.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/arm-init.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..aa1f743152a2 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -61,8 +61,8 @@ static int __init uefi_init(void)
char vendor[100] = "unknown";
int i, retval;
- efi.systab = early_memremap(efi_system_table,
- sizeof(efi_system_table_t));
+ efi.systab = early_memremap_ro(efi_system_table,
+ sizeof(efi_system_table_t));
if (efi.systab == NULL) {
pr_warn("Unable to map EFI system table.\n");
return -ENOMEM;
@@ -86,8 +86,8 @@ static int __init uefi_init(void)
efi.systab->hdr.revision & 0xffff);
/* Show what we know for posterity */
- c16 = early_memremap(efi_to_phys(efi.systab->fw_vendor),
- sizeof(vendor) * sizeof(efi_char16_t));
+ c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
+ sizeof(vendor) * sizeof(efi_char16_t));
if (c16) {
for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i)
vendor[i] = c16[i];
@@ -100,8 +100,8 @@ static int __init uefi_init(void)
efi.systab->hdr.revision & 0xffff, vendor);
table_size = sizeof(efi_config_table_64_t) * efi.systab->nr_tables;
- config_tables = early_memremap(efi_to_phys(efi.systab->tables),
- table_size);
+ config_tables = early_memremap_ro(efi_to_phys(efi.systab->tables),
+ table_size);
if (config_tables == NULL) {
pr_warn("Unable to map EFI config table array.\n");
retval = -ENOMEM;
@@ -185,7 +185,7 @@ void __init efi_init(void)
efi_system_table = params.system_table;
memmap.phys_map = params.mmap;
- memmap.map = early_memremap(params.mmap, params.mmap_size);
+ memmap.map = early_memremap_ro(params.mmap, params.mmap_size);
if (memmap.map == NULL) {
/*
* If we are booting via UEFI, the UEFI memory map is the only
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 5/7] ARM: efistub: check for LPAE support before booting a LPAE kernel
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (3 preceding siblings ...)
2016-02-04 15:50 ` [PATCH v2 4/7] efi: arm-init: use read-only early mappings Ard Biesheuvel
@ 2016-02-04 15:50 ` 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
` (3 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
A kernel built with support for LPAE cannot boot to a state where it
can inform the user about it if it fails due to missing LPAE support
in the hardware.
If we happen to be booting via UEFI, we can fail gracefully so check
for LPAE support in the hardware on CONFIG_ARM_LPAE builds before
entering the kernel proper.
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm32-stub.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
index 495ebd657e38..6f42be4d0084 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -9,6 +9,23 @@
#include <linux/efi.h>
#include <asm/efi.h>
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+ int block;
+
+ /* non-LPAE kernels can run anywhere */
+ if (!IS_ENABLED(CONFIG_ARM_LPAE))
+ return EFI_SUCCESS;
+
+ /* LPAE kernels need compatible hardware */
+ block = cpuid_feature_extract(CPUID_EXT_MMFR0, 0);
+ if (block < 5) {
+ pr_efi_err(sys_table_arg, "This LPAE kernel is not supported by your CPU\n");
+ return EFI_UNSUPPORTED;
+ }
+ return EFI_SUCCESS;
+}
+
efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
unsigned long *image_addr,
unsigned long *image_size,
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 6/7] arm64: efistub: check for h/w support before booting a >4 KB granule kernel
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (4 preceding siblings ...)
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 ` Ard Biesheuvel
2016-02-04 15:50 ` [PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility check Ard Biesheuvel
` (2 subsequent siblings)
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
A kernel built with support for a page size that is not supported by the
hardware it runs on cannot boot to a state where it can inform the user
about it.
If we happen to be booting via UEFI, we can fail gracefully so check
if the currently configured page size is supported by the hardware before
entering the kernel proper. Note that UEFI mandates support for 4 KB pages,
so in that case, no check is needed.
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm64-stub.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 9e0342745e4f..aef04ad60e0d 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -12,6 +12,26 @@
#include <linux/efi.h>
#include <asm/efi.h>
#include <asm/sections.h>
+#include <asm/sysreg.h>
+
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+ u64 tg;
+
+ /* UEFI mandates support for 4 KB granule, no need to check */
+ if (IS_ENABLED(CONFIG_ARM64_4K_PAGES))
+ return EFI_SUCCESS;
+
+ tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf;
+ if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+ if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
+ pr_efi_err(sys_table_arg, "This 64 KB granule kernel is not supported by your CPU\n");
+ else
+ pr_efi_err(sys_table_arg, "This 16 KB granule kernel is not supported by your CPU\n");
+ return EFI_UNSUPPORTED;
+ }
+ return EFI_SUCCESS;
+}
efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
unsigned long *image_addr,
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility check
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (5 preceding siblings ...)
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 ` 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
8 siblings, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
Before proceeding with relocating the kernel and parsing the command line,
insert a call to check_platform_features() to allow an arch specific check
to be performed whether the current kernel can execute on the current
hardware.
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm-stub.c | 4 ++++
drivers/firmware/efi/libstub/efistub.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 3397902e4040..6086a874fa3c 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -190,6 +190,10 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
pr_efi(sys_table, "Booting Linux Kernel...\n");
+ status = check_platform_features(sys_table);
+ if (status != EFI_SUCCESS)
+ goto fail;
+
/*
* Get a handle to the loaded image protocol. This is used to get
* information about the running image, such as size and the command
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 275f395c886d..a25ac4c7955f 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -53,4 +53,6 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
unsigned long desc_size, efi_memory_desc_t *runtime_map,
int *count);
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (6 preceding siblings ...)
2016-02-04 15:50 ` [PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility check Ard Biesheuvel
@ 2016-02-04 16:13 ` Mark Rutland
2016-02-11 16:16 ` Matt Fleming
8 siblings, 0 replies; 13+ messages in thread
From: Mark Rutland @ 2016-02-04 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 04, 2016 at 04:50:23PM +0100, Ard Biesheuvel wrote:
> Ard Biesheuvel (7):
> arm64: efistub: drop __init annotation from handle_kernel_image()
> arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
> efi: efistub: prevent __init annotations from being used
> efi: arm-init: use read-only early mappings
> ARM: efistub: check for LPAE support before booting a LPAE kernel
> arm64: efistub: check for h/w support before booting a >4 KB granule
> kernel
> ARM/arm64: efistub: perform hardware compatibility check
This all looks good to be, so FWIW, for the series:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
2016-02-04 15:50 [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks Ard Biesheuvel
` (7 preceding siblings ...)
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
8 siblings, 1 reply; 13+ messages in thread
From: Matt Fleming @ 2016-02-11 16:16 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
2016-02-11 16:16 ` Matt Fleming
@ 2016-02-11 16:18 ` Ard Biesheuvel
2016-02-11 16:29 ` Matt Fleming
0 siblings, 1 reply; 13+ messages in thread
From: Ard Biesheuvel @ 2016-02-11 16:18 UTC (permalink / raw)
To: linux-arm-kernel
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.
Thanks,
Ard.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
2016-02-11 16:18 ` Ard Biesheuvel
@ 2016-02-11 16:29 ` Matt Fleming
2016-02-11 16:32 ` Will Deacon
0 siblings, 1 reply; 13+ messages in thread
From: Matt Fleming @ 2016-02-11 16:29 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
2016-02-11 16:29 ` Matt Fleming
@ 2016-02-11 16:32 ` Will Deacon
0 siblings, 0 replies; 13+ messages in thread
From: Will Deacon @ 2016-02-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 11, 2016 at 04:29:20PM +0000, Matt Fleming wrote:
> 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.
No complaints here (the arm64 bits are all acked).
Will
^ permalink raw reply [flat|nested] 13+ messages in thread