Am Samstag, 3. Dezember 2011, 00:41:34 schrieb Sarah Sharp: > On Fri, Dec 02, 2011 at 04:35:08PM -0500, Alan Stern wrote: > > On Fri, 2 Dec 2011, Sarah Sharp wrote: > > You do need to decide what to do about commands that are in flight. > > Ideally you would wait until they all complete by themselves (or are > > aborted by the error handler, which amounts to the same thing). > > Actively cancelling their URBs in preparation for the reset is not as > > safe, although it is necessary when things time out or aborts fail. > > It's true that another interface driver could want to reset the USB > device, not just the UAS driver. But is there a way to tell the > difference without adding code to the UAS driver? A reset is used almost always in error handling. It is quite likely that your driver and the other driver want to reset the device for the same reason. [..] > I'm also not sure we can just wait for the commands to complete. Since > the device chooses which streams to request data for (and thus which > SCSI commands to service), it's entirely possible the device could just > starve a particular command indefinitely due to some fireware bug. So > another driver asks for a reset, we let the commands complete on their > own (while not submitting new commands), the starved SCSI command It is probably not a bad idea to take the hint when another driver wants to reset. In particular I wouldn't trust the device to correctly execute commands when some driver has requested a reset. IMHO you want to give the upper layers a chance to retry. Regards Oliver -- 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
