Am Samstag 04 April 2009 17:02:10 schrieb Alan Stern: > 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 OK, this makes sense. > 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? What could generic methods do? 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
