On Thu, Apr 28, 2011 at 10:05:15AM -0400, Alan Stern wrote: > On Tue, 26 Apr 2011, Oliver Neukum wrote: > > > Am Montag, 25. April 2011, 23:30:38 schrieb Alan Stern: > > > On Mon, 25 Apr 2011, Sarah Sharp wrote: > > > > > > > On Mon, Apr 25, 2011 at 03:18:46PM -0400, Alan Stern wrote: > > > > > On Mon, 25 Apr 2011, Sarah Sharp wrote: > > > > > > > > > > > Random question time. :) > > > > > > > > > > > > Do USB device drivers have to cancel all URBs that are pending for a > > > > > > device before calling usb_reset_device? Will the drivers have to wait > > > > > > for the URBs to complete before resetting the device? > > > > > > > > > > There is no requirement that drivers cancel all URBs before a reset > > > > > occurs. Indeed, some drivers can't because they have no way to know > > > > > when another driver bound to another interface on the same device wants > > > > > to do a reset, i.e., they have no pre_reset callback. > > > > > > > > Ah, ok. Apparently Windows recommends canceling all outstanding > > > > transfers before issuing a port reset, which was apparently what the > > > > chipset folks were hoping Linux also suggested. Oh well. > > > > > > I don't know offhand of any drivers that leave URBs active while doing > > > a reset. But there's no recommendation about it. > > > > Then we should add it. > > If a driver does not implement pre_reset() we call disconnect() which > > does require termination of all IO. > > > > If we call pre_reset() any further IO is unreliable. The assumption they > > are making are quite reasonable. > > I suppose so. How does this look? Looks fine to me. Do we know of any existing drivers that do leave URBs active across resets? I suppose they would be difficult to find if a different driver in a composite device reset the device. I suppose any combination of mass storage and whatever else in a composite device would be an issue. Can we find the drivers and fix them? Sarah Sharp -- 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
