public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
* [PATCH] acpi: Fix ARM32 platforms compile issue introduced by fw_table changes
@ 2023-11-21 15:58 Dave Jiang
  2023-11-21 21:49 ` Sam Edwards
  0 siblings, 1 reply; 3+ messages in thread
From: Dave Jiang @ 2023-11-21 15:58 UTC (permalink / raw)
  To: linus.walleij, rafael
  Cc: Rafael J. Wysocki, lenb, robert.moore, Jonathan.Cameron,
	dan.j.williams, guohanjun, arnd, linux-acpi, acpica-devel,
	linux-kernel, linux-arm-kernel

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>
 
 union acpi_subtable_headers {
 	struct acpi_subtable_header common;



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] acpi: Fix ARM32 platforms compile issue introduced by fw_table changes
  2023-11-21 15:58 [PATCH] acpi: Fix ARM32 platforms compile issue introduced by fw_table changes Dave Jiang
@ 2023-11-21 21:49 ` Sam Edwards
  2023-11-21 22:11   ` Dave Jiang
  0 siblings, 1 reply; 3+ messages in thread
From: Sam Edwards @ 2023-11-21 21:49 UTC (permalink / raw)
  To: Dave Jiang, linus.walleij, rafael
  Cc: Rafael J. Wysocki, lenb, robert.moore, Jonathan.Cameron,
	dan.j.williams, guohanjun, arnd, linux-acpi, acpica-devel,
	linux-kernel, linux-arm-kernel



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;
> 
> 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] acpi: Fix ARM32 platforms compile issue introduced by fw_table changes
  2023-11-21 21:49 ` Sam Edwards
@ 2023-11-21 22:11   ` Dave Jiang
  0 siblings, 0 replies; 3+ messages in thread
From: Dave Jiang @ 2023-11-21 22:11 UTC (permalink / raw)
  To: Sam Edwards, linus.walleij, rafael
  Cc: Rafael J. Wysocki, lenb, robert.moore, Jonathan.Cameron,
	dan.j.williams, guohanjun, arnd, linux-acpi, acpica-devel,
	linux-kernel, linux-arm-kernel



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;
>>
>>
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-11-21 22:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-21 15:58 [PATCH] acpi: Fix ARM32 platforms compile issue introduced by fw_table changes Dave Jiang
2023-11-21 21:49 ` Sam Edwards
2023-11-21 22:11   ` Dave Jiang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox