From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Len Brown <lenb@kernel.org>
Cc: Arjan van de Ven <arjan@infradead.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Christian Hofstaedtler <ch@zeha.at>,
x86@kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
bruce.w.allan@intel.com, Thomas Gleixner <tglx@linutronix.de>,
Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-acpi@vger.kernel.org,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH] Add DMI quirk for Intel DP55KG mainboard
Date: Wed, 6 Jan 2010 19:36:08 +0000 [thread overview]
Message-ID: <20100106193608.GA21447@srcf.ucam.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1001061321260.4086@localhost.localdomain>
On Wed, Jan 06, 2010 at 02:26:44PM -0500, Len Brown wrote:
> But...
> using _OSI is not "a similar method to Windows".
> The BIOS does not need to invoke _OSI to determine if
> it should expose a properly functioning ACPI reset or not.
> Windows XP simply demanded it, and the box failed WHQL
> if it did not work.
http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx
was what I was referring to:
"By using the _OSI method, ASL writers can easily determine the version
of the ACPI interfaces that the host operating system supports. This
versioning method provides a solution for creating firmware that can
support future operating systems and enable the operating system to
change behavior based on the requested interface levels."
We know that this is used for deciding whether or not to block system IO
accesses, but it wouldn't surprise me if it's also used to determine
other functionality like whether or not the ACPI interface is used for
rebooting.
> Further, there is no _guarantee_ that a BIOS will invoke _OSI
> at all, let alone a _rule_ for what _OSI() strings the BIOS
> will choose to query to trigger its Windows specific
> compatibility hooks -- even if common practice is for
> a desktop BIOS to evaluate _OSI strings in sequence
> up throught he most recent version of Windows it
> knows about...
It's effectively guaranteed if the system is validated with Windows.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2010-01-06 19:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-03 20:23 Linux* is not supported on the Intel(R) Desktop Board DP55KG - Kernel still hangs upon reboot Christian Hofstaedtler
2010-01-03 21:40 ` Justin Piszcz
2010-01-03 23:03 ` Arjan van de Ven
2010-01-03 23:34 ` Christian Hofstaedtler
2010-01-04 5:47 ` Yuhong Bao
2010-01-04 15:16 ` David John
2010-06-11 2:16 ` Yuhong Bao
2010-01-04 16:21 ` [PATCH] Add DMI quirk for Intel DP55KG mainboard Christian Hofstaedtler
2010-01-04 17:15 ` Len Brown
2010-01-04 17:30 ` H. Peter Anvin
2010-01-04 22:03 ` Len Brown
2010-01-05 2:15 ` Robert Hancock
2010-01-05 3:37 ` H. Peter Anvin
2010-01-05 12:30 ` [PATCH] Default to ACPI reboots on newish X86 hardware Christian Hofstaedtler
2010-01-05 17:04 ` H. Peter Anvin
2010-01-05 18:26 ` Christian Hofstaedtler
2010-01-06 6:06 ` H. Peter Anvin
2010-01-06 19:38 ` Len Brown
2010-01-07 20:03 ` Christian Hofstaedtler
2010-01-07 20:05 ` Christian Hofstaedtler
2010-01-07 23:05 ` H. Peter Anvin
2010-01-20 5:21 ` Len Brown
2010-01-21 17:18 ` [PATCH 1/2] x86: Unify reboot_type selection Christian Hofstaedtler
2010-01-21 17:18 ` [PATCH 2/2] Default to ACPI reboots on newish X86 hardware Christian Hofstaedtler
2010-01-23 19:57 ` Len Brown
2010-01-21 18:29 ` [PATCH 1/2] x86: Unify reboot_type selection H. Peter Anvin
2010-01-21 17:24 ` [PATCH] Default to ACPI reboots on newish X86 hardware Christian Hofstaedtler
2010-01-05 1:45 ` [PATCH] Add DMI quirk for Intel DP55KG mainboard Arjan van de Ven
2010-01-06 14:36 ` Matthew Garrett
2010-01-06 19:26 ` Len Brown
2010-01-06 19:36 ` Matthew Garrett [this message]
2010-01-06 20:22 ` Len Brown
2010-01-06 20:29 ` Matthew Garrett
2010-01-06 21:26 ` H. Peter Anvin
2010-01-20 5:06 ` Len Brown
2010-01-07 1:15 ` Robert Hancock
2010-01-06 7:41 ` Pavel Machek
2010-01-06 14:51 ` Alan Cox
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=20100106193608.GA21447@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=arjan@infradead.org \
--cc=bruce.w.allan@intel.com \
--cc=ch@zeha.at \
--cc=hpa@zytor.com \
--cc=jpiszcz@lucidpixels.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
--cc=x86@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.