Alan Stern wrote: >It doesn't seem right to return a code indicating success when in fact we >don't know whether the device reset worked or not. > Scsi layer will do it itself. There is no need to reimplement its logic. If you take a look at scsi various controllers implementation of bus reset you will note that most of them always returns success.
>Perhaps the >bus_reset() routine in scsiglue.c should wait for a short period and then >try to determine if the device was properly reset (how?) before returning >or continuing. > The period can not be short. In my case it takes 1-2 sec, and other devices can work even more slowly. >If something is really wrong with the device, and we keep telling the scsi >layer that it has been reset successfully when in fact it has not, then we >run the risk of getting caught in an endless INQUIRE - fail - reset - >succeed loop. > Scsi layer has a protection against such case. If command fails again after reset, device is put offline ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
