Build error in -next due to 'efi: Add esrt support'
Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
Guenter
PATCH 1/1 efi: Work around ia64 build problem with ESRT driver.
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'
Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
----------------------------------------------
I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have early-ioremap.h . So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.
To me this looks like a workaround - doing something like:
generic-y += early_ioremap.h
in arch/ia64/include/asm/Kbuild would appear to be more correct, but ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h , and it's a macro. So adding the above /and/ requiring that asm/io.h be included /after/ asm/early_ioremap.h in all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.
Note that I've only actually tried to build this patch on x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.
--- drivers/firmware/efi/Makefile | 5 ++++- include/linux/efi.h | 4 ++++ 2 files changed, 8 insertions(+), 1 deletion(-)
drivers/firmware/efi/Makefile +4 -1
@@ -1,7 +1,10 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o +ifeq ($(CONFIG_IA64),) +obj-$(CONFIG_EFI) += esrt.o +endif obj-$(CONFIG_EFI_VARS) += efivars.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.o
include/linux/efi.h +4 -0
@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_IA64 +static inline void efi_esrt_init (void ) { } +#else extern void __init efi_esrt_init (void ); +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );
Signature · 1 line
2.4.2
Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.
Quoted 49 lines · Peter Jones
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error:asm/early_ioremap.h: No such file or directory
----------------------------------------------I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have
early-ioremap.h. So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.To me this looks like a workaround - doing something like:
generic-y +=
early_ioremap.hin
arch/ia64/include/asm/Kbuildwould appear to be more correct, but ia64 has its ownearly_memremap()decl inarch/ia64/include/asm/io.h, and it's a macro. So adding the above /and/ requiring thatasm/io.hbe included /after/asm/early_ioremap.hin all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.Note that I've only actually tried to build this patch on
x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.Signed-off-by Peter Jones <[email protected]>--- drivers/firmware/efi/Makefile | 5 ++++- include/linux/efi.h | 4 ++++ 2 files changed, 8 insertions(+), 1 deletion(-)drivers/firmware/efi/Makefile +0
-0
drivers/firmware/efi/Makefile line 7
Quoted 8 lines
drivers/firmware/efi/Makefile +4
-1@@ -1,7 +1,10 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o +ifeq ($(CONFIG_IA64),) +obj-$(CONFIG_EFI) += esrt.o +endif
Hi Peter,
How about adding a hidden Kconfig option instead ?
config EFI_ESRT
bool
depends on !IA64
default true
Then you could use
obj-$(CONFIG_EFI_ESRT) += esrt.o
include/linux/efi.h static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon · line 882
Quoted 12 lines
drivers/firmware/efi/Makefile +0
-0obj-$(CONFIG_EFI_VARS) += efivars.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.oinclude/linux/efi.h +1
-0@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_IA64
and use CONFIG_EFI_ESRT here.
Thanks,
Guenter
Quoted 10 lines
include/linux/efi.h +3
-0+static inline void efi_esrt_init (void ) { } +#else extern void __init efi_esrt_init (void ); +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );Signature · 1 line
2.4.2
PATCH 1/1 efi: Work around ia64 build problem with ESRT driver.
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'
Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
----------------------------------------------
I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have early-ioremap.h . So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.
To me this looks like a workaround - doing something like:
generic-y += early_ioremap.h
in arch/ia64/include/asm/Kbuild would appear to be more correct, but ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h , and it's a macro. So adding the above /and/ requiring that asm/io.h be included /after/ asm/early_ioremap.h in all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.
Note that I've only actually tried to build this patch on x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.
--- drivers/firmware/efi/Kconfig | 5 +++++ drivers/firmware/efi/Makefile | 3 ++- include/linux/efi.h | 4 ++++ 3 files changed, 11 insertions(+), 1 deletion(-)
drivers/firmware/efi/Kconfig +5 -0
@@ -18,6 +18,11 @@ config EFI_VARS Subsequent efibootmgr releases may be found at: <http://github.com/vathpela/efibootmgr> +config EFI_ESRT + bool + depends on EFI && !IA64 + default true + config EFI_VARS_PSTORE tristate "Register efivars backend for pstore" depends on EFI_VARS && PSTORE
drivers/firmware/efi/Makefile +2 -1
@@ -1,8 +1,9 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o obj-$(CONFIG_EFI_VARS) += efivars.o +obj-$(CONFIG_EFI_ESRT) += esrt.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
include/linux/efi.h +4 -0
@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_EFI_ESRT extern void __init efi_esrt_init (void ); +#else +static inline void efi_esrt_init (void ) { } +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );
Signature · 1 line
2.4.2
Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.
Quoted 5 lines · Peter Jones
Note that I've only actually tried to build this patch on
x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.
This, of course, is a total lie. I'll send a reply patch in which it's actually true.
Quoted 1 line
Acked-by Tony Luck <[email protected]>
So sorry, Tony.
Signature · 1 line
Peter
PATCH 1/1 efi: Work around ia64 build problem with ESRT driver.
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'
Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error: asm/early_ioremap.h: No such file or directory
----------------------------------------------
I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have early-ioremap.h . So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.
To me this looks like a workaround - doing something like:
generic-y += early_ioremap.h
in arch/ia64/include/asm/Kbuild would appear to be more correct, but ia64 has its own early_memremap() decl in arch/ia64/include/asm/io.h , and it's a macro. So adding the above /and/ requiring that asm/io.h be included /after/ asm/early_ioremap.h in all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.
Note that I've only actually tried to build this patch on x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.
--- drivers/firmware/efi/Kconfig | 5 +++++ drivers/firmware/efi/Makefile | 3 ++- include/linux/efi.h | 4 ++++ 3 files changed, 11 insertions(+), 1 deletion(-)
drivers/firmware/efi/Kconfig +5 -0
@@ -18,6 +18,11 @@ config EFI_VARS Subsequent efibootmgr releases may be found at: <http://github.com/vathpela/efibootmgr> +config EFI_ESRT + bool + depends on EFI && !IA64 + default y + config EFI_VARS_PSTORE tristate "Register efivars backend for pstore" depends on EFI_VARS && PSTORE
drivers/firmware/efi/Makefile +2 -1
@@ -1,8 +1,9 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o obj-$(CONFIG_EFI_VARS) += efivars.o +obj-$(CONFIG_EFI_ESRT) += esrt.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
include/linux/efi.h +4 -0
@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_EFI_ESRT extern void __init efi_esrt_init (void ); +#else +static inline void efi_esrt_init (void ) { } +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );
Signature · 1 line
2.4.2
Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.
Quoted 32 lines · Peter Jones
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error:asm/early_ioremap.h: No such file or directory
----------------------------------------------I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have
early-ioremap.h. So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.To me this looks like a workaround - doing something like:
generic-y +=
early_ioremap.hin
arch/ia64/include/asm/Kbuildwould appear to be more correct, but ia64 has its ownearly_memremap()decl inarch/ia64/include/asm/io.h, and it's a macro. So adding the above /and/ requiring thatasm/io.hbe included /after/asm/early_ioremap.hin all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.
Quoted 8 lines
Note that I've only actually tried to build this patch on
x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.Signed-off-by Peter Jones <[email protected]>Acked-by Tony Luck <[email protected]>
The ia64:defconfig build passes with this patch, so
(Compile-)Tested-by: Guenter Roeck <[email protected]>
Guenter
Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.
In reply to Peter JonesQuoted 38 lines · Peter Jones
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error:asm/early_ioremap.h: No such file or directory
----------------------------------------------I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have
early-ioremap.h. So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.To me this looks like a workaround - doing something like:
generic-y +=
early_ioremap.hin
arch/ia64/include/asm/Kbuildwould appear to be more correct, but ia64 has its ownearly_memremap()decl inarch/ia64/include/asm/io.h, and it's a macro. So adding the above /and/ requiring thatasm/io.hbe included /after/asm/early_ioremap.hin all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.Note that I've only actually tried to build this patch on
x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.
Quoted 7 lines
Signed-off-by Peter Jones <[email protected]>Acked-by Tony Luck <[email protected]>--- drivers/firmware/efi/Kconfig | 5 +++++ drivers/firmware/efi/Makefile | 3 ++- include/linux/efi.h | 4 ++++ 3 files changed, 11 insertions(+), 1 deletion(-)
Thanks Peter, I picked this up with everyone's Ack/Test tags.
But now let's Cc some more people that can answer the questions you posed above, which would be the people mentioned in commit 9e5c33d7aeee ("mm: create generic early_ioremap() support").
Folks, is it legitimate to have headers in include/asm-generic/ that aren't available to all architectures? The build failure incurred by directly including asm/early_ioremap.h is noted above.
Quoted 50 lines
drivers/firmware/efi/Kconfig +5
-0@@ -18,6 +18,11 @@ config EFI_VARS Subsequent efibootmgr releases may be found at: <http://github.com/vathpela/efibootmgr> +config EFI_ESRT + bool + depends on EFI && !IA64 + default y + config EFI_VARS_PSTORE tristate "Register efivars backend for pstore" depends on EFI_VARS && PSTOREdrivers/firmware/efi/Makefile +2
-1@@ -1,8 +1,9 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o obj-$(CONFIG_EFI_VARS) += efivars.o +obj-$(CONFIG_EFI_ESRT) += esrt.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.oinclude/linux/efi.h +4
-0@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_EFI_ESRT extern void __init efi_esrt_init (void ); +#else +static inline void efi_esrt_init (void ) { } +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );Signature · 1 line
2.4.2
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Re: [PATCH] efi: Work around ia64 build problem with ESRT driver.
Quoted 49 lines · Matt Fleming
Quoted 38 lines · Peter Jones
So, I'm told this problem exists in the world:
----------------------------------------------
Subject: Build error in -next due to 'efi: Add esrt support'Building ia64:defconfig ... failed
--------------
Error log:
drivers/firmware/efi/esrt.c:28:31: fatal error:asm/early_ioremap.h: No such file or directory
----------------------------------------------I'm not really sure how it's okay that we have things in asm-generic on some platforms but not others - is having it the same everywhere not the whole point of asm-generic?
That said, ia64 doesn't have
early-ioremap.h. So instead, since it's difficult to imagine new IA64 machines with UEFI 2.5, just don't build this code there.To me this looks like a workaround - doing something like:
generic-y +=
early_ioremap.hin
arch/ia64/include/asm/Kbuildwould appear to be more correct, but ia64 has its ownearly_memremap()decl inarch/ia64/include/asm/io.h, and it's a macro. So adding the above /and/ requiring thatasm/io.hbe included /after/asm/early_ioremap.hin all cases would fix it, but that's pretty ugly as well. Since I'm not going to spend the rest of my life rectifying ia64 headers vs "generic" headers that aren't generic, it's much simpler to just not build there.Note that I've only actually tried to build this patch on
x86_64, but esrt.o still gets built there, and that would seem to demonstrate that the conditional building is working correctly at all the places the code built before. I no longer have any ia64 machines handy to test that the exclusion actually works there.Quoted 7 lines
Signed-off-by Peter Jones <[email protected]>Acked-by Tony Luck <[email protected]>--- drivers/firmware/efi/Kconfig | 5 +++++ drivers/firmware/efi/Makefile | 3 ++- include/linux/efi.h | 4 ++++ 3 files changed, 11 insertions(+), 1 deletion(-)Thanks Peter, I picked this up with everyone's Ack/Test tags.
Quoted 7 lines
But now let's Cc some more people that can answer the questions you posed above, which would be the people mentioned in commit
9e5c33d7aeee("mm: create genericearly_ioremap()support").Folks, is it legitimate to have headers in
include/asm-generic/that aren't available to all architectures? The build failure incurred by directly includingasm/early_ioremap.his noted above.
To answer generally, yes it is legitimate to have asm-generic headers which are not used by all architectures.
The intent of asm-generic/fixmap.h was to consolidate the generic bits copied by all architectures *which implemented fixmap.h* in <arch>/include/asm. Not all architecture need to involve page table mappings for fixmap-like support and fixmap makes no sense for !MMU arches.
Quoted 52 lines
Quoted 51 lines
drivers/firmware/efi/Kconfig +5
-0@@ -18,6 +18,11 @@ config EFI_VARS Subsequent efibootmgr releases may be found at: <http://github.com/vathpela/efibootmgr> +config EFI_ESRT + bool + depends on EFI && !IA64 + default y + config EFI_VARS_PSTORE tristate "Register efivars backend for pstore" depends on EFI_VARS && PSTOREdrivers/firmware/efi/Makefile +2
-1@@ -1,8 +1,9 @@ # # Makefile for linux kernel # -obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o +obj-$(CONFIG_EFI) += efi.o vars.o reboot.o obj-$(CONFIG_EFI_VARS) += efivars.o +obj-$(CONFIG_EFI_ESRT) += esrt.o obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o obj-$(CONFIG_UEFI_CPER) += cper.o obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.oinclude/linux/efi.h +4
-0@@ -879,7 +879,11 @@ static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned lon#endif extern void __iomem *efi_lookup_mapped_addr (u64 phys_addr);extern int efi_config_init (efi_config_table_type_t *arch_tables); +#ifdef CONFIG_EFI_ESRT extern void __init efi_esrt_init (void ); +#else +static inline void efi_esrt_init (void ) { } +#endif extern int efi_config_parse_tables (void *config_tables,int count,int sz,efi_config_table_type_t *arch_tables);extern u64 efi_get_iobase (void );Signature · 1 line
2.4.2
RE: [PATCH] efi: Work around ia64 build problem with ESRT driver.
In reply to Peter Jones-obj-$(CONFIG_EFI) += efi.o esrt.o vars.o reboot.o
+obj-$(CONFIG_EFI) += efi.o vars.o reboot.o
+ifeq ($(CONFIG_IA64),)
+obj-$(CONFIG_EFI) += esrt.o
+endif
I doubt that ia64 systems are going to start implementing ERST - so it's fine with me to drop it from the build.
Guenter's suggestion of a new CONFIG_EFI_ESRT looks a bit prettier that that
ifeq ($(CONFIG_IA64),)
but either way: