On Wed, Dec 7, 2011 at 11:31 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > Oh, I see, thanks. "Possible states would include: unconnected (i.e., no +5 V power), connected, resetting, active, and suspended." Then, from what stage you think is "active", after port change INTR or receive SET_ADDRESS? The user may also would like to use this "status" to check where it is if he/she finds enumeration fails. > Alan Stern > -- BR, Peter Chen -- 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
