public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Thomas Renninger <trenn@suse.de>
Cc: Len Brown <lenb@kernel.org>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	Zhao Yakui <yakui.zhao@intel.com>,
	me@markdoughty.co.uk,
	linux-thinkpad <linux-thinkpad@linux-thinkpad.org>,
	"devel@acpica.org" <devel@acpica.org>
Subject: Re: [RESEND] [PATCH 2/3] Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt
Date: Tue, 11 Nov 2008 00:58:56 +0000	[thread overview]
Message-ID: <20081111005856.GA10535@srcf.ucam.org> (raw)
In-Reply-To: <200810192350.57993.trenn@suse.de>

I've now had confirmation from multiple sources that Vista still uses 
the 32-bit addresses for the GPE blocks. We're actually seeing the same 
bug on some currently shipping machines, so again I'm going to suggest 
that the blacklist model isn't going to scale and we should just behave 
like Windows. How about this patch instead? It does some sanity 
checking, so I doubt that there's any way it could break a legitimate 
system. I've left IA64 as-is because it seems more likely that there'd 
be a requirement for 64-bit setups there.

Signed-off-by: Matthew Garrett <mjg@redhat.com>

---

Are there even any ACPI platforms where a system io address can be 
greater than 32 bits? It's limited to 16 bits on x86, so I *really* 
don't think this is going to break anything. The FADTs I've checked from 
Thinkpads all seem to have valid 32-bit addresses even using the one 
obtained from the XSDT.

diff --git a/drivers/acpi/events/evgpeblk.c b/drivers/acpi/events/evgpeblk.c
index 73c058e..eed35d7 100644
--- a/drivers/acpi/events/evgpeblk.c
+++ b/drivers/acpi/events/evgpeblk.c
@@ -1107,6 +1107,32 @@ acpi_status acpi_ev_gpe_initialize(void)
 	 */
 
 	/*
+	 * The ACPI specification says that we should use the 64-bit
+	 * address offset for the GPE blocks if it 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.
+	 */
+
+#ifdef CONFIG_X86
+	if (acpi_gbl_FADT.gpe0_block &&
+	    acpi_gbl_FADT.xgpe0_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe0_block.address =
+			(u64)acpi_gbl_FADT.gpe0_block;
+
+	if (acpi_gbl_FADT.gpe1_block &&
+	    acpi_gbl_FADT.xgpe1_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO)
+		acpi_gbl_FADT.xgpe1_block.address =
+			(u64)acpi_gbl_FADT.gpe1_block;
+#endif
+
+	/*
 	 * Determine the maximum GPE number for this machine.
 	 *
 	 * Note: both GPE0 and GPE1 are optional, and either can exist without

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  parent reply	other threads:[~2008-11-11  0:59 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19 21:50 [RESEND] [PATCH 2/3] Introduce acpi_root_table=rsdt boot param and dmi list to force rsdt Thomas Renninger
2008-10-20  1:01 ` Matthew Garrett
2008-10-20 15:31   ` Henrique de Moraes Holschuh
2008-10-20 16:23     ` Thomas Renninger
2008-10-20 16:27       ` Matthew Garrett
2008-10-20 16:48         ` Thomas Renninger
2008-10-20 16:54           ` Matthew Garrett
2008-10-20 17:51             ` Henrique de Moraes Holschuh
2008-10-20 17:58               ` Matthew Garrett
2008-10-20 18:16                 ` Henrique de Moraes Holschuh
2008-10-20 18:24                   ` Matthew Garrett
2008-10-20 18:47                     ` Henrique de Moraes Holschuh
2008-10-20 18:52                       ` Matthew Garrett
2008-10-20 19:25                         ` Henrique de Moraes Holschuh
2008-10-21  8:14                         ` Thomas Renninger
2008-10-21  9:53                         ` Thomas Renninger
2008-10-21  9:57                 ` Thomas Renninger
2008-10-21 12:46                   ` Matthew Garrett
2008-10-21 13:05                     ` Thomas Renninger
2008-10-21 13:08                       ` Matthew Garrett
2008-10-21 13:34                         ` Thomas Renninger
2008-10-21 14:01                           ` Rafael J. Wysocki
2008-10-21 14:00                             ` Matthew Garrett
2008-10-21 14:12                               ` Thomas Renninger
2008-10-21 14:19                                 ` Matthew Garrett
2008-10-21 14:25                               ` Rafael J. Wysocki
2008-10-21 14:29                                 ` Matthew Garrett
2008-10-21 14:45                                   ` Thomas Renninger
2008-10-21 14:49                                     ` Matthew Garrett
2008-10-21 15:10                                   ` Rafael J. Wysocki
2008-10-21 15:27                                     ` Matthew Garrett
2008-10-21 15:46                                       ` Henrique de Moraes Holschuh
2008-10-21 15:50                                         ` Matthew Garrett
2008-10-21 16:58                                           ` [ltp] " Henrique de Moraes Holschuh
2008-10-21 17:02                                             ` Matthew Garrett
2008-10-21 19:04                                             ` Rafael J. Wysocki
2008-10-20 16:43   ` Thomas Renninger
2008-10-20 18:05     ` Henrique de Moraes Holschuh
2008-10-20 15:46 ` Henrique de Moraes Holschuh
2008-10-21 11:07   ` Thomas Renninger
2008-11-11  0:58 ` Matthew Garrett [this message]
2008-11-12 23:58   ` Thomas Renninger
2008-11-13  0:56     ` Matthew Garrett
2008-11-13  2:21     ` [Devel] " Zhang Rui
2008-11-13  2:24       ` Matthew Garrett
2008-11-13  8:27         ` Zhang Rui
2008-11-13 11:13           ` Matthew Garrett

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=20081111005856.GA10535@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=devel@acpica.org \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-thinkpad@linux-thinkpad.org \
    --cc=me@markdoughty.co.uk \
    --cc=trenn@suse.de \
    --cc=yakui.zhao@intel.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