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@xxxxxxxxxx>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Signed-off-by: Dave Jiang <dave.jiang@xxxxxxxxx>
---
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;
