* Peter Hurley | 2013-03-05 17:20:29 [-0500]: >> Not sure I understood. tty_hangup() is only called from within >> gserial_disconnect() which calls right after usb_ep_disable(). After >> usb_ep_disable() no further serial packets can be received until the >> endpoints are re-enabled. This happens in gserial_connect(). > >That's why I asked. There are two potential issues: > >First, tty_hangup() is asynchronous -- ie., it returns immediately. It >does not wait for the tty device to actually perform the hangup. So if >the gadget layers start cleanup immediately after, expecting that they >won't get a flurry of tty calls, that would be bad. tty_hangup() is called from interrupt context usually after the USB cable has been unplugged. It is also possible that if the host requests the function twice, it will (on the second invocation without a reset) call tty_hangup() followed by tty_wakeup() to start the new session. > >tty_vhangup() is synchronous -- ie., you wait while it cleans up. This >is what the usb serial core does on it's disconnect() method. But I >didn't research further if the circumstances were the same. Okay. >Second, when the hangup actually does run -- in __tty_hangup() -- it >expects the tty to exist. I didn't go looking through the gadget layers >to see if the tty was disposed some other way, which might race the >asynchronous tty hangup. It calls wake_up_interruptible() expecting the user to leave. The node is removed on module removal. Is there any change of API you suggest? >Thanks, >Peter Hurley Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
