Re: [autosuspend] [ums] spin down the disk in the suspend() method of the storage driver

On Mon, 10 Sep 2007, Oliver Neukum wrote:

> > > You are correct, except for one thing: The change you propose (park
> > > heads, spin down, and then suspend) involves the SCSI disk driver, not
> > > the usb-storage driver.  In fact, the SCSI disk driver already contains 
> > > code to do these things, although I believe you have to enable it by 
> > > hand.
> > 
> > By this logic the autosuspend code in the storage driver is fundamentally
> > flawed. In this case the SCSI layer should propagate down the information
> > that all a bus' devices are spun down.

Or more generally, it should propagate the information that the entire 
SCSI bus is idle and therefore the host adapter may be suspended.  Yes, 
it should.  However the SCSI people haven't gotten that far yet in 
their runtime power-management development.  USB is ahead of them.  :-)

> Sorry for replying to myself. I wasn't fully awake the first time.
> Firstly, you are right, anything else is a layering violation.
> 
> But if we do this our API becomes insufficient. It makes no sense to put
> the USB timeout based API on top of whatever SCSI may use. We need
> a way to specify that an interface doesn't need timeout. It should suspend
> as soon as the counter goes to zero.

I don't see this as a problem.  For one thing, there's no harm in
leaving the USB transport active for an extra few seconds after all the
SCSI-level stuff has been suspended.  After all, there might be USB
traffic that doesn't involve any SCSI activity (lsusb, for example).

For another, we _already_ have a way to get rid of the timeout.  All 
you have to do is set the autosuspend delay to 0.

Alan Stern

P.S.: There are plenty of other difficulties as well.  For example,
flash-based storage devices don't have heads to park and don't need to
spin down, whereas USB-IDE converters usually do.  But there's no
simple way for the kernel to tell them apart -- even HAL would have
trouble and in the end will have to resort to a list of the various
device types.  Nevertheless, the strategies and delays appropriate for
the two types of devices are quite different.

Another wrinkle involves those bus-powered devices which need to have 2
USB connectors in order to obtain sufficient power to run: one for the
usual USB connection and one simply to transfer extra current.  The
extent to which these devices are in compliance with the spec is
questionable, as is the way they will respond to being suspended.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel