On Fri, Sep 25, 2009 at 08:05:23AM +0200, Oliver Neukum wrote: > Am Donnerstag, 24. September 2009 23:32:39 schrieb Johan Hovold: > > > You can, if you wish to hide what's going on, poison the urb. The > > > correct sequence is: > > > > 1. poison the urb > > > 2. cancel_delayed_work_sync > > > 3. unpoison the urb > > And this is what we generally want to be doing I assume, rather than > > adding an explicit state flag? > > Now that you mention it, it seems like a good idea to me. I just realised that there's been another change in semantics that needs to be addressed: The tty layer can now call serial_unthrottle after serial_close. When this happens the ftdi (and generic) drivers resubmits the killed (or poisoned/unpoisoned) urb. This is actually caught by a warning in usb_serial: WARNING: at drivers/usb/serial/usb-serial.c:441 serial_unthrottle+0x77/0x80 [usbserial]() when it is called with a port count of zero. I guess this should this be fixed in each affected driver, rather than allowing them to rely on the old semantics by adding a check in usb serial_unthrottle? This case could be handled in the drivers' unthrottle() by checking the ASYNC_CLOSING before resubmitting (or, in the ftdi case, adding to the work queue). Apart from this issue, poisoning / unpoisoning the urb on close and always trying to resubmit in the completion handler seems to solve the problems at hand (for ftdi at least). Regards, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
