From: Ingo Molnar <mingo@kernel.org>
To: Lv Zheng <lv.zheng@intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>, Lv Zheng <zetalog@gmail.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit
Date: Fri, 19 Jun 2015 06:26:31 +0000 [thread overview]
Message-ID: <20150619062631.GA9668@gmail.com> (raw)
In-Reply-To: <2f708d4ee4100bd1b64ca1ea00b678d5f5b2135a.1434684719.git.lv.zheng@intel.com>
* Lv Zheng <lv.zheng@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?idt021
> Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org>
> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Fenghua Yu <fenghua.yu@intel.com>
> Cc: linux-ia64@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
next prev parent reply other threads:[~2015-06-19 6:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1434684719.git.lv.zheng@intel.com>
2015-06-19 3:38 ` [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit firm Lv Zheng
2015-06-19 6:26 ` Ingo Molnar [this message]
2015-06-19 23:42 ` [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit Rafael J. Wysocki
[not found] ` <cover.1435114811.git.lv.zheng@intel.com>
2015-06-24 3:02 ` [PATCH v2 03/28] ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS Lv Zheng
2015-06-24 13:39 ` Rafael J. Wysocki
2015-06-24 22:58 ` Rafael J. Wysocki
2015-06-25 0:29 ` Zheng, Lv
2015-06-26 0:54 ` Rafael J. Wysocki
2015-06-26 1:39 ` Zheng, Lv
2015-06-25 1:09 ` Zheng, Lv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150619062631.GA9668@gmail.com \
--to=mingo@kernel.org \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mingo@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=zetalog@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox