On Mon, 19 Nov 2007, James Bottomley wrote: > > Here's how it will work: scsi_prep_state_check() will see that the > > device is in a suspended state (probably a substate of SDEV_QUIESCE). > > The return value will depend on the type of suspend: > > > > For manual suspend or system suspend, the routine simply > > returns BLKPREP_KILL. > > > > For autosuspend, the routine will submit a workqueue request > > to autoresume the device and will return BLKPREP_DEFER. > > > > The trick is somehow to allow the START-STOP UNIT commands get past > > this filter. Is this what the REQ_PREEMPT flag is intended for? > > Um, that model is pretty host centric ... we wouldn't be able to use > that for power management of shared devices like SAS/SATA devices in an > expander or FC devices. The basic problem with power management of > external devices (whether shared or not) is that it's not just what the > host did to them, it's also what the environment or administrator did to > them. Well, think of this as "idle-device" management rather than power management. It's no more host-centric than the existing code in sd_suspend(). When I mentioned sending START-STOP UNIT commands above, that was a bit sloppy. What the code would actually do is call the high-level driver's suspend method, which would then send the appropriate commands to the device. (Or maybe the code would simply call scsi_bus_suspend.) If sending START-STOP UNIT during a suspend is host-centric then sd_suspend() is already guilty. Regarding this thread's original question, the best idea I've come up with so far is to store an extra flag in the scsi_device structure indicating that a suspend or resume transition is underway. When the flag is set, commands with REQ_PREEMPT would be accepted. If the device is "suspended" and the flag is clear, then commands would be delayed or killed in the prep function regardless of REQ_PREEMPT. This scheme could potentially let unwanted commands go through, but I haven't been able to think of anything more suitable. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
