Status of storage autosuspend

Status of storage autosuspend

[Pavel Machek]

Hi!

What is the status of USB storage/SCSI autosuspend patches? They work
nicely here ;-).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Status of storage autosuspend

[Alan Stern]

On Mon, 18 Feb 2008, Pavel Machek wrote:

> Hi!
> 
> What is the status of USB storage/SCSI autosuspend patches? They work
> nicely here ;-).

I could submit them, but there is one outstanding problem I would like
to solve first.  Maybe you can suggest a solution.

The problem is how to handle SG_IOCTL calls.  It seems that the only
safe thing to do is to force an autoresume and prevent the device from
autosuspending until the device file is closed.  Unfortunately the
SG_IOCTL stuff is all handled inside the block layer, and there's no
apparent way (other than some dreadful hack) of passing the necessary
information down to the SCSI layer.

Should we ignore this issue and submit the patches anyway?

Alan Stern

Re: Status of storage autosuspend

[Pavel Machek]

Hi!

> > What is the status of USB storage/SCSI autosuspend patches? They work
> > nicely here ;-).
> 
> I could submit them, but there is one outstanding problem I would like
> to solve first.  Maybe you can suggest a solution.
> 
> The problem is how to handle SG_IOCTL calls.  It seems that the only
> safe thing to do is to force an autoresume and prevent the device from
> autosuspending until the device file is closed.  Unfortunately the
> SG_IOCTL stuff is all handled inside the block layer, and there's no
> apparent way (other than some dreadful hack) of passing the necessary
> information down to the SCSI layer.

Hmm...

> Should we ignore this issue and submit the patches anyway?

I think you should. "Easy" (and clean) solution to that issue is to
just return -EPERM from SG_IOCTL if autosuspend is configured in ;-).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Status of storage autosuspend

[Alan Stern]

On Mon, 18 Feb 2008, Pavel Machek wrote:

> > Should we ignore this issue and submit the patches anyway?
> 
> I think you should. "Easy" (and clean) solution to that issue is to
> just return -EPERM from SG_IOCTL if autosuspend is configured in ;-).

:-)

Okay, I'll update the patches to 2.6.25-rc2 and submit them in a few
days.  (Actually the SCSI patch has to go in first and the usb-storage
patch afterward, which will probably cause it to be delayed one kernel
version.  I don't know any good way to handle these cross-subsystem
updates...)

Alan Stern

Re: Status of storage autosuspend

[Greg KH]

On Mon, Feb 18, 2008 at 10:19:11PM -0500, Alan Stern wrote:
> On Mon, 18 Feb 2008, Pavel Machek wrote:
> 
> > > Should we ignore this issue and submit the patches anyway?
> > 
> > I think you should. "Easy" (and clean) solution to that issue is to
> > just return -EPERM from SG_IOCTL if autosuspend is configured in ;-).
> 
> :-)
> 
> Okay, I'll update the patches to 2.6.25-rc2 and submit them in a few
> days.  (Actually the SCSI patch has to go in first and the usb-storage
> patch afterward, which will probably cause it to be delayed one kernel
> version.  I don't know any good way to handle these cross-subsystem
> updates...)

Push the usb-storage one through the scsi tree as well.  The subsystem
maintainers handle this kind of thing all the time (for example, a sysfs
feature is about to go in through the ocfs tree for this very reason.)

thanks,

greg k-h