* Andreas Kemnade <andreas@xxxxxxxxxxxx> [160919 22:05]: > On Mon, 19 Sep 2016 09:02:50 -0700 > Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [160918 23:00]: > > > 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. > > > > 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. > > > I am primarily talking about > doing things like the patch > usb: musb: Fix locking errors for host only mode > 2c5575401e34de3d2f > > did for musb_start(), for musb_stop() also. Yeah I know, but that is really just trying to plug holes. The real long term fix seems to to be something like: 1. Add musb_try_start_session/stop_session() that can be called multiple times unpaired and only tinker with the devctl register 2. Make musb_start/stop() paired for the hardware specific init 3. This allows making musb_platform_enable/disable() paired too But for now, we still have issues in v4.8-rc cycle, so let's get that fixed first. 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
