On Wed, 7 Dec 2011, Felipe Balbi wrote: > On Mon, Dec 05, 2011 at 01:12:25PM -0500, Alan Stern wrote: > > 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. > > Yes, I'm just concerned if that's something that should be part of > gadget or PHY layer. What happens on devices that don't have a PHY driver? > It can be done on both places, easily, and I like > your idea for the contents. Will see what I can do quickly. Maybe just > add a "status" enumeration to struct usb_udc and add a udc_set_status() > call which will update that field and sysfs_notify() the correct > attribute. How does that sound ? Yes, that seems like the right way to go. > UDC drivers would be required to call > that correctly though. True; that will be the tricky part. On Wed, 7 Dec 2011, Peter Chen wrote: > Yes, just like we do for speed, we can add "status" at struct usb_gadget, > and create sys entry at udc-core.c. > The question is how many status are needed? > connected/reset/addressed/suspended/disconnected? See what I wrote above. 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
