On Mon, 5 Dec 2011, Sebastian Andrzej Siewior wrote: > > Felipe, Sebastian, this sounds like a good candidate for something to > > be added to the UDC core framework. Perhaps a pollable sysfs file > > containing the current connection/PHY status? The UDC driver would > > merely have to invoke a new core routine whenever the status changed. > > So what do we want? > > We do have a disconnect callback (gadget_driver->disconnect) where the > udc driver should tell the gadget when we lost the link. So in theory > we know when we lost the link partner by force. > After the USB-Reset the udc-driver knows that it is connected again. > But a good cell phone or bad cables can lead a USB-Reset as well. That's okay. If the UDC/gadget drivers think the connection is bouncing, the sysfs file should reflect that information to userspace. > If you are connected to self-powered HUB and you re-plug it from one > computer to another the udc does only notice that something changed due > to the USB-Reset, right? When the hub is unplugged, it disables its downstream ports. To the gadget, this should appear as a USB suspend. > So I think looking at the speed attribute is the best thing we can do. > If we route a few callbacks through udc-core we could make speed > attribute poll able. Every speed change, results in re-enumeration and > this could be a cable plug. Possible states would include: unconnected (i.e., no +5 V power), connected, resetting, active, and suspended. Some PHYs might expose other states, such as charging. OTG devices could even have a host-mode state. If we expose a PHY/connection state attribute and a speed attribute, that ought to satisfy everybody. 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
