Comments embedded below. > -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Alan Stern > Sent: 24. november 2009 23:19 > To: Thomas Søhus > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: RE: Gadget serial and cable detection (in user mode) > > On Tue, 24 Nov 2009, Thomas Søhus wrote: > > > Alan, > > > > Thanks a lot for your reply. > > > > I would like to add a fix for this issue which will be a long term > solution > > that others can also benefit from. Do you think that adding e.g. a > > kobject_uevent() signal to both composite_setup() and > composite_disconnect() > > would be the right solution that can also go upstream? > > No. The right solution should apply to all gadgets, not just composite > gadgets. That means it should be added to all the device controller > drivers. The best way to do this would be as a uevent.c library file > that could be #included in each of the drivers. But you would have to > learn enough about how each driver works in order to make the > appropriate changes. Yes, I agree. That would be a more generic solution. > > > 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. 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. 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. > > > In this way I may not even need the event signaling on cable > detect/remove > > as I can simply wait for data to be available/transmitted again and I > will > > know the link is back up. > > 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). Best regards, Thomas > > 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 > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.709 / Virus Database: 270.14.79/2522 - Release Date: > 11/24/09 08:46:00 -- 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
