On Tue, 3 Jan 2012, Oliver Neukum wrote: > > The USB suspend/resume function does that "unbind/rebind" dance, and > > that causes a "device_attach()". Which causes a probe() to be called. > > > > Should it do that? I think not, not if the ID's haven't changed. But I > > don't know the USB layer all that well. > > The ID has changed. That is why we run into this problem. > And indeed the USB layer does the rebind only if either > > a) ID has changed That's not true, or at least, it shouldn't be true. If the ID has changed then there's nothing to rebind. The old device is gone; it cannot be resumed or rebound at all. That's the theory, and indeed things really do work that way during reset-resume. Now, during an ordinary resume, the USB core does not check IDs. It assumes that if suspend power was provided to the bus and the device was connected to the bus the entire time, then the device remains unchanged. Perhaps this assumption is a mistake, but so far I haven't seen any data to prove that it is. > b) the driver tells us that it cannot deal with a device that has lost its state This case applies only in situations where the driver doesn't have a reset_resume method. The uvc driver does have one. (You left out a third case: The driver doesn't have any suspend/resume methods. But this case applies only when the device has not lost its state, and besides, the uvc driver does have these methods.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
