From: "Adam J. Richter" <adam@yggdrasil.com>
To: rmk@arm.linux.org.uk
Cc: ebiederm@xmission.com, eblade@blackmagik.dynup.net,
linux-kernel@vger.kernel.org
Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices
Date: Sun, 13 Oct 2002 16:10:01 -0700 [thread overview]
Message-ID: <200210132310.QAA01044@adam.yggdrasil.com> (raw)
Russell King writes:
>x86, I believe, is one example of such a platform that can leave PCI
>devices jabbering over a warm reboot.
The standards on pcisig.com are apparently proprietary, so I'm
afraid I can only quote a proprietary book I have handy:
Reset Signal (RST#):
When asserted, the reset signal forces all PCI configuration
registers, master and target state machines and output drivers to an
initialized state. RST# may be asserted or deasserted asynchronously
to the PCI CLK edge. The assertion of RST# also initializes other,
device-specific functions, but this subject is beyond the scope of the
PCI specification. All PCI output signals must be driver to their
bening states. In general, this means they must be tri-stated [...]
Chapter 4, page 37
_PCI System Architecture, 4th Edition_
Tom Shanley and Don Anderson
So, you must be talking about a PC that does not ground RST#
during a warm reboot or out of spec (according to this book) PCI devices,
which would not be specific to x86 unless we're talking about motherboard
chipset devices.
I understand the benefits of being conservative, but let's not
be taken in by urban legend, or, more likely, some quirkly hardware
that we can set a flag for while we can reboot more quickly with most
other hardware. Anyhow, if you or anyone can give me specifics about
devices jabbering away after reboot, that would be great
I have no objection to replacing or supplementing the reboot
notifier chain with a method in struct device_driver, but let's not
overload these methods with ambiguous semantics. I do not want to
call thirty functions that primarily return memory to various memory
allocators, mark a bunch of inodes as invalid, and otherwise arrange
things so that the kernel can smoothly continue to run user level
programs when, in fact, we just want to pull the reset line on the
computer.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
next reply other threads:[~2002-10-13 23:04 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-13 23:10 Adam J. Richter [this message]
2002-10-13 23:15 ` Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices Russell King
2002-10-14 0:03 ` Eric W. Biederman
2002-10-13 23:54 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2002-10-21 22:26 Adam J. Richter
2002-10-21 20:56 Adam J. Richter
2002-10-22 4:28 ` Eric W. Biederman
2002-10-20 7:01 Adam J. Richter
2002-10-20 9:17 ` Eric W. Biederman
2002-10-20 20:43 ` Patrick Mochel
2002-10-20 23:57 ` Eric W. Biederman
2002-10-21 17:13 ` Patrick Mochel
2002-10-17 1:50 Adam J. Richter
2002-10-17 9:08 ` Eric W. Biederman
2002-10-15 19:52 Adam J. Richter
2002-10-16 12:13 ` Eric W. Biederman
2002-10-15 18:54 Adam J. Richter
2002-10-15 2:53 Adam J. Richter
2002-10-15 16:59 ` Eric W. Biederman
2002-10-14 18:41 Adam J. Richter
2002-10-14 20:05 ` Eric W. Biederman
2002-10-15 4:55 ` Eric Blade
2002-10-16 8:01 ` Pavel Machek
2002-10-14 15:25 Adam J. Richter
2002-10-14 16:44 ` Eric W. Biederman
2002-10-14 17:48 ` Richard B. Johnson
2002-10-14 19:28 ` Eric W. Biederman
2002-10-14 20:17 ` Richard B. Johnson
2002-10-13 23:59 Adam J. Richter
2002-10-14 0:07 ` Eric W. Biederman
2002-10-14 5:38 ` Eric Blade
2002-10-14 15:28 ` Eric W. Biederman
2002-10-15 4:34 ` Eric Blade
2002-10-13 22:14 Adam J. Richter
2002-10-13 22:31 ` Russell King
2002-10-13 23:49 ` Eric W. Biederman
2002-10-15 16:35 ` Patrick Mochel
2002-10-15 20:04 ` Mikael Pettersson
2002-10-19 18:30 ` Eric W. Biederman
2002-10-20 9:47 ` Eric W. Biederman
2002-10-13 19:24 Adam J. Richter
2002-10-13 19:51 ` Eric Blade
2002-10-13 21:27 ` Eric W. Biederman
2002-10-13 22:52 ` Andries Brouwer
2002-10-14 0:30 ` Eric W. Biederman
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=200210132310.QAA01044@adam.yggdrasil.com \
--to=adam@yggdrasil.com \
--cc=ebiederm@xmission.com \
--cc=eblade@blackmagik.dynup.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).