On Sun, 18 Sep 2016 08:19:02 -0700
Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [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.
> > I'm not sure whether this is a regression introduced by commit
> > a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for
> > 2430 glue layer") or an entirely different issue;
> ...
> > [ 5.711303] [<c0872788>] (_raw_spin_unlock_irqrestore) from
> > [<c069b260>] (musb_gadget_queue+0x128/0x4ac)
> > [ 5.711303] [<c069b260>] (musb_gadget_queue) from [<c06a9ae4>]
> > (usb_ep_queue+0x38/0x1d4)
> > [ 5.729766] [<c06a9ae4>] (usb_ep_queue) from [<c06aba40>]
> > (rx_submit+0xc8/0x19c)
> > [ 5.737548] [<c06aba40>] (rx_submit) from [<c06abb90>]
> > (rx_fill+0x7c/0xa0) [ 5.737548] [<c06abb90>] (rx_fill) from
> > [<c06abbdc>] (eth_start+0x28/0x48) [ 5.751983] [<c06abbdc>]
> > (eth_start) from [<c06abe7c>] (eth_open+0x6c/0x7c) [ 5.751983]
> > [<c06abe7c>] (eth_open) from [<c0778c2c>] (__dev_open+0x9c/0x104)
>
> This could be something else though. Care to email me your .config,
> maybe this is related to legacy g_ether being built in?
>
> Anyways, please also give the following patch a try. The reason why we
> currently have no chance of getting musb_platform_enable/disable
> balanced is because we need to try to set the musb devctl session bit
> in various places and possibly retry too. So musb_start should really
> be called musb_try_start_session() or something.
>
> 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).
Regards,
Andreas
--
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
