* Lv Zheng <lv.zh...@intel.com> 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 <o...@kde.org> > Signed-off-by: Lv Zheng <lv.zh...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: x...@kernel.org > Cc: Tony Luck <tony.l...@intel.com> > Cc: Fenghua Yu <fenghua...@intel.com> > Cc: linux-i...@vger.kernel.org > --- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
