A further explanation, which I'd like to have in the case log, for why a
separate quiesce routine, and suspend was deemed insufficient follows.
These details have previously been discussed with the project team
before this case was submitted. Note that none of the following is a
request for any action on anyone's part, I just want to record the
rationale more clearly here for posterity.
-- Garrett
It is interesting to note that for many drivers there may be a great
deal of shared implementation between quiesce and suspend. However, we
should consider why a separate quiesce is required:
1) suspend requires device drivers be able to suspend without loss
of functionality, which makes it much, much harder to guarantee correct
function. quiesce is far far simpler in this regard. (If device
drivers never "failed" suspend -- e.g. because the device is in use,
then they could probably use their suspend logic.)
2) quiesce requires a device be placed in a state where it can be
reinitialized as if it were in a more-or-less default state, without a
power cycle or bus reset, and without any soft state being passed from
one environment to the next. To put a concrete example, think of a NIC
device which initializes with a default MAC address, but which can be
temporarily changed in software by the driver, e.g. in response to an
end user using ifconfig to change the mac address. The problem now is
that the original factory mac address is "lost" unless the device gets a
full reset. (And in fact, this particular behavior for NICs is not
uncommon.) In this regard, the ability to go back to an initial "power
on" or "default" state is actually a *new* requirement, and one where
suspend semantics might not be sufficient.
