On Thu, Sep 19, 2002, Mitch Frazier <[EMAIL PROTECTED]> wrote: > > > Johannes Erdfelt wrote: > > On Thu, Sep 19, 2002, Greg KH <[EMAIL PROTECTED]> wrote: > > > >>On Thu, Sep 19, 2002 at 02:30:11PM -0600, Mitch Frazier wrote: > >> > >>>I'm having a problem with a device driver. The driver calls > >>>usb_reset_device() from the driver's probe function. This causes a > >>>deadlock on the semaphore: > >>> > >>> usb_address0_sem -- defined in linux/drivers/usb/hub.c > >>> > >>>My question is: is it legal to call usb_reset_device() from the probe > >>>routine? In other words, is this a driver problem or a usb sub-system > >>>problem? > >> > >>Right now, it's a driver problem. Don't do that! :) > >> > >>Shouldn't the device reset itself? If not, a timer event could cause > >>the device to be reset later on, after probe() returns. > > > > > > usb_address0_sem shouldn't be held that far. It's only needed when the > > device has address 0. > > > > We should be able to drop it after usb_connect, but the code in hub.c > > will need to be modified a little bit. > > > > Does that sound reasonable? > > Yes it does, and I have added a hack in my kernel which allows me to get > the driver working. What I was mainly interested in was finding out if > calling usb_reset_device() was a "reasonable" thing to do from the probe > function. If it is not and the standard usb code remains as-is then I > will need to push harder on the driver writer to find another way of > doing this.
I think it's reasonable to do during the probe function. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
