I don't know -- it would depend on the particular transport. In any
case, it's a decision the transport class can make.
Possibly.
Also possible, although I don't think your example is a good one since
sd.c wouldn't be aware of vendor-specific commands.
To my mind, if the driver has to do something special to prepare for
the link going down (such as draining the cache), then afterward the
device is in a special state -- not the same as the active state. The
difference between the two states is that in one the link may be
autosuspended and in the other it mustn't.
I see the driver making the transition between these states in response
to autosuspend and autoresume calls.
This means a driver such as sd.c has to respond in different sorts of
ways to various autosuspend scenarios, either doing a real power-down
or merely preparing for the link to go down. The implication is that
we might want to send the driver two different autosuspend calls: One
to prepare for the link to go down (after, say, a couple of seconds of
idleness) and another to power-down the device (after, say, 15 minutes
of idleness).
Thus, there would be two "autosuspended" states: a shallow autosuspend
(cache is drained) and a deep autosuspend (disk is spun down). Such an
approach could be made to work, even though it seems slightly
artificial.
Alan Stern
--
