On Fri, 18 Oct 2013, Vishal Annapurve wrote: > Hi Alan, > > What I wanted to say was If the bit US_FLIDX_TIMED_OUT can have more > meanings than timed out then maybe it would be best to override the > results after usb-storage is done with the command maybe in scsi layer > itself who aborted it in the first place. US_FLIDX_TIMED_OUT has one very specific meaning: command_abort() was called. Since command_abort() is the .eh_abort_handler routine, US_FLIDX_TIMED_OUT means that the SCSI layer decided to abort the command. Does the SCSI layer ever abort a command for any reason other than a timeout? If not, you may conclude that US_FLIDX_TIMED_OUT indicates a timeout. But if it does, you should not make this conclusion. > My concern was that overriding the result in usb storage or scsi layers > will have more side effects than doing it in scsiglue.c. > And by scsi-usb storage bridge what I meant was specifically the code in > scsiglue. > > Question about your last mail, do you want to change all the occurrences of > DID_ABORT from usb-storage to DID_TIMEOUT? Put it this way: There's no good reason for changing some of them but not all of them. And if you're going to change them at all, it makes no sense to first set the result to DID_ABORT and then change it to DID_TIMEOUT. You should simply set it to DID_TIMEOUT in the first place. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
