Re: [PATCHv2] usb: musb: Fix unbalanced platform_disable

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org> [160918 23:00]:
> On Sun, 18 Sep 2016 08:19:02 -0700
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> 
> > * Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [160918 05:13]:
> > > 
> > > FYI, while this patch allows me to boot my Panda board with NFS
> > > over usbnet, it only works with cold boots. A warm reboot results
> > > in the following warning, and no ethernet traffic going through.
> > > The USB device is detected by the host though.
> > 
> > Yeah I noticed too that we still have issues. For example doing rmmod
> > of omap2430 with gadget configured and connected will produce a
> > hardirq-safe hardirq-unsafe lock order error. That also happens with
> > reboot with gadget configured and connected.
> > 
> hmm, well, there is a musb_platform_disable() in musb_remove() which is
> simply superfluous...
> Some days ago we had a locking problem with musb_start() and moved
> it out of the locked area. Maybe we could do also something similar
> here.

Well I don't think we can do that safely at this point because we
have unpaired calls to musb_start() and musb_stop(). So trying to
make musb_platform_enable/disable() paired right now will just lead
into mystery breakage in various use cases.

> > So I think the only sane thing to do at this point is to revert the
> > changes trying to enable/disable USB PHY from
> > omap2430_musb_enable/disable. The other fixes are OK too as they get
> > us a bit closer to making the platform glue calls balanced.
> >
> or to balance it there (in a better way as done by my first patch).

We can't do that until we have musb_start() and musb_stop() paired :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html