From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@ti.com (Felipe Balbi) Date: Wed, 22 Jun 2011 18:19:03 +0300 Subject: [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend In-Reply-To: References: <20110622143216.GE27654@legolas.emea.dhcp.ti.com> Message-ID: <20110622151902.GN27654@legolas.emea.dhcp.ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On Wed, Jun 22, 2011 at 11:02:27AM -0400, Alan Stern wrote: > On Wed, 22 Jun 2011, Felipe Balbi wrote: > > > > In fact, something like this is _necessary_ for all UDC/PHY drivers > > > unless the device can guarantee that it will automatically wake up from > > > suspend in time to service a USB packet (note that the window for > > > responding to a packet is only a few microseconds). Otherwise the > > > device would appear to the host to be unresponsive and broken -- better > > > to do a clean disconnect. > > > > > > If suspending the device while it is in use would cause problems ... > > > then don't suspend it when it is in use! > > > > I second your thoughts, but today we don't have enough infrastructure to > > communicate between PHY and Link, so a clean solution isn't possible, > > right ? > > > > Should we block this patch due to that ? > > No, the patch is appropriate. > > We don't need better communication. If g_mass_storage (for example) > knows that the device is in use, it can block suspends by returning > -EBUSY from its own suspend callback. The UDC driver doesn't need to > worry about these matters; it should assume that such things have > already been handled elsewhere. That's what Dmitry meant when he was > talking about a "higher level driver" -- maybe "lower level" would have > been a better choice of words. :-) > > Until recently, ordering of the suspend callbacks didn't present any > problem. The gadget device was a child of the UDC device and therefore > its suspend callback would always be invoked first. > > With the new UDC framework, I don't know if this is true any more. > It's something to consider. it's still true, but with one extra device in the middle. e.g.: musb is parent to udc-core which is parent to g_zero. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: