From: Matthew Garrett <mjg59@srcf.ucam.org>
To: lenb@kernel.org
Cc: linux-acpi@vger.kernel.org
Subject: [PATCH] Use 32-bit FADT values on X86
Date: Mon, 1 Dec 2008 11:17:13 +0000 [thread overview]
Message-ID: <20081201111713.GA26069@srcf.ucam.org> (raw)
The ACPI specification says that we should use the 64-bit address offsets
contained within the FADT if they exist. However, Windows uses the legacy
address. Various vendors have left incorrect values in the 64-bit field
which then causes problems later. Since the vast majority of machines have
never been tested with an OS that uses the 64-bit value by default, we should
behave like Windows and ignore the spec by only using the 64-bit address if
it contains something that can't be represented in the legacy field. Since
system io space is only 16 bits on x86, this should be entirely safe.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
Len, this is a clear case of the spec not matching real-life behaviour.
I'd be amazed if anyone can find an x86 system that uses system-io space
for these values and doesn't contain an accurate value in the 32-bit
field. On the other hand, we've seen machines that assume the
Windows-style behaviour and we keep finding more. A blacklist isn't the
correct solution for this problem.
diff --git a/drivers/acpi/tables/tbfadt.c b/drivers/acpi/tables/tbfadt.c
index 2817158..89a3c82 100644
--- a/drivers/acpi/tables/tbfadt.c
+++ b/drivers/acpi/tables/tbfadt.c
@@ -320,9 +320,30 @@ static void acpi_tb_convert_fadt(void)
ACPI_ADD_PTR(struct acpi_generic_address, &acpi_gbl_FADT,
fadt_info_table[i].target);
- /* Expand only if the X target is null */
-
- if (!target->address) {
+ /*
+ * The ACPI specification says that we should use the
+ * 64-bit address offsets if they exists. However,
+ * Windows uses the legacy address. Various vendors
+ * have left incorrect values in the 64-bit field,
+ * which then causes problems later. Since the vast
+ * majority of machines have never been tested with an
+ * OS that uses the 64-bit value by default, we should
+ * behave like Windows and ignore the spec by only
+ * using the 64-bit address if it contains something
+ * that can't be represented in the legacy
+ * field. Since system io space is only 16 bits on
+ * x86, this should be entirely safe. We also extend
+ * the 32-bit value into the 64-bit one if no 64-bit
+ * address is provided.
+ */
+
+ if (!target->address
+#ifdef CONFIG_X86
+ || (target->space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
+ *ACPI_ADD_PTR(u32, &acpi_gbl_FADT,
+ fadt_info_table[i].source))
+#endif
+ ) {
acpi_tb_init_generic_address(target,
*ACPI_ADD_PTR(u8,
&acpi_gbl_FADT,
--
Matthew Garrett | mjg59@srcf.ucam.org
next reply other threads:[~2008-12-01 11:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-01 11:17 Matthew Garrett [this message]
2008-12-02 1:05 ` [PATCH] Use 32-bit FADT values on X86 Zhang Rui
2008-12-02 1:14 ` Matthew Garrett
2008-12-02 3:48 ` Len Brown
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=20081201111713.GA26069@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.