Greg KH 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.
Unfortunately, it appears the reset is needed about half way through the
initialization process. First it downloads firmware to an "internal"
rom, then it resets, then it downloads to an "external" rom.
The driver is for wireless 802.11b devices with Atmel 76C502A chips.
Atmel recently made the driver open source, but you have to sign a
Non-Disclosure-Agreement to get access to the documentation. Therefore,
I can't see if there's another way to do it. I'm still trying to see if
they are seeing this problem and if not why.
>
> thanks,
>
> greg k-h
>
>
> -------------------------------------------------------
> 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
>
--
Mitch
-------------------------------------------------------
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
