On Tue, 24 Nov 2009, Thomas Søhus wrote: > > > The main reason why I need cable detection is, that whenever the > > cable has > > > been disconnected the data link is broken and I have to re-open the > > gadget > > > serial device file, in order to re-establish the link. Maybe we can > > fix the > > > gadget serial driver so that re-opening the device is not needed? > > > > Why? If you get a hangup event on a normal serial device, you can't > > re-establish the link without re-opening the device file. I think > > g_serial should behave the same way. > > The Gadget serial needs to work a real embedded device/gadget. So it need to > be able to autonomously attach when the link is ready again. I would not > know when to re-open the device file, since I don't have any idea when the > cable is attached. Suppose instead of using g_serial, your embedded device used an actual serial line. How would the program work then? It should work the same way with g_serial. > Actually I have noticed that: 1. you can open the port without the cable > being plugged 2. Insert the cable 3. Successfully transmit data. > This is however not possible if you disconnect/reconnect the cable during > the communication. I find this a bit "inconsistent", and hence I concluded > that this is probably not intended behavior. No, it is. Hangup (or equivalently, USB disconnect for serial gadgets) acts as a kind of "secure attention event". Normal serial connections behave exactly the same way, intentionally. Suppose you had a connection that was being used to transmit highly secure data. Suppose the USB cable was disconnected, and an intruder connected the cable up to their own computer. If the serial connection remained open, the intruder would then be able to copy and steal all the confidential data the program would still be sending. That's why USB disconnects or serial hangups behave as they do. > Writing the above actually lead to a possible work-around: Once the > connection is lost, I can close the port and open it again right away. Then > I will wait until data is successfully transmitted and I will know that the > link is back up again. It should work but I find it as a "work around" and I > find it cleaner to have events for signaling this. It is not a workaround; it is the correct way to use the serial interface. But you shouldn't have to wait until data is successfully transmitted; there should be a more direct way to tell when a connection has been re-established. A normal serial device would turn on the DCD setting. Or maybe you don't have to wait for anything; just start sending data. It will accumulate inside the kernel until a connection is established. > > Does g_serial use the modem handshaking lines to represent the presence > > of absence of a USB connection? If it doesn't, maybe you can change it > > so that it does. Then applications could check the modem status just > > as they do for normal serial devices. > > > I don't think so. I think the RTS/CTS settings are ignored for g_serial (Not > completely sure though). Maybe you could change that. Or add support for DCD. Alan Stern -- 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
