Introduce a generic acpi.h header that provides the required definitions
to allow files including xen/acpi.h to be compiled. The definitions were
largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.

Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
---
 xen/arch/ppc/include/asm/Makefile |  1 +
 xen/include/asm-generic/acpi.h    | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 xen/include/asm-generic/acpi.h

diff --git a/xen/arch/ppc/include/asm/Makefile b/xen/arch/ppc/include/asm/Makefile
index ced02e26ed..a4faa0f2aa 100644
--- a/xen/arch/ppc/include/asm/Makefile
+++ b/xen/arch/ppc/include/asm/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+generic-y += acpi.h
 generic-y += altp2m.h
 generic-y += device.h
 generic-y += div64.h
diff --git a/xen/include/asm-generic/acpi.h b/xen/include/asm-generic/acpi.h
new file mode 100644
index 0000000000..ae9ed83ba8
--- /dev/null
+++ b/xen/include/asm-generic/acpi.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __ASM_GENERIC_ACPI_H
+#define __ASM_GENERIC_ACPI_H
+
+#include <asm/page.h>
+#include <xen/types.h>
+
+#ifdef CONFIG_ACPI
+#error "asm-generic acpi.h can't be used with CONFIG_ACPI set"
+#endif
+
+#define COMPILER_DEPENDENT_INT64   int64_t
+#define COMPILER_DEPENDENT_UINT64  uint64_t
+#define ACPI_MAP_MEM_ATTR          PAGE_HYPERVISOR
+
+#define acpi_disabled (true)
+#define disable_acpi()
+#define enable_acpi()
+
+#endif /* __ASM_GENERIC_ACPI_H */
-- 
2.30.2

On 14.03.2024 23:15, Shawn Anastasio wrote:
> Introduce a generic acpi.h header that provides the required definitions
> to allow files including xen/acpi.h to be compiled. The definitions were
> largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.

As said a couple of times in discussion with Oleksii on his work towards
populating asm-generic/, I view a use like this as an abuse of this
asm-generic machinery. Instead imo said !CONFIG_ACPI parts from Arm's header
want moving to xen/acpi.h, eliminating the need for asm/acpi.h for
architectures / configurations not supporting ACPI. Much like was done
with e.g. xen/numa.h.

Jan

> --- a/xen/arch/ppc/include/asm/Makefile
> +++ b/xen/arch/ppc/include/asm/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +generic-y += acpi.h
>  generic-y += altp2m.h
>  generic-y += device.h
>  generic-y += div64.h
> --- /dev/null
> +++ b/xen/include/asm-generic/acpi.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_ACPI_H
> +#define __ASM_GENERIC_ACPI_H
> +
> +#include <asm/page.h>
> +#include <xen/types.h>
> +
> +#ifdef CONFIG_ACPI
> +#error "asm-generic acpi.h can't be used with CONFIG_ACPI set"
> +#endif
> +
> +#define COMPILER_DEPENDENT_INT64   int64_t
> +#define COMPILER_DEPENDENT_UINT64  uint64_t
> +#define ACPI_MAP_MEM_ATTR          PAGE_HYPERVISOR
> +
> +#define acpi_disabled (true)
> +#define disable_acpi()
> +#define enable_acpi()
> +
> +#endif /* __ASM_GENERIC_ACPI_H */

Hi Jan,

On 3/25/24 10:19 AM, Jan Beulich wrote:
> On 14.03.2024 23:15, Shawn Anastasio wrote:
>> Introduce a generic acpi.h header that provides the required definitions
>> to allow files including xen/acpi.h to be compiled. The definitions were
>> largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.
> 
> As said a couple of times in discussion with Oleksii on his work towards
> populating asm-generic/, I view a use like this as an abuse of this
> asm-generic machinery. Instead imo said !CONFIG_ACPI parts from Arm's header
> want moving to xen/acpi.h, eliminating the need for asm/acpi.h for
> architectures / configurations not supporting ACPI. Much like was done
> with e.g. xen/numa.h.
>

In this case I'm not sure I fully agree, since the definitions here
aren't really stubs but rather more-or-less fully complete
architecture-independent implementations of these symbols for the
!CONFIG_ACPI case.

That said, after you mentioned the other route of modifying xen/acpi.h,
I found that going that route required fewer changes, so I'll proceed
with that approach.

> Jan

Thanks,
Shawn