On Fri, 30 Jun 2006, Oliver Neukum wrote:
> Am Freitag, 30. Juni 2006 04:17 schrieb Alan Stern:
> > On Thu, 29 Jun 2006, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > does anybody know what error to return from queuecommand for commands
> > > arriving while a device is being suspended?
> >
> > I don't know of anyone who has worried about it yet...
> >
> > You want to tell the SCSI core that your device isn't reachable and it
> > shouldn't attempt to retry the command, right? One way to do that is to
> > set scmd->result = DID_NO_CONNECT << 16 and to call done(scmd), then
> > return 0. That's what usb-storage does when queuecommand is called after
> > the device has been disconnected.
> >
> > Presumably this won't come up very often. If all the children devices are
> > properly suspended first then there shouldn't be any calls to queuecommand
> > while your device is being suspended.
>
> Is this true, even if we are talking about suspending single devices?
Nobody knows! :-)
Seriously, the kernel has _never_ had good support for runtime (i.e.,
selective) suspend. Anyone who uses it does so at their own risk.
> This is how the plan for microtek is looking now:
>
> static int mts_usb_suspend (struct usb_interface *intf, pm_message_t message)
> {
> int rv = 0;
> struct mts_desc* desc = usb_get_intfdata(intf);
>
> spin_lock_irq(desc->susp_lock);
> if (desc->working > 0) {
> rv = -EBUSY;
> } else {
> desc->working = -1;
> scsi_block_requests(desc->host);
> }
> spin_unlock_irq(desc->susp_lock);
>
> return rv;
> }
>
> static int mts_usb_resume (struct usb_interface *intf)
> {
> struct mts_desc* desc;
>
> desc = usb_get_intfdata(intf);
> spin_lock_irq(desc->susp_lock);
> desc->working = 0;
> spin_unlock_irq(desc->susp_lock);
> scsi_unblock_requests(desc->host);
>
> return 0;
> }
>
> But scsi_block_requests() isn't doing any locking.
In the current SCSI implementation it's safe for you to hold the host
spinlock while calling scsi_block_requests(). It's _not_ safe for you to
hold it while calling scsi_unblock_requests(), but that shouldn't matter.
In this situation it's not clear whether blocking requests is the right
thing to do. It might be better to fail them. Or to automatically resume
the device and then carry out the request.
BTW, if your driver has any URBs in flight then it's good form for the
suspend method to block until they are all completed (possibly after
unlinking some of them), instead of returning an error. Of course, this
depends on the nature and structure of the driver.
Alan Stern
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
