Resend this mail in plain text. Hello Felipe, We’ve found on some Layerscape platforms which integrating DWC3 USB3.0 DRD controller, VBUS glitch happened and caused some USB drives enumeration fail, like to discuss the details as below. Story is that, we found once function dwc3_core_init_mode() got called and enabled host mode by calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST) which would write register [DWC3_GCTL] bit 12~13, so the pin (such as USB_DRVVBUS) which control VBUS driving chip’s EN pin would be pulled high immediately, so did the VBUS (up to +5V). Then, DWC3 core driver continued to call function dwc3_host_init()->platform_device_add(xhci)… xhci_plat_probe()->usb_add_hcd()->xhci_plat_setup()->xhci_gen_setup-> xhci_reset(), which would reset xHCI controller. At this point, the VBUS EN pin (USB_DRVVBUS) was pulled low for about 15us, causing the VBUS did the same drop too, then back to normal voltage when HW reset complete. We have confirmed this whole process according to scope waveform with test code on DWC3 driver. Impact is that VBUS glitch has let some USB drives (such as Transcend 4GB USB2.0 (jetflash) and Kingston 16GB USB2.0 DTGE9) malfunction during enumeration (particularly happen when drive is connected to root-hub port prior to Linux boot). Per my understanding, VBUS need to keep +5V once enabled without any drop/unstable. And above glitch looks like caused by the gap between DWC3 design and driver init procedure. One of probably workaround come to my mind is to program all root-hub ports’ PORTSC[PP] to 0b immediately after enabling host mode (calling dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST)), so VBUS will keep 0V till xhci is reset by xhci driver like above. I have test this and it works. I know it is not an good fix because DWC3 core driver would touch xHCI controller which ought to be handled by xHCI driver instead, so like to send out this mail for discussion first, see if anyone has better solution on this issue. Thanks for your time. Regards, Ran
