[PATCH] ACPI: acenv: Permit compilation from within the kernel

Sam Edwards cfsworks at gmail.com
Tue Nov 14 10:09:37 PST 2023


On 11/13/23 16:08, Linus Walleij wrote:
> 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__.

Hi Linus,

I saw the same baremetal-compiler error here on the ARM64 side of the 
fence, and narrowed the problem to the same commit as you.

> 
> This is because the header <acpi/platform/acenv.h> is now
> in the include path for <linux/irq.h>:

More generally, I think it's because of this addition to linux/acpi.h:
+#include <linux/fw_table.h>

linux/acpi.h is supposed to ensure _LINUX is defined (if it isn't 
already done by a non-baremetal compiler) before we start pulling in 
ACPICA includes, so that ACPICA knows the platform. But because 
fw_table.h contains:
#include <linux/acpi.h>
#include <acpi/acpi.h>

...the circular include does nothing (linux/acpi.h's include guard stops 
the include before _LINUX is defined) and we end up pulling in 
acpi/acpi.h before we're ready.

> 
>    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
>        |  ^~~~~
> 
> One solution to make compilation with a bare metal compiler
> work again is to say the file is used with Linux from within
> the kernel if __KERNEL__ is defined so I did that.

I am not an ACPI subsystem maintainer, but my understanding is that the 
files in include/acpi/ are copied verbatim from ACPICA, so any change to 
those files will have to be sent to the ACPICA project and wouldn't be 
accepted here.

More likely, we'd want to do something about the circular-include 
situation between linux/fw_table.h<->linux/acpi.h. That may have further 
consequences down the road than just our problem here. Perhaps just 
dropping both #includes from fw_table.h, and lowering the fw_table.h 
include from within linux/acpi.h to be below <acpi/acpi.h>, is the way 
to go?

Kind regards,
Sam



More information about the linux-arm-kernel mailing list