Re: [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit firmware waking vector.

[Ingo Molnar]

* Lv Zheng <lv.zheng@xxxxxxxxx> wrote:

> This patch updates acpi_set_firmware_waking_vector() invocations in order
> to keep 32-bit firmware waking vector favor for Linux.

This sentence does not parse.

> 64-bit firmware waking vector has never been enabled by Linux.  The
> (acpi_physical_address)0 for 64-bit address can be used to force ACPICA to
> set only 32-bit firmware waking vector for Linux.

So this is a change that affects a lot of systems - what is the expected 
compatibility of this? Does Windows enable the 64-bit address? Which versions of 
Windows?

> 
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=74021
> Reported-and-tested-by: Oswald Buddenhagen <ossi@xxxxxxx>
> Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
> Cc: x86@xxxxxxxxxx
> Cc: Tony Luck <tony.luck@xxxxxxxxx>
> Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
> Cc: linux-ia64@xxxxxxxxxxxxxxx
> ---
>  arch/ia64/include/asm/acpi.h |    3 ++-
>  arch/ia64/kernel/acpi.c      |    2 --
>  arch/x86/include/asm/acpi.h  |    3 ++-
>  drivers/acpi/sleep.c         |    8 ++++++--
>  4 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
> index aa0fdf1..0ac4fab 100644
> --- a/arch/ia64/include/asm/acpi.h
> +++ b/arch/ia64/include/asm/acpi.h
> @@ -79,7 +79,8 @@ int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
>  /* Low-level suspend routine. */
>  extern int acpi_suspend_lowlevel(void);
>  
> -extern unsigned long acpi_wakeup_address;
> +#define acpi_wakeup_address	((acpi_physical_address)0)
> +#define acpi_wakeup_address64	((acpi_physical_address)0)
>  
>  /*
>   * Record the cpei override flag and current logical cpu. This is
> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> index b1698bc..1b08d6f 100644
> --- a/arch/ia64/kernel/acpi.c
> +++ b/arch/ia64/kernel/acpi.c
> @@ -60,8 +60,6 @@ int acpi_lapic;
>  unsigned int acpi_cpei_override;
>  unsigned int acpi_cpei_phys_cpuid;
>  
> -unsigned long acpi_wakeup_address = 0;
> -
>  #ifdef CONFIG_IA64_GENERIC
>  static unsigned long __init acpi_find_rsdp(void)
>  {
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index 3a45668..fc9608d 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -72,7 +72,8 @@ static inline void acpi_disable_pci(void)
>  extern int (*acpi_suspend_lowlevel)(void);
>  
>  /* Physical address to resume after wakeup */
> -#define acpi_wakeup_address ((unsigned long)(real_mode_header->wakeup_start))
> +#define acpi_wakeup_address	((acpi_physical_address)(real_mode_header->wakeup_start))
> +#define acpi_wakeup_address64	((acpi_physical_address)(0))

Btw., 'acpi_physical_address' is a mouthful, and despite being a data type, it 
looks like a variable name. Please rename it to something more sensible, matching 
existing physical address patterns, like 'acpi_phys_addr_t'.

Also, is there any reason why it's not simply phys_addr_t? It's not like ACPI has 
a different notion of physical addresses.

> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index 2f0d4db..3a6a2eb 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -25,6 +25,8 @@
>  #include "internal.h"
>  #include "sleep.h"
>  
> +#define ACPI_NO_WAKING_VECTOR		((acpi_physical_address)0)

So in x86 speak, 'vectors' are the things that drive interrupts. They are not 
addresses. So calling it a 'vector' is a misnomer - it's a wakeup entry address 
point.

Secondly, when the 64-bit entry point is configured, in what mode does the 
firmware enter it - still real mode? Exactly what are the semantics when the 
64-bit entry point is set?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/