From: ebiederm@xmission.com (Eric W. Biederman)
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: Avi Kivity <avi@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Len Brown <lenb@kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Garrett <mjg@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrey Borzenkov <arvidjaar@mail.ru>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"Brown, Len" <len.brown@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH 10/10] x86, ACPI: default to reboot via ACPI (again)
Date: Wed, 12 Nov 2008 22:58:04 -0800 [thread overview]
Message-ID: <m1ljvom7sz.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <1226554186.4006.136.camel@yakui_zhao.sh.intel.com> (Zhao Yakui's message of "Thu, 13 Nov 2008 13:29:46 +0800")
Zhao Yakui <yakui.zhao@intel.com> writes:
>> Instead of just writing a plain 6. I think at least on some machines
>> there is a requirement for a low to hight transition.
> Maybe the 0xCF9 port is defined for NVidia, SiS and Several others
> vendor. But we can't say that it is appropriate for most boxes.
Let me get this straight. We survey all of the major chipsets in existence.
We discover a register that is implemented the same way in all of them.
You conclude that using that register is not appropriate for most boxes?
> Of course IMO it is not a generic solution for reboot.
> At the same time the value written to the 0xCF9 I/O port should not be a
> fixed value. Maybe it varies on different vendors/chipset. Even the
> value will vary on the boxes from different BIOS vendors although the
> boxes are based on the same chipset.
Reading in between the lines. Did you just say someone implemented
a nasty hack on some laptop and attempting to reboot by writing to 0xcf9
will cause nasty problems?
If you know of such a case please describe the failure mode. If there
is a case where writing to 0xcf9 will makes things worse than we need
to tread carefully, and we will happily deal with reality. If you can
only tell us that we are being rude and circumventing a vendors vision
of the then your input is not especially useful.
> And the value should be provided by BIOS. If BIOS doesn't provide
> the above info, it is not safe to use them.
Balderdash. There are other ways to learn things than by talking to
the BIOS. Usually BIOS's are a mediocre information source at best.
The job of a BIOS is to boot and if it can do that solidly you can ship it,
when the schedule gets tight. Everything else is a nice to have.
Eric
next prev parent reply other threads:[~2008-11-13 7:05 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-07 4:45 ACPI patchese on test branch Len Brown
2008-11-07 4:45 ` [PATCH 01/10] ACPI: pci_link: remove acpi_irq_balance_set() interface Len Brown
2008-11-07 4:45 ` [PATCH 02/10] ACPI: Disambiguate processor declaration type Len Brown
2008-11-07 4:45 ` [PATCH 03/10] ACPI: Behave uniquely based on processor declaration definition type Len Brown
2008-11-07 4:45 ` [PATCH 04/10] ACPI: 80 column adherence and spelling fix (no functional change) Len Brown
2008-11-07 4:45 ` [PATCH 05/10] Hibernate: Call platform_begin before swsusp_shrink_memory Len Brown
2008-11-07 4:45 ` [PATCH 06/10] ACPI hibernate: Add a mechanism to save/restore ACPI NVS memory Len Brown
2008-11-07 4:45 ` [PATCH 07/10] x86 hibernate: Mark ACPI NVS memory region at startup Len Brown
2008-11-07 4:45 ` [PATCH 08/10] ACPI hibernate: Introduce new kernel parameter acpi_sleep=s4_nonvs Len Brown
2008-11-07 4:45 ` [PATCH 09/10] compal-laptop: use rfkill switch subsystem Len Brown
2008-11-07 4:45 ` [PATCH 10/10] x86, ACPI: default to reboot via ACPI (again) Len Brown
2008-11-07 7:25 ` Ingo Molnar
2008-11-08 1:41 ` Len Brown
2008-11-08 6:30 ` Andrey Borzenkov
2008-11-08 7:12 ` Len Brown
2008-11-08 7:50 ` Andrey Borzenkov
2008-11-08 11:59 ` Ingo Molnar
2008-11-09 9:55 ` Avi Kivity
2008-11-09 10:00 ` H. Peter Anvin
2008-11-10 8:39 ` Ingo Molnar
2008-11-10 8:54 ` Avi Kivity
2008-11-10 9:02 ` Ingo Molnar
2008-11-11 18:26 ` H. Peter Anvin
2008-11-11 20:29 ` Eric W. Biederman
2008-11-11 20:44 ` Ingo Molnar
2008-11-10 11:59 ` Matthew Garrett
2008-11-10 11:57 ` Matthew Garrett
2008-11-10 12:56 ` Ingo Molnar
2008-11-10 13:00 ` Matthew Garrett
2008-11-11 23:14 ` Len Brown
2008-11-12 0:25 ` Attempt rebooting via port CF9 if it seems to be available H. Peter Anvin
2008-11-12 18:49 ` Andrey Borzenkov
2008-11-12 0:27 ` [PATCH 10/10] x86, ACPI: default to reboot via ACPI (again) Matthew Garrett
2008-11-12 11:58 ` Ingo Molnar
2008-11-12 12:23 ` Avi Kivity
2008-11-13 3:23 ` Zhao Yakui
2008-11-13 3:18 ` H. Peter Anvin
2008-11-13 3:43 ` Zhao Yakui
2008-11-13 4:10 ` Eric W. Biederman
2008-11-13 4:34 ` H. Peter Anvin
2008-11-13 4:14 ` Eric W. Biederman
2008-11-13 5:29 ` Zhao Yakui
2008-11-13 5:25 ` H. Peter Anvin
2008-11-13 6:56 ` Eric W. Biederman
2008-11-13 6:58 ` Eric W. Biederman [this message]
2008-11-13 9:06 ` Zhao Yakui
2008-11-13 17:42 ` H. Peter Anvin
2008-11-14 1:29 ` Zhao Yakui
2008-11-14 1:22 ` H. Peter Anvin
2008-11-14 1:49 ` Zhao Yakui
2008-11-13 3:29 ` Stephen Rothwell
2008-11-08 12:40 ` Rafael J. Wysocki
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=m1ljvom7sz.fsf@frodo.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=arvidjaar@mail.ru \
--cc=avi@redhat.com \
--cc=ehabkost@redhat.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mjg@redhat.com \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.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