On Tue, Nov 14, 2023 at 7:09 PM Sam Edwards <cfsworks@xxxxxxxxx> wrote: > > 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. Yes, that's the problem AFAICS. Dave? What about moving the fw_table.h include in linux/acpi.h below the mutex.h one, along with the EXPORT_SYMBOL_ACPI_LIB-related definitions? BTW, I'm not really sure why fw_table.h needs to include both linux/acpi.h and acpi/acpi.h, because it should get the latter through the former anyway. > > > > 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. There are exceptions, but generally you are right. > 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? Something like that.
