Hi all, I'm reaching out to more knowledgeable people as I've exhausted my other debug options. We have a custom board with two linux systems connected by USB 3 wires only, vbus and USB2 are omitted for space savings. This has pretty much worked as the controllers are independent, except for the following bug: - When the host system (tegra xhci host driver) reboots, the device (msm-dwc3) enters the U3 state and never leaves it, even after the host powers back up. - Also if the device system happens to finish booting before the host, the same thing happens, dwc3 gets stuck in U3 and never enumerates. I'm able to get these messages from the dwc3 driver when the host reboots [ 34.549834] msm-dwc3 a600000.ssusb: msm_dwc3_pwr_irq received [ 34.555749] msm-dwc3 a600000.ssusb: dwc3_pwr_event_handler irq_stat=28100C [ 34.562902] msm-dwc3 a600000.ssusb: dwc3_pwr_event_handler link state = 0x0006 [ 34.570319] msm-dwc3 a600000.ssusb: dwc3_pwr_event_handler: unexpected PWR_EVNT, irq_stat=281000 [ 34.663734] msm-dwc3 a600000.ssusb: msm_dwc3_pwr_irq received [ 34.669644] msm-dwc3 a600000.ssusb: dwc3_pwr_event_handler irq_stat=2C1004 [ 34.676698] msm-dwc3 a600000.ssusb: dwc3_pwr_event_handler: unexpected PWR_EVNT, irq_stat=2C1000 [ 34.686082] dwc3 a600000.dwc3: dwc3_gadget_suspend_interrupt Entry to 3 [ 34.692919] dwc3 a600000.dwc3: Notify controller from dwc3_gadget_vbus_draw. mA = 2 [ 34.700777] msm-dwc3 a600000.ssusb: DWC3_CONTROLLER_SET_CURRENT_DRAW_EVENT received [ 34.708648] dwc3 a600000.dwc3: Notify OTG from dwc3_gadget_suspend_interrupt [ 34.715888] msm-dwc3 a600000.ssusb: DWC3_CONTROLLER_NOTIFY_OTG_EVENT received I think the main thing I'm looking for is validating my existing understanding and confirming a few things I suspect, but am not sure of due to unfamiliarity with the details of the USB3 spec: - iiuc USB3 power management and states should actually be independent from both vbus and usb2 lines as all the negotiation happens with LFPS over the USB3 wires. - I see that entry to U3 requires an LFPS message, but in this case the host wouldn't have been able to send a message as it is powering off. Is the device also capable of entering U3 due to timeouts and is it expected to enter U3 in this situation? - Similarly I've seen that exiting from U3 requires an LFPS message. My expectation is that the host would wake up all devices on the bus with LFPS messages shortly after bootup, and either this isn't happening, or the device is failing to receive or process the message. If the entry to U3 is expected, how is it then expected to exit U3? I've also tried relevant looking quirks on the gadget side including ssp-u3-u0-quirk, u2exit_lfps_quirk, disable_scramble_quirk. I don't see a way to explicitly prevent the controller from entering U3 mode, is this possible with a register setting? Would appreciate any thoughts. If I haven't misunderstood anything, the next step would probably be to find a beagle 5000 analyzer and track down the LFPS messages. Thanks
