| Message ID | 170058229266.2356592.11579977558324549374.stgit@djiang5-mobl3 (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | acpi: Fix ARM32 platforms compile issue introduced by fw_table changes | expand |
On 11/21/23 07:58, Dave Jiang wrote: > Linus reported that: > After commit a103f46633fd the kernel stopped compiling for > several ARM32 platforms that I am building with a bare metal > compiler. Bare metal compilers (arm-none-eabi-) don't > define __linux__. > > This is because the header <acpi/platform/acenv.h> is now > in the include path for <linux/irq.h>: > > CC arch/arm/kernel/irq.o > CC kernel/sysctl.o > CC crypto/api.o > In file included from ../include/acpi/acpi.h:22, > from ../include/linux/fw_table.h:29, > from ../include/linux/acpi.h:18, > from ../include/linux/irqchip.h:14, > from ../arch/arm/kernel/irq.c:25: > ../include/acpi/platform/acenv.h:218:2: error: #error Unknown target environment > 218 | #error Unknown target environment > | ^~~~~ > > The issue is caused by the introducing of splitting out the ACPI code to > support the new generic fw_table code. > > Rafael suggested moving the fw_table.h include in linux/acpi.h to below > the asm/acpi.h. The move also helped with eliminating the inclusion of > acpi/acpi.h in fw_table.h. The unfortunate circular inclusion of > linux/acpi.h is needed for fw_table.h due fw_table code needing the > defined acpi structs in order to build. > > Fixes: a103f46633fd ("acpi: Move common tables helper functions to common lib") > Reported-by: Linus Walleij <linus.walleij@linaro.org> > Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Signed-off-by: Dave Jiang <dave.jiang@intel.com> > --- > include/linux/acpi.h | 23 ++++++++++++----------- > include/linux/fw_table.h | 1 - > 2 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 54189e0e5f41..2789beb26138 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -15,7 +15,6 @@ > #include <linux/mod_devicetable.h> > #include <linux/property.h> > #include <linux/uuid.h> > -#include <linux/fw_table.h> > > struct irq_domain; > struct irq_domain_ops; > @@ -25,16 +24,6 @@ struct irq_domain_ops; > #endif > #include <acpi/acpi.h> > > -#ifdef CONFIG_ACPI_TABLE_LIB > -#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) > -#define __init_or_acpilib > -#define __initdata_or_acpilib > -#else > -#define EXPORT_SYMBOL_ACPI_LIB(x) > -#define __init_or_acpilib __init > -#define __initdata_or_acpilib __initdata > -#endif > - > #ifdef CONFIG_ACPI > > #include <linux/list.h> > @@ -48,6 +37,18 @@ struct irq_domain_ops; > #include <acpi/acpi_io.h> > #include <asm/acpi.h> > > +#include <linux/fw_table.h> > + > +#ifdef CONFIG_ACPI_TABLE_LIB > +#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) > +#define __init_or_acpilib > +#define __initdata_or_acpilib > +#else > +#define EXPORT_SYMBOL_ACPI_LIB(x) > +#define __init_or_acpilib __init > +#define __initdata_or_acpilib __initdata > +#endif > + > static inline acpi_handle acpi_device_handle(struct acpi_device *adev) > { > return adev ? adev->handle : NULL; > diff --git a/include/linux/fw_table.h b/include/linux/fw_table.h > index ff8fa58d5818..a722300c215b 100644 > --- a/include/linux/fw_table.h > +++ b/include/linux/fw_table.h > @@ -26,7 +26,6 @@ struct acpi_subtable_proc { > }; > > #include <linux/acpi.h> > -#include <acpi/acpi.h> Hi Dave, Seems to me that the #include <linux/acpi.h> should go too, to break the circular including cycle. If it remains, I fear that there could be subtle problems in the future depending on which header is included first in a compilation unit. It sounds now like the only correct way to get fw_table.h included is transitively via linux/acpi.h (of note: lib/fw_table.c will have to be updated; it's the only file that currently breaks this rule) so that removal will just help enforce this. Plus, includes in the middle of non-preprocessor declarations are a (sometimes necessary, definitely not here) code smell, in my view. If this include must remain for some reason, perhaps a comment should be added to call attention to the circular situation and provide justification? Cheers, Sam > > union acpi_subtable_headers { > struct acpi_subtable_header common; > > > >
On 11/21/23 14:49, Sam Edwards wrote: > > > On 11/21/23 07:58, Dave Jiang wrote: >> Linus reported that: >> After commit a103f46633fd the kernel stopped compiling for >> several ARM32 platforms that I am building with a bare metal >> compiler. Bare metal compilers (arm-none-eabi-) don't >> define __linux__. >> >> This is because the header <acpi/platform/acenv.h> is now >> in the include path for <linux/irq.h>: >> >> CC arch/arm/kernel/irq.o >> CC kernel/sysctl.o >> CC crypto/api.o >> In file included from ../include/acpi/acpi.h:22, >> from ../include/linux/fw_table.h:29, >> from ../include/linux/acpi.h:18, >> from ../include/linux/irqchip.h:14, >> from ../arch/arm/kernel/irq.c:25: >> ../include/acpi/platform/acenv.h:218:2: error: #error Unknown target environment >> 218 | #error Unknown target environment >> | ^~~~~ >> >> The issue is caused by the introducing of splitting out the ACPI code to >> support the new generic fw_table code. >> >> Rafael suggested moving the fw_table.h include in linux/acpi.h to below >> the asm/acpi.h. The move also helped with eliminating the inclusion of >> acpi/acpi.h in fw_table.h. The unfortunate circular inclusion of >> linux/acpi.h is needed for fw_table.h due fw_table code needing the >> defined acpi structs in order to build. >> >> Fixes: a103f46633fd ("acpi: Move common tables helper functions to common lib") >> Reported-by: Linus Walleij <linus.walleij@linaro.org> >> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> Signed-off-by: Dave Jiang <dave.jiang@intel.com> >> --- >> include/linux/acpi.h | 23 ++++++++++++----------- >> include/linux/fw_table.h | 1 - >> 2 files changed, 12 insertions(+), 12 deletions(-) >> >> diff --git a/include/linux/acpi.h b/include/linux/acpi.h >> index 54189e0e5f41..2789beb26138 100644 >> --- a/include/linux/acpi.h >> +++ b/include/linux/acpi.h >> @@ -15,7 +15,6 @@ >> #include <linux/mod_devicetable.h> >> #include <linux/property.h> >> #include <linux/uuid.h> >> -#include <linux/fw_table.h> >> struct irq_domain; >> struct irq_domain_ops; >> @@ -25,16 +24,6 @@ struct irq_domain_ops; >> #endif >> #include <acpi/acpi.h> >> -#ifdef CONFIG_ACPI_TABLE_LIB >> -#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) >> -#define __init_or_acpilib >> -#define __initdata_or_acpilib >> -#else >> -#define EXPORT_SYMBOL_ACPI_LIB(x) >> -#define __init_or_acpilib __init >> -#define __initdata_or_acpilib __initdata >> -#endif >> - >> #ifdef CONFIG_ACPI >> #include <linux/list.h> >> @@ -48,6 +37,18 @@ struct irq_domain_ops; >> #include <acpi/acpi_io.h> >> #include <asm/acpi.h> >> +#include <linux/fw_table.h> >> + >> +#ifdef CONFIG_ACPI_TABLE_LIB >> +#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) >> +#define __init_or_acpilib >> +#define __initdata_or_acpilib >> +#else >> +#define EXPORT_SYMBOL_ACPI_LIB(x) >> +#define __init_or_acpilib __init >> +#define __initdata_or_acpilib __initdata >> +#endif >> + >> static inline acpi_handle acpi_device_handle(struct acpi_device *adev) >> { >> return adev ? adev->handle : NULL; >> diff --git a/include/linux/fw_table.h b/include/linux/fw_table.h >> index ff8fa58d5818..a722300c215b 100644 >> --- a/include/linux/fw_table.h >> +++ b/include/linux/fw_table.h >> @@ -26,7 +26,6 @@ struct acpi_subtable_proc { >> }; >> #include <linux/acpi.h> >> -#include <acpi/acpi.h> > > Hi Dave, > > Seems to me that the #include <linux/acpi.h> should go too, to break the circular including cycle. If it remains, I fear that there could be subtle problems in the future depending on which header is included first in a compilation unit. It sounds now like the only correct way to get fw_table.h included is transitively via linux/acpi.h (of note: lib/fw_table.c will have to be updated; it's the only file that currently breaks this rule) so that removal will just help enforce this. Plus, includes in the middle of non-preprocessor declarations are a (sometimes necessary, definitely not here) code smell, in my view. > > If this include must remain for some reason, perhaps a comment should be added to call attention to the circular situation and provide justification? If I remove linux/acpi.h as well in fw_table.h and place linux/acpi.h in fw_table.c before fw_table.h inclusion, it now seems to solve my build issue. Will that work? I'll send a v2. > > Cheers, > Sam > >> union acpi_subtable_headers { >> struct acpi_subtable_header common; >> >> >> >>
diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 54189e0e5f41..2789beb26138 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -15,7 +15,6 @@ #include <linux/mod_devicetable.h> #include <linux/property.h> #include <linux/uuid.h> -#include <linux/fw_table.h> struct irq_domain; struct irq_domain_ops; @@ -25,16 +24,6 @@ struct irq_domain_ops; #endif #include <acpi/acpi.h> -#ifdef CONFIG_ACPI_TABLE_LIB -#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) -#define __init_or_acpilib -#define __initdata_or_acpilib -#else -#define EXPORT_SYMBOL_ACPI_LIB(x) -#define __init_or_acpilib __init -#define __initdata_or_acpilib __initdata -#endif - #ifdef CONFIG_ACPI #include <linux/list.h> @@ -48,6 +37,18 @@ struct irq_domain_ops; #include <acpi/acpi_io.h> #include <asm/acpi.h> +#include <linux/fw_table.h> + +#ifdef CONFIG_ACPI_TABLE_LIB +#define EXPORT_SYMBOL_ACPI_LIB(x) EXPORT_SYMBOL_NS_GPL(x, ACPI) +#define __init_or_acpilib +#define __initdata_or_acpilib +#else +#define EXPORT_SYMBOL_ACPI_LIB(x) +#define __init_or_acpilib __init +#define __initdata_or_acpilib __initdata +#endif + static inline acpi_handle acpi_device_handle(struct acpi_device *adev) { return adev ? adev->handle : NULL; diff --git a/include/linux/fw_table.h b/include/linux/fw_table.h index ff8fa58d5818..a722300c215b 100644 --- a/include/linux/fw_table.h +++ b/include/linux/fw_table.h @@ -26,7 +26,6 @@ struct acpi_subtable_proc { }; #include <linux/acpi.h> -#include <acpi/acpi.h> union acpi_subtable_headers { struct acpi_subtable_header common;
Linus reported that: After commit a103f46633fd the kernel stopped compiling for several ARM32 platforms that I am building with a bare metal compiler. Bare metal compilers (arm-none-eabi-) don't define __linux__. This is because the header <acpi/platform/acenv.h> is now in the include path for <linux/irq.h>: CC arch/arm/kernel/irq.o CC kernel/sysctl.o CC crypto/api.o In file included from ../include/acpi/acpi.h:22, from ../include/linux/fw_table.h:29, from ../include/linux/acpi.h:18, from ../include/linux/irqchip.h:14, from ../arch/arm/kernel/irq.c:25: ../include/acpi/platform/acenv.h:218:2: error: #error Unknown target environment 218 | #error Unknown target environment | ^~~~~ The issue is caused by the introducing of splitting out the ACPI code to support the new generic fw_table code. Rafael suggested moving the fw_table.h include in linux/acpi.h to below the asm/acpi.h. The move also helped with eliminating the inclusion of acpi/acpi.h in fw_table.h. The unfortunate circular inclusion of linux/acpi.h is needed for fw_table.h due fw_table code needing the defined acpi structs in order to build. Fixes: a103f46633fd ("acpi: Move common tables helper functions to common lib") Reported-by: Linus Walleij <linus.walleij@linaro.org> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> --- include/linux/acpi.h | 23 ++++++++++++----------- include/linux/fw_table.h | 1 - 2 files changed, 12 insertions(+), 12 deletions(-)