[PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend

[Felipe Balbi]

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: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110622/4af441b7/attachment.sig>