<snip..>
> >@@ -2179,15 +2322,23 @@ static int musb_suspend(struct device *dev)
> > spin_lock_irqsave(&musb->lock, flags);
> >
> > if (is_peripheral_active(musb)) {
> >- /* FIXME force disconnect unless we know USB will wake
> >- * the system up quickly enough to respond ...
> >+ /* System is entering into suspend where gadget would not
> be
> >+ * able to respond to host and thus it will be in an
> unknown
> >+ * state for host. Re-enumeration of gadget is required
> after
> >+ * a resume. So we force a disconnect.
> > */
> >+ reg = musb_readb(musb->mregs, MUSB_POWER);
> >+ reg &= ~MUSB_POWER_SOFTCONN;
> >+ musb_writeb(musb->mregs, MUSB_POWER, reg);
> >+
>
> I think we should only allow suspend if cable isn't connected. What
> would happend if you have mounted fs (using mass storage), user is
> transferring files and you force a disconnect ?
We force a disconnect during suspend which is actually triggered by user
Only. So do we need to consider this scenario?
Moreover, in case of OMAP3, as Smart-Idle/Stdby is enabled so system shouldn't
enter into suspend state if cable is connected and data
transfer is going on.
-Ajay
>
> >diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> >index 83beeac..15a3f27 100644
> >--- a/drivers/usb/musb/omap2430.c
> >+++ b/drivers/usb/musb/omap2430.c
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
