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. > 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. > 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. 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
