On Tue, Dec 6, 2016 at 4:26 PM, John Youn <John.Youn@xxxxxxxxxxxx> wrote: > On 12/6/2016 4:05 PM, John Stultz wrote: >> On Tue, Dec 6, 2016 at 3:17 PM, John Youn <John.Youn@xxxxxxxxxxxx> wrote: >>> Also, do you really need this at all? Wasn't your system previously >>> able to detect the ID pin change correctly via the connection id >>> status change interrupt? This would only be needed if that were not >>> the case. >> >> So it can be made work w/o this, but we needed other hacks because the >> usb-gadget disconnect logic never triggered when the cable was >> unplugged. The controller would jump over to host mode, then when we >> re-plugged in the usb-gadget cable, it would fail often as we never >> got a disconnect signal. That's why earlier I was using this hack to >> force gadget disconnect before the reset was called: >> https://lkml.org/lkml/2016/10/20/26 > > Other than the triggering WARN_ON() in fifo init, is there any other > negative effects? Well, when we see the WARN_ON, it doesn't connect into usb-gadget mode. I had to unplug and re-plug the cable. (The hack I linked to above avoids this, but I suspect its not correct). Also Amit Pundir had mentioned earlier that the UDC sysfs state doesn't get reported correctly since it doesn't register the usb-gadget as unplugged until the cable is re-inserted. > We are revisiting this fifo init code and I think the fifo init is not > necessary for USB_RESET purposes. This should get rid of a race > condition where the EP's are not disabled before attempting to > initialize their FIFO's. Which should get rid of the WARN_ON(). > > If this is the only issue, then this will probably resolve it. (Basically that and the two suspend fixes I sent along in this patchset :). I'd be happy to test anything you're playing with. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
