Re: [PATCH] xen/arm: ACPI: Remove EXPERT dependancy, default on for ARM64

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.10.2020 05:35, Elliott Mitchell wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -32,13 +32,18 @@ menu "Architecture Features"
>  source "arch/Kconfig"
>  
>  config ACPI
> -     bool "ACPI (Advanced Configuration and Power Interface) Support" if 
> EXPERT
> +     bool "ACPI (Advanced Configuration and Power Interface) Support"
>       depends on ARM_64
> +     default y if ARM_64

The "if" is pointless with the "depends on".

> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -254,6 +254,15 @@ int __init acpi_boot_table_init(void)
>                                     dt_scan_depth1_nodes, NULL) )
>          goto disable;
>  
> +    printk("\n"
> +"*************************************************************************\n"
> +"*    WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING    *\n"
> +"*                                                                       *\n"
> +"* Xen-ARM ACPI support is EXPERIMENTAL.  It is presently (October 2020) *\n"
> +"* recommended you boot your system in device-tree mode if you can.      *\n"
> +"*************************************************************************\n"
> +            "\n");
> +

We have an abstraction for such warnings, causing them to appear
later in the boot process and then consistently all in one place
(both increasing, as we believe, the chances of being noticed):
warning_add(). There's a delay accompanied with this, so I think
you will want to also have a command line option allowing to
silence this warning. "acpi=on" or "acpi=force", as available on
x86 and (possibly wrongly right now) not documented as
x86-specific, may be (re-)usable, i.e. to avoid having to
introduce some entirely new option.

Also a few formal nits: The subject tag should have been [PATCH v2],
there should have been a short revision log outside of the commit
message area, and new patch versione would better start their own
new threads than being in-reply-to the earlier version's one.

Jan