* Andreas Kemnade <andreas@xxxxxxxxxxxx> [160913 22:46]:
> On Wed, 14 Sep 2016 10:53:10 +0530
> Kishon Vijay Abraham I <kishon@xxxxxx> wrote:
>
> > Hi,
> >
> > On Monday 12 September 2016 08:56 PM, Tony Lindgren wrote:
> > > Hi,
> > >
> > > * Kishon Vijay Abraham I <kishon@a0393678ub> [160910 05:23]:
> > >> On Tue, Aug 23, 2016 at 03:57:24PM -0700, Tony Lindgren wrote:
> > >>> * Andreas Kemnade <andreas@xxxxxxxxxxxx> [160822 12:25]:
> > >>>> setting twl->linkstat = MUSB_UNKNOWN upon error in musb_mailbox
> > >>>> as introduced in
> > >>>> commit 12b7db2bf8b8 ("usb: musb: Return error value from
> > >>>> musb_mailbox") causes twl4030_usb_irq() to not detect a state
> > >>>> change form cable connected to cable disconnected after such an
> > >>>> error so that pm_runtime_put_autosuspend() will not be called
> > >>>> and the usage counter gets unbalanced. Such errors happen e.g.
> > >>>> if the omap2430 module is not (yet) loaded during plug/unplug
> > >>>> events.
> > >>>>
> > >>>> This patch introduces a flag instead that indicates whether
> > >>>> there is information for the musb_mailbox pending and calls
> > >>>> musb_mailbox() if that flag is set.
> > >>>
> > >>> Still works for me for PM:
> > >>>
> > >>> Tested-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > >>
> > >> merged, thanks.
> > >
> > > Just to be sure we're on the same page.. Kishon, this one is needed
> > > as a regression fix for v4.8-rc cycle in addition to the "usb:
> > > musb: Fix unbalanced platform_disable" that I've been working on.
> >
> > Okay. Thank you for letting me know this. I see still there are
> > discussions in the "usb: musb: Fix unbalanced platform_disable"
> > thread. Would it be a problem if this patch goes without the
> > platform_disable patch?
>
> No problem. It can go without it (and my other phy patch can also
> without it).
Yes it can go separately. I will send v3 of the musb fix with
the glue layer changes Bin suggested so Bin can take it.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
