On Sat, 4 Apr 2009, Oliver Neukum wrote: > Am Samstag 04 April 2009 10:55:23 schrieb Hal Murray: > > tom.leiming@xxxxxxxxx said: > > > IMO, the deadlock is caused by mutex_lock(&port->serial->disc_mutex) > > > (called in garmin_close() and usb_serial_disconnect() ). The garmin > > > usb_driver doesn't define .pre_reset and .post_reset, so > > > usb_reset_devie() will unbound garmin usb_driver before doing bus > > > reset, which makes .disconnect() called, then deadlock happens. > > Alan, > > this looks like a generic problem to me. Any suggestions? Is it really so generic? As Ming Lei pointed out, why does garmin_gps do a device reset while holding serial->disc_mutex? This is a recipe for disaster. In fact, why do a reset in the close method at all? If a reset really is needed, why not do it as soon as the driver realizes it is needed? Why wait until the device file is closed (which could be an arbitrarily long time later)? In any case, shouldn't the generic layer contain pre_reset and post_reset routines? And shouldn't these routines be listed in the usb_driver structure for each of the subdrivers? Alan Stern -- 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
