On Tue, Dec 6, 2016 at 4:35 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > 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. Actually, this is still an outstanding issue, as /sys/class/udc/f72c0000.usb/state seems to be stuck at "configured" no matter the state of the cable, even with my patches. I'll need to look further at the details there. 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
