Hi,
On 10/22/2013 08:52 PM, Oliver Neukum wrote:
On Tue, 2013-10-22 at 16:58 +0100, Hans de Goede wrote:
Handle usb-device resets not triggered from uas_eh_bus_reset_handler(), when
this happens, disable cmd queuing during the reset, and wait for existing
requests to finish in pre_reset.
Hm. The most likely reason for resetting a device is a malfunction.
That makes waiting for requests to finish a bit problematic.
Maybe taking steps to forcibly terminate the pending requests
would be better.
Right, but the waiting only happens for an externally triggered reset, on
a scsi subsys initiated reset we already kill all the requests earlier.
Just because another interface has an error requiring a reset does not
necessarily mean their is an issue with the uas interface, and just killing
all inflight transfers and reporting errors back to the scsi subsys is
not going to make the scsi subsys very happy.
Also note that the waiting for completion is exactly the same as what the
usb-storage driver does (by taking the dev_mutex, which it can only do if
any pending command has completed).
Regards,
Hans
--
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
