On 01/13/2015 11:18 AM, Robert Baldyga wrote: > On 01/12/2015 10:35 PM, Paul Zimmerman wrote: >>> From: Robert Baldyga [mailto:r.baldyga@xxxxxxxxxxx] >>> Sent: Monday, December 22, 2014 6:13 AM >>> >>> I have recently noticed problem with DWC2 driver in latest linux-next. I >>> use it in gadget only mode at Samsung platform (Odroid U3) but I believe >>> the bug can be reproduced at another platforms. >>> >>> While running FFS example (tools/usb/ffs-aio-example/simple/) the >>> communication breaks after few seconds. It's because one of IN requests >>> enqueued in DWC2 driver do not complete. At USB analyzer I see that USB >>> device started to transmit data from this request, but it ended incomplete. >>> >>> I bisected kernel tree, and I got following patches are reason of break. >>> >>> 941fcce usb: dwc2: Update the gadget driver to use common dwc2_hsotg >>> structure >>> 117777b usb: dwc2: Move gadget probe function into platform code >>> bcc0607 usb: dwc2: convert to use dev_pm_ops API >>> 510ffaa usb: dwc2: Initialize the USB core for peripheral mode >>> db8178c usb: dwc2: Update common interrupt handler to call gadget >>> interrupt handler >>> 8d736d8 usb: dwc2: gadget: Do not fail probe if there isn't a clock node >>> >>> Patch 941fcce breaks DWC2 driver at my platform and it starts to work >>> from 8d736d8 but it has described bug. >>> >>> I will try to localize reason of this issue. >> >> Hi Robert, >> >> I think the most likely suspect would be db8178c, since the rest appear >> to be init-time things. It seems to revert cleanly, can you try >> reverting just that patch and see if it helps? >> > > Hi Paul, > > Thanks. It looks like you're right, commit db8178c causes the break. > > I have found out that if we don't call dwc2_is_controller_alive() in > interrupt handler everything works well. Conclusion is that reading from > GSNPSID causes the problem. > > BTW it's strange that this register is used for testing if controller is > alive. Documentation says nothing about that as well as it does not say > that reading this register can affect hardware behaviour. > > Avoiding to read this register in device mode seems to be the simplest > solution. But the question is why does it behave this way? > It looks like calling dwc2_is_controller_alive() under spinlock solves the problem. I will prepare patch. Best regards, Robert Baldyga -- 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
