On Fri, Jun 27, 2003 at 04:45:12PM +0100, Ian Abbott wrote: > Hello, > > I have borrowed Greg's changes in the Visor USB serial driver (2.5.x > kernel) that replaces a fixed pool of write urbs with dynamically > allocated write urbs, I want to use the same technique in the > ftdi_sio driver. > > A simple 'dd' command to write several seconds worth of data to the > serial port now returns pretty much instantly (because the > 'chars_in_buffer' function pretends the data is already flushed). > This leaves plenty of time to 'rmmod' the driver module while the > data is still being transmitted, but this causes an Oops, > presumably when the callback function gets called on completion of > an urb.
Yup, don't do that :) > I'm a newbie as far as the 2.5.x kernel is concerned, but MOD_INC... > and MOD_DEC... seem to be frowned upon now, so what's the best way > around this problem? I'm guessing it happens in the Visor driver > too? Yes, this could happen in the visor driver too. As for how to solve this? The module reference count will be incremented when the device is opened, right? Then on close, make sure all urbs are flushed out before finishing the close function. Unfortunatly, this seems to require keeping track of all pending urbs in flight, which is kind of the opposite for doing what the visor driver is doing... There was some proposals for how to fix this in the past on the mailing list, but I don't think they ever went very far. Hope this helps, greg k-h ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
