Am Dienstag, 31. Januar 2012, 11:02:37 schrieb Bjørn Mork: > The problem here is that wdm_read or wdm_write may be blocking on the > desc->wait waitqueue while holding the desc->lock mutex. Which means > that wdm_pre_reset will have to wait for something else to wake up > wdm_read or wdm_write before it can finish. This is the same problem > which used to be present in wdm_disconnect. Indeed. I assumed that read/write would make progress. The assumption was wrong. > > Now I don't know how I am supposed to trigger a reset, but loading > usb-storage seems to do the trick for devices with mass storage > interfaces. So I'm using that as a trigger. > > I am testing with cdc-wdm from the stable linux-3.2.y branch > (i.e. without any of my recent changes) with the following diff to add > two debug printk's and allow binding to the Huawei modem (I will happily > demonstrate this on the Ericsson modem without any diff at all, if > someone tells me how to trigger a reset): You can use usbfs. Alan has written a tool to do so. http://marc.info/?l=linux-usb-users&m=116827193506484&w=2 > If we're going to take the read/write mutex in pre_reset then we really > need to first set a flag telling wdm_read and wdm_write not to block > with the mutex held, like we do in disconnect. But all this seems > unnecessarily complex. Do we really need to take the locks in reset? We need to make sure nobody does IO to the device while it is being reset. > What problem is this trying to solve? Is it avoiding submitting an urb > in wdm_write? In that case, why not just set the WDM_IN_USE flag? This won't do, because an urb may be in flight. Killing it after setting the flag would race and killing it after setting the flag would also race. And you cannot kill an urb with a lock held. So we really need a flag for resetting. 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
