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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:48 EST