On Fri, May 18, 2007 at 10:20:51AM -0400, Alan Stern wrote: > > 1) kzalloc() is called, but memory is never freed > > > > Is this a memory leak? I'm not sure, but the buffer is only > > a dummy buffer to hold return data that is never used, > > so I suspect a stack variable will suffice. > > Are you aware that stack-based DMA buffers don't work on all systems?
I was not aware of that, thanks. So kzalloc() needs to stay, and the leak needs to be fixed. > Apparently you don't understand how usb_driver_set_configuration() > works. It doesn't set the configuration immediately; in fact the > Set-Config doesn't happen until after your driver returns. Thank you for the explanation. If I understand correctly, the ssleep() I added is really just delaying the actual set-config (if it actually happens). Are most of these usb function calls queued like this? > usb_reset_configuration() doesn't do a device reset; it does a > Set-Config. Is that what you want? Or do you want to call > usb_reset_device()? I wanted reset_device. If I call usb_reset_device(), and there is a pending usb_set_configuration(), will it still happen in that order? I'll work up a new patch. Interestingly, I did test this, and it worked, even with the wrong call. It could have just been the device I was testing with. I once had a Pearl that definitely needed a reset from userspace, but I don't have it to test with anymore. Thanks, - Chris ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
