On Thu, 15 Jan 2004, Stavros Markou wrote:destroy_configuration and get_configuration are taken from the current stable kernel.
First of all, I want to thank you and Alan for your help. Second for the drivers I am developing and In order to be independent from a kernel 's usb_reset_device (since it doesn't work for the moment and the users of the driver don't want to mess with the kernel too much) I 've put a small portion of
kernel usb code inside a file called kernel_usb_reset.c that I attach it to this mail. Inside this file I 've made some changes to usb_physical_reset_device (__usb_reset_device) and I 've included some functions in order to complete succesfully the reset of the device. Inside the kernel, usb_physical_reset_device stops when it puts down the usb0_address_sem and leaves the system hanging. All seems to be fine after my reset_device the card as network device is fully functional . When I try to hot_unplug the device, and I believe usb_disconnect function is called then, I get a NULL pointer reference that leaves the system
with pending urbs etc.
I took a quick look at your file. Making reset_device() call destroy_configuration() and get_configuration() like you do is very unsafe. No wonder you're getting kernel panics!
This entire part of the USB subsystem is under active development at the moment. Any changes you make will most likely be superseded in the near future. Although you may not like it, my best advice for now is just to wait until the updates are written.I can do that. The users of the driver not :-) .
Here's an alternate approach you could try. Create a userspace driver that uses libfs or usbfs to take care of the DFU and device reset. Once that's done, load your kernel driver and let it carry on.I want the procedure to be transparent for the simple user. How can I achieve that with two drivers (user-space, kernel-space)?
In the future if anything happens to a usb device like a failure to a command over the control endpoint then the driver will be able to reset the device ?
Alan Stern
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
