On Mon, Nov 20, 2023 at 5:19 PM Dave Jiang <dave.jiang@xxxxxxxxx> wrote: > > > > On 11/20/23 08:46, Rafael J. Wysocki wrote: > > 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. > > Not including either causes compile errors for me. Interesting. What errors do you get if you include linux/acpi.h only? It should not be necessary to include acpi/acpi.h in addition to linux/acpi.h, because the latter is expected to include the former. If it doesn't do that, something is amiss. > And directly including acpi/acpi.h w/o linux/acpi.h causes triggering the #error and some other stuff: > > ./include/acpi/platform/aclinux.h:18:2: error: #error "Please don't include <acpi/acpi.h> directly, include <linux/acpi.h> instead." > 18 | #error "Please don't include <acpi/acpi.h> directly, include <linux/acpi.h> instead." > | ^~~~~ > > > Only including linux/acpi.h: > In file included from ./include/linux/acpi.h:18, > from init/main.c:30: > ./include/linux/fw_table.h:32:37: error: field ‘common’ has incomplete type > 32 | struct acpi_subtable_header common; > | ^~~~~~ > ./include/linux/fw_table.h:33:36: error: field ‘hmat’ has incomplete type > 33 | struct acpi_hmat_structure hmat; > | ^~~~ > ./include/linux/fw_table.h:34:40: error: field ‘prmt’ has incomplete type > 34 | struct acpi_prmt_module_header prmt; > | ^~~~ > ./include/linux/fw_table.h:35:33: error: field ‘cedt’ has incomplete type > 35 | struct acpi_cedt_header cedt; > | ^~~~ > > > > > > 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? > > This builds cleanly for me. OK, so I'm wondering if this also helps the other people in this thread.
