| Message ID | 20240603131304.233403-1-mike.looijmans@topic.nl |
|---|---|
| State | New |
| Headers | show |
| Series | usb: dwc3: gadget: Inform system of suspended state | expand |
On 04-06-2024 03:03, Thinh Nguyen wrote: > Hi, > > On Mon, Jun 03, 2024, Mike Looijmans wrote: >> When disconnecting the USB cable on an LS1028 device, nothing happens >> in userspace, which keeps thinking everything is still up and running. >> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >> expect. As a result, sysfs attribute "state" remains "configured" >> until something resets it. >> >> Forward the "suspended" state to sysfs, so that the "state" at least >> changes into "suspended" when one removes the cable, and hence also >> matches the gadget's state when really suspended. > On disconnection, did you see disconnect interrupt? If so, it should > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > address your issue. Can you provide the driver tracepoints? The device doesn't issue a disconnect event, I didn't have tracing enabled in the kernel but added some dev_info() calls to determine what was going on. Added this to dwc3_process_event_entry(): dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); When disconnecting the cable from the host, I see this: [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 The "0x4086" and "0x6084" messages are endpoint events that occur all the time while connected. The last event is the "suspend" one. After that, total silence. If you need traces, please point me to a description on how to obtain them. > > Thanks, > Thinh > >> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> >> --- >> >> drivers/usb/dwc3/gadget.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> index 4df2661f6675..99e8ea9db600 100644 >> --- a/drivers/usb/dwc3/gadget.c >> +++ b/drivers/usb/dwc3/gadget.c >> @@ -4343,6 +4343,7 @@ static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc, >> if (!dwc->suspended && next == DWC3_LINK_STATE_U3) { >> dwc->suspended = true; >> dwc3_suspend_gadget(dwc); >> + usb_gadget_set_state(dwc->gadget, USB_STATE_SUSPENDED); >> } >> >> dwc->link_state = next; >> -- >> 2.34.1 >> >> >> Met vriendelijke groet / kind regards, >> >> Mike Looijmans
On 6/4/2024 10:56 AM, Mike Looijmans wrote: > On 04-06-2024 03:03, Thinh Nguyen wrote: >> Hi, >> >> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>> When disconnecting the USB cable on an LS1028 device, nothing happens >>> in userspace, which keeps thinking everything is still up and running. >>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>> expect. As a result, sysfs attribute "state" remains "configured" >>> until something resets it. >>> >>> Forward the "suspended" state to sysfs, so that the "state" at least >>> changes into "suspended" when one removes the cable, and hence also >>> matches the gadget's state when really suspended. >> On disconnection, did you see disconnect interrupt? If so, it should >> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >> address your issue. Can you provide the driver tracepoints? > > The device doesn't issue a disconnect event, I didn't have tracing > enabled in the kernel but added some dev_info() calls to determine what > was going on. Added this to dwc3_process_event_entry(): > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > When disconnecting the cable from the host, I see this: > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > The "0x4086" and "0x6084" messages are endpoint events that occur all > the time while connected. The last event is the "suspend" one. After > that, total silence. > > If you need traces, please point me to a description on how to obtain them. > > Hi Mike, I may be wrong, but can you help understand the mechanism as to how disconnect interrupt is generated in your targets. For example, on QC SoC's, this happens when HS_PHY_CTRL reg VBUS_VALID bit is cleared and cable is disconnected. This is because the vbus line is not routed to controller. But from my calls with Synopsys previously, I remember that the vbus line is routed to the controller as well for other OEMs. In your SoC, what is the indication to controller that vbus is absent ? Also, after this happens, do you see the next plug in working ? Regards, Krishna,
On 04-06-2024 08:45, Krishna Kurapati PSSNV wrote: > > > On 6/4/2024 10:56 AM, Mike Looijmans wrote: >> On 04-06-2024 03:03, Thinh Nguyen wrote: >>> Hi, >>> >>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>> in userspace, which keeps thinking everything is still up and running. >>>> Turns out that the DWC3 controller only sends >>>> DWC3_DEVICE_EVENT_SUSPEND >>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>> expect. As a result, sysfs attribute "state" remains "configured" >>>> until something resets it. >>>> >>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>> changes into "suspended" when one removes the cable, and hence also >>>> matches the gadget's state when really suspended. >>> On disconnection, did you see disconnect interrupt? If so, it should >>> transition to USB_STATE_NOATTACHED. This change doesn't seem to >>> directly >>> address your issue. Can you provide the driver tracepoints? >> >> The device doesn't issue a disconnect event, I didn't have tracing >> enabled in the kernel but added some dev_info() calls to determine >> what was going on. Added this to dwc3_process_event_entry(): >> >> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, >> event->type.type); >> >> When disconnecting the cable from the host, I see this: >> >> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >> >> The "0x4086" and "0x6084" messages are endpoint events that occur all >> the time while connected. The last event is the "suspend" one. After >> that, total silence. >> >> If you need traces, please point me to a description on how to obtain >> them. >> >> > > Hi Mike, > > I may be wrong, but can you help understand the mechanism as to how > disconnect interrupt is generated in your targets. For example, on QC > SoC's, this happens when HS_PHY_CTRL reg VBUS_VALID bit is cleared and > cable is disconnected. This is because the vbus line is not routed to > controller. But from my calls with Synopsys previously, I remember > that the vbus line is routed to the controller as well for other OEMs. > In your SoC, what is the indication to controller that vbus is absent ? > The board I'm testing this on is an LS1028ARDB. Looking at the schematic, VBUS is routed to the chip. There's also an LED attached to it, which turns off when I unplug the cable. In the devicetree, I can't see any hint of NXP-specific "glue" in the DWC3 entries, so it uses the controller "as is": compatible = "fsl,ls1028a-dwc3", "snps,dwc3"; reg = <0x0 0x3100000 0x0 0x10000>; snps,dis_rxdet_inp3_quirk; snps,quirk-frame-length-adjustment = <0x20>; snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>; The "fsl,ls1028a-dwc3" keyword doesn't actually occur anywhere in the kernel, so it uses plain "snps,dwc3". > Also, after this happens, do you see the next plug in working ? Next plugin works, because of a "reset" event at that point that makes everything happy again. The state remains in "configured" while the cable is out. Plugging the cable back in makes it revert to "default" first, then it goes back into "configured".
On 6/4/2024 1:55 PM, Mike Looijmans wrote: > On 04-06-2024 08:45, Krishna Kurapati PSSNV wrote: >> >> >> On 6/4/2024 10:56 AM, Mike Looijmans wrote: >>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>> Hi, >>>> >>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>> in userspace, which keeps thinking everything is still up and running. >>>>> Turns out that the DWC3 controller only sends >>>>> DWC3_DEVICE_EVENT_SUSPEND >>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>> until something resets it. >>>>> >>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>> changes into "suspended" when one removes the cable, and hence also >>>>> matches the gadget's state when really suspended. >>>> On disconnection, did you see disconnect interrupt? If so, it should >>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to >>>> directly >>>> address your issue. Can you provide the driver tracepoints? >>> >>> The device doesn't issue a disconnect event, I didn't have tracing >>> enabled in the kernel but added some dev_info() calls to determine >>> what was going on. Added this to dwc3_process_event_entry(): >>> >>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, >>> event->type.type); >>> >>> When disconnecting the cable from the host, I see this: >>> >>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>> >>> The "0x4086" and "0x6084" messages are endpoint events that occur all >>> the time while connected. The last event is the "suspend" one. After >>> that, total silence. >>> >>> If you need traces, please point me to a description on how to obtain >>> them. >>> >>> >> >> Hi Mike, >> >> I may be wrong, but can you help understand the mechanism as to how >> disconnect interrupt is generated in your targets. For example, on QC >> SoC's, this happens when HS_PHY_CTRL reg VBUS_VALID bit is cleared and >> cable is disconnected. This is because the vbus line is not routed to >> controller. But from my calls with Synopsys previously, I remember >> that the vbus line is routed to the controller as well for other OEMs. >> In your SoC, what is the indication to controller that vbus is absent ? >> > The board I'm testing this on is an LS1028ARDB. Looking at the > schematic, VBUS is routed to the chip. There's also an LED attached to > it, which turns off when I unplug the cable. > > In the devicetree, I can't see any hint of NXP-specific "glue" in the > DWC3 entries, so it uses the controller "as is": > > compatible = "fsl,ls1028a-dwc3", "snps,dwc3"; > reg = <0x0 0x3100000 0x0 0x10000>; > snps,dis_rxdet_inp3_quirk; > snps,quirk-frame-length-adjustment = <0x20>; > snps,incr-burst-type-adjustment = <1>, <4>, > <8>, <16>; > > The "fsl,ls1028a-dwc3" keyword doesn't actually occur anywhere in the > kernel, so it uses plain "snps,dwc3". > > >> Also, after this happens, do you see the next plug in working ? > > Next plugin works, because of a "reset" event at that point that makes > everything happy again. Ahh, got it. Thanks for the info. I ran into a similar issue before where disconnect isn't generated [1] and was suspecting it could be the case here but it isn't. [1]: https://patchwork.kernel.org/project/linux-usb/patch/20231011100214.25720-1-quic_kriskura@quicinc.com/ Regards, Krishna, > > The state remains in "configured" while the cable is out. Plugging the > cable back in makes it revert to "default" first, then it goes back into > "configured". >
Hi, On Tue, Jun 04, 2024, Mike Looijmans wrote: > On 04-06-2024 03:03, Thinh Nguyen wrote: > > Hi, > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > in userspace, which keeps thinking everything is still up and running. > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > expect. As a result, sysfs attribute "state" remains "configured" > > > until something resets it. > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > changes into "suspended" when one removes the cable, and hence also > > > matches the gadget's state when really suspended. > > On disconnection, did you see disconnect interrupt? If so, it should > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > address your issue. Can you provide the driver tracepoints? > > The device doesn't issue a disconnect event, I didn't have tracing enabled > in the kernel but added some dev_info() calls to determine what was going > on. Added this to dwc3_process_event_entry(): > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > When disconnecting the cable from the host, I see this: > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > time while connected. The last event is the "suspend" one. After that, total > silence. > > If you need traces, please point me to a description on how to obtain them. > > Let me know if you run into issues following this instructions to capture the tracepoints: https://docs.kernel.org/driver-api/usb/dwc3.html#required-information From the patch you provided, you only apply the change for the usb suspend. But did your device go through system suspend? If that's the case, then the dwc3 driver will cause a soft-disconnect. Currently that will not prompt a state change. We need the tracepoint to know more detail. Until we have the tracepoints, you can experiment with this test patch. If my suspiction is correct, then this may resolve your issue: diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..29dbb889a0e2 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2682,6 +2682,8 @@ static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc) */ ret = dwc3_gadget_run_stop(dwc, false); + usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED); + /* * Stop the gadget after controller is halted, so that if needed, the * events to update EP0 state can still occur while the run/stop -- Thanks, Thinh
On 05-06-2024 01:06, Thinh Nguyen wrote: > Hi, > > On Tue, Jun 04, 2024, Mike Looijmans wrote: >> On 04-06-2024 03:03, Thinh Nguyen wrote: >>> Hi, >>> >>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>> in userspace, which keeps thinking everything is still up and running. >>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>> expect. As a result, sysfs attribute "state" remains "configured" >>>> until something resets it. >>>> >>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>> changes into "suspended" when one removes the cable, and hence also >>>> matches the gadget's state when really suspended. >>> On disconnection, did you see disconnect interrupt? If so, it should >>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>> address your issue. Can you provide the driver tracepoints? >> The device doesn't issue a disconnect event, I didn't have tracing enabled >> in the kernel but added some dev_info() calls to determine what was going >> on. Added this to dwc3_process_event_entry(): >> >> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >> >> When disconnecting the cable from the host, I see this: >> >> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >> >> The "0x4086" and "0x6084" messages are endpoint events that occur all the >> time while connected. The last event is the "suspend" one. After that, total >> silence. >> >> If you need traces, please point me to a description on how to obtain them. >> >> > Let me know if you run into issues following this instructions to > capture the tracepoints: > https://docs.kernel.org/driver-api/usb/dwc3.html#required-information I've attached the traces as a tarball. Hope it survives. At the start, the USB is up and running (and doing ethernet+mass storage). I saved the trace after pulling the USB cable.
On 05-06-2024 01:06, Thinh Nguyen wrote: > Hi, > > On Tue, Jun 04, 2024, Mike Looijmans wrote: >> On 04-06-2024 03:03, Thinh Nguyen wrote: >>> Hi, >>> >>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>> in userspace, which keeps thinking everything is still up and running. >>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>> expect. As a result, sysfs attribute "state" remains "configured" >>>> until something resets it. >>>> >>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>> changes into "suspended" when one removes the cable, and hence also >>>> matches the gadget's state when really suspended. >>> On disconnection, did you see disconnect interrupt? If so, it should >>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>> address your issue. Can you provide the driver tracepoints? >> The device doesn't issue a disconnect event, I didn't have tracing enabled >> in the kernel but added some dev_info() calls to determine what was going >> on. Added this to dwc3_process_event_entry(): >> >> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >> >> When disconnecting the cable from the host, I see this: >> >> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >> >> The "0x4086" and "0x6084" messages are endpoint events that occur all the >> time while connected. The last event is the "suspend" one. After that, total >> silence. >> >> If you need traces, please point me to a description on how to obtain them. >> >> > Let me know if you run into issues following this instructions to > capture the tracepoints: > https://docs.kernel.org/driver-api/usb/dwc3.html#required-information > > From the patch you provided, you only apply the change for the usb > suspend. But did your device go through system suspend? If that's the > case, then the dwc3 driver will cause a soft-disconnect. Currently that > will not prompt a state change. We need the tracepoint to know more > detail. > > Until we have the tracepoints, you can experiment with this test patch. > If my suspiction is correct, then this may resolve your issue: > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 89fc690fdf34..29dbb889a0e2 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -2682,6 +2682,8 @@ static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc) > */ > ret = dwc3_gadget_run_stop(dwc, false); > > + usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED); > + > /* > * Stop the gadget after controller is halted, so that if needed, the > * events to update EP0 state can still occur while the run/stop I tried the patch above, but it doesn't work. Apparently dwc3_gadget_soft_disconnect() doesn't get called when I unplug the cable.
On Wed, Jun 05, 2024, Mike Looijmans wrote: > On 05-06-2024 01:06, Thinh Nguyen wrote: > > Hi, > > > > On Tue, Jun 04, 2024, Mike Looijmans wrote: > > > On 04-06-2024 03:03, Thinh Nguyen wrote: > > > > Hi, > > > > > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > > > in userspace, which keeps thinking everything is still up and running. > > > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > > > expect. As a result, sysfs attribute "state" remains "configured" > > > > > until something resets it. > > > > > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > > > changes into "suspended" when one removes the cable, and hence also > > > > > matches the gadget's state when really suspended. > > > > On disconnection, did you see disconnect interrupt? If so, it should > > > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > > > address your issue. Can you provide the driver tracepoints? > > > The device doesn't issue a disconnect event, I didn't have tracing enabled > > > in the kernel but added some dev_info() calls to determine what was going > > > on. Added this to dwc3_process_event_entry(): > > > > > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > > > > > When disconnecting the cable from the host, I see this: > > > > > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > > > > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > > > time while connected. The last event is the "suspend" one. After that, total > > > silence. > > > > > > If you need traces, please point me to a description on how to obtain them. > > > > > > > > Let me know if you run into issues following this instructions to > > capture the tracepoints: > > https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ > I've attached the traces as a tarball. Hope it survives. Got them. Thanks. > > At the start, the USB is up and running (and doing ethernet+mass storage). I > saved the trace after pulling the USB cable. > From the capture, we can see that there's no system suspend, so there's no soft-disconnect. Base on the suspend event, you're running in usb2 speed (ignore the incorrect U3 state, should be L2): irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] The DSTS from the regdump indicated that you're still in L2 despite disconnected. Looks like the phy was unable to detect and wakeup from the disconnection to notify the controller. Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable usb2 phy suspend. Does your device support SuperSpeed? If so, do you observe the same behavior while operating in SuperSpeed? Thanks, Thinh
On Wed, Jun 05, 2024, Mike Looijmans wrote: > On 05-06-2024 01:06, Thinh Nguyen wrote: > > Hi, > > > > On Tue, Jun 04, 2024, Mike Looijmans wrote: > > > On 04-06-2024 03:03, Thinh Nguyen wrote: > > > > Hi, > > > > > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > > > in userspace, which keeps thinking everything is still up and running. > > > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > > > expect. As a result, sysfs attribute "state" remains "configured" > > > > > until something resets it. > > > > > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > > > changes into "suspended" when one removes the cable, and hence also > > > > > matches the gadget's state when really suspended. > > > > On disconnection, did you see disconnect interrupt? If so, it should > > > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > > > address your issue. Can you provide the driver tracepoints? > > > The device doesn't issue a disconnect event, I didn't have tracing enabled > > > in the kernel but added some dev_info() calls to determine what was going > > > on. Added this to dwc3_process_event_entry(): > > > > > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > > > > > When disconnecting the cable from the host, I see this: > > > > > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > > > > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > > > time while connected. The last event is the "suspend" one. After that, total > > > silence. > > > > > > If you need traces, please point me to a description on how to obtain them. > > > > > > > > Let me know if you run into issues following this instructions to > > capture the tracepoints: > > https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!epxtPmXHiizMg5_5igEYiKU483OZb1zcYK1M3afqXxIfgsw_cU_kdz9Rlpf1w-30JF0v4UUkxBViJtx4Prv3ZWchjKNHkKE$ > > > > From the patch you provided, you only apply the change for the usb > > suspend. But did your device go through system suspend? If that's the > > case, then the dwc3 driver will cause a soft-disconnect. Currently that > > will not prompt a state change. We need the tracepoint to know more > > detail. > > > > Until we have the tracepoints, you can experiment with this test patch. > > If my suspiction is correct, then this may resolve your issue: > > > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > > index 89fc690fdf34..29dbb889a0e2 100644 > > --- a/drivers/usb/dwc3/gadget.c > > +++ b/drivers/usb/dwc3/gadget.c > > @@ -2682,6 +2682,8 @@ static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc) > > */ > > ret = dwc3_gadget_run_stop(dwc, false); > > + usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED); > > + > > /* > > * Stop the gadget after controller is halted, so that if needed, the > > * events to update EP0 state can still occur while the run/stop > > I tried the patch above, but it doesn't work. Apparently > dwc3_gadget_soft_disconnect() doesn't get called when I unplug the cable. > Thanks for testing. There's no system suspend, so that's expected. BR, Thinh
On 06-06-2024 02:28, Thinh Nguyen wrote: > On Wed, Jun 05, 2024, Mike Looijmans wrote: >> On 05-06-2024 01:06, Thinh Nguyen wrote: >>> Hi, >>> >>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>> until something resets it. >>>>>> >>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>> matches the gadget's state when really suspended. >>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>> address your issue. Can you provide the driver tracepoints? >>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>> in the kernel but added some dev_info() calls to determine what was going >>>> on. Added this to dwc3_process_event_entry(): >>>> >>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>> >>>> When disconnecting the cable from the host, I see this: >>>> >>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>> >>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>> time while connected. The last event is the "suspend" one. After that, total >>>> silence. >>>> >>>> If you need traces, please point me to a description on how to obtain them. >>>> >>>> >>> Let me know if you run into issues following this instructions to >>> capture the tracepoints: >>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >> I've attached the traces as a tarball. Hope it survives. > > Got them. Thanks. > >> >> At the start, the USB is up and running (and doing ethernet+mass storage). I >> saved the trace after pulling the USB cable. >> > > From the capture, we can see that there's no system suspend, so there's > no soft-disconnect. > > Base on the suspend event, you're running in usb2 speed (ignore the > incorrect U3 state, should be L2): > > irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] > > The DSTS from the regdump indicated that you're still in L2 despite > disconnected. Looks like the phy was unable to detect and wakeup from > the disconnection to notify the controller. > > Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable > usb2 phy suspend. Will do. > > Does your device support SuperSpeed? If so, do you observe the same > behavior while operating in SuperSpeed? It does, and it does. The setup is SuperSpeed capable, and usually connects at this speed, but I didn't explicitly check if it set up a SS link for this particular trace. The behavior is always the same, regardless of whether it's in super or just high speed.
On 06-06-2024 02:28, Thinh Nguyen wrote: > On Wed, Jun 05, 2024, Mike Looijmans wrote: >> On 05-06-2024 01:06, Thinh Nguyen wrote: >>> Hi, >>> >>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>> until something resets it. >>>>>> >>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>> matches the gadget's state when really suspended. >>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>> address your issue. Can you provide the driver tracepoints? >>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>> in the kernel but added some dev_info() calls to determine what was going >>>> on. Added this to dwc3_process_event_entry(): >>>> >>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>> >>>> When disconnecting the cable from the host, I see this: >>>> >>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>> >>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>> time while connected. The last event is the "suspend" one. After that, total >>>> silence. >>>> >>>> If you need traces, please point me to a description on how to obtain them. >>>> >>>> >>> Let me know if you run into issues following this instructions to >>> capture the tracepoints: >>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >> I've attached the traces as a tarball. Hope it survives. > Got them. Thanks. > >> At the start, the USB is up and running (and doing ethernet+mass storage). I >> saved the trace after pulling the USB cable. >> > From the capture, we can see that there's no system suspend, so there's > no soft-disconnect. > > Base on the suspend event, you're running in usb2 speed (ignore the > incorrect U3 state, should be L2): > > irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] > > The DSTS from the regdump indicated that you're still in L2 despite > disconnected. Looks like the phy was unable to detect and wakeup from > the disconnection to notify the controller. > > Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable > usb2 phy suspend. Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is identical. > > Does your device support SuperSpeed? If so, do you observe the same > behavior while operating in SuperSpeed? Just checked, still connects with superspeed. What led you to think it was only high speed? Do you want me to send new traces?
On Thu, Jun 06, 2024, Mike Looijmans wrote: > On 06-06-2024 02:28, Thinh Nguyen wrote: > > On Wed, Jun 05, 2024, Mike Looijmans wrote: > > > On 05-06-2024 01:06, Thinh Nguyen wrote: > > > > Hi, > > > > > > > > On Tue, Jun 04, 2024, Mike Looijmans wrote: > > > > > On 04-06-2024 03:03, Thinh Nguyen wrote: > > > > > > Hi, > > > > > > > > > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > > > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > > > > > in userspace, which keeps thinking everything is still up and running. > > > > > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > > > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > > > > > expect. As a result, sysfs attribute "state" remains "configured" > > > > > > > until something resets it. > > > > > > > > > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > > > > > changes into "suspended" when one removes the cable, and hence also > > > > > > > matches the gadget's state when really suspended. > > > > > > On disconnection, did you see disconnect interrupt? If so, it should > > > > > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > > > > > address your issue. Can you provide the driver tracepoints? > > > > > The device doesn't issue a disconnect event, I didn't have tracing enabled > > > > > in the kernel but added some dev_info() calls to determine what was going > > > > > on. Added this to dwc3_process_event_entry(): > > > > > > > > > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > > > > > > > > > When disconnecting the cable from the host, I see this: > > > > > > > > > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > > > > > > > > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > > > > > time while connected. The last event is the "suspend" one. After that, total > > > > > silence. > > > > > > > > > > If you need traces, please point me to a description on how to obtain them. > > > > > > > > > > > > > > Let me know if you run into issues following this instructions to > > > > capture the tracepoints: > > > > https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ > > > I've attached the traces as a tarball. Hope it survives. > > Got them. Thanks. > > > > > At the start, the USB is up and running (and doing ethernet+mass storage). I > > > saved the trace after pulling the USB cable. > > > > > From the capture, we can see that there's no system suspend, so there's > > no soft-disconnect. > > > > Base on the suspend event, you're running in usb2 speed (ignore the > > incorrect U3 state, should be L2): > > > > irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] > > > > The DSTS from the regdump indicated that you're still in L2 despite > > disconnected. Looks like the phy was unable to detect and wakeup from > > the disconnection to notify the controller. > > > > Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable > > usb2 phy suspend. > > Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is > identical. > > > > > > Does your device support SuperSpeed? If so, do you observe the same > > behavior while operating in SuperSpeed? > > Just checked, still connects with superspeed. What led you to think it was > only high speed? > Bit(4) of event info (0003) from device event value (00030601) indicates usb2 speed. Register DSTS field 2:0 indicates fullspeed. Even though this was captured after disconnection, the linkstate did not change, which led me to think that the connected speed did not change to Es.Disable either. > Do you want me to send new traces? > Can you also try to disable usb3 phy suspend with "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? Please capture the traces again if it's operating in SuperSpeed. Thanks, Thinh
On 06-06-2024 22:21, Thinh Nguyen wrote: > On Thu, Jun 06, 2024, Mike Looijmans wrote: >> On 06-06-2024 02:28, Thinh Nguyen wrote: >>> On Wed, Jun 05, 2024, Mike Looijmans wrote: >>>> On 05-06-2024 01:06, Thinh Nguyen wrote: >>>>> Hi, >>>>> >>>>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>>>> until something resets it. >>>>>>>> >>>>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>>>> matches the gadget's state when really suspended. >>>>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>>>> address your issue. Can you provide the driver tracepoints? >>>>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>>>> in the kernel but added some dev_info() calls to determine what was going >>>>>> on. Added this to dwc3_process_event_entry(): >>>>>> >>>>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>>>> >>>>>> When disconnecting the cable from the host, I see this: >>>>>> >>>>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>>>> >>>>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>>>> time while connected. The last event is the "suspend" one. After that, total >>>>>> silence. >>>>>> >>>>>> If you need traces, please point me to a description on how to obtain them. >>>>>> >>>>>> >>>>> Let me know if you run into issues following this instructions to >>>>> capture the tracepoints: >>>>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >>>> I've attached the traces as a tarball. Hope it survives. >>> Got them. Thanks. >>> >>>> At the start, the USB is up and running (and doing ethernet+mass storage). I >>>> saved the trace after pulling the USB cable. >>>> >>> From the capture, we can see that there's no system suspend, so there's >>> no soft-disconnect. >>> >>> Base on the suspend event, you're running in usb2 speed (ignore the >>> incorrect U3 state, should be L2): >>> >>> irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] >>> >>> The DSTS from the regdump indicated that you're still in L2 despite >>> disconnected. Looks like the phy was unable to detect and wakeup from >>> the disconnection to notify the controller. >>> >>> Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable >>> usb2 phy suspend. >> Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is >> identical. >> >> >>> Does your device support SuperSpeed? If so, do you observe the same >>> behavior while operating in SuperSpeed? >> Just checked, still connects with superspeed. What led you to think it was >> only high speed? >> > Bit(4) of event info (0003) from device event value (00030601) indicates > usb2 speed. > > Register DSTS field 2:0 indicates fullspeed. Even though this was > captured after disconnection, the linkstate did not change, which led me > to think that the connected speed did not change to Es.Disable either. > >> Do you want me to send new traces? >> > Can you also try to disable usb3 phy suspend with > "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? Added this to the devicetree, but also no change in behavior. > Please capture the traces again if it's operating in SuperSpeed. I've attached new traces. Connected at superspeed (host reports "superspeed" in its dmesg log, and the real data transfer speed is way above highspeed) I added register dumps before and after the disconnect.
On Fri, Jun 07, 2024, Mike Looijmans wrote: > On 06-06-2024 22:21, Thinh Nguyen wrote: > > On Thu, Jun 06, 2024, Mike Looijmans wrote: > > > On 06-06-2024 02:28, Thinh Nguyen wrote: > > > > On Wed, Jun 05, 2024, Mike Looijmans wrote: > > > > > On 05-06-2024 01:06, Thinh Nguyen wrote: > > > > > > Hi, > > > > > > > > > > > > On Tue, Jun 04, 2024, Mike Looijmans wrote: > > > > > > > On 04-06-2024 03:03, Thinh Nguyen wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > > > > > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > > > > > > > in userspace, which keeps thinking everything is still up and running. > > > > > > > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > > > > > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > > > > > > > expect. As a result, sysfs attribute "state" remains "configured" > > > > > > > > > until something resets it. > > > > > > > > > > > > > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > > > > > > > changes into "suspended" when one removes the cable, and hence also > > > > > > > > > matches the gadget's state when really suspended. > > > > > > > > On disconnection, did you see disconnect interrupt? If so, it should > > > > > > > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > > > > > > > address your issue. Can you provide the driver tracepoints? > > > > > > > The device doesn't issue a disconnect event, I didn't have tracing enabled > > > > > > > in the kernel but added some dev_info() calls to determine what was going > > > > > > > on. Added this to dwc3_process_event_entry(): > > > > > > > > > > > > > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > > > > > > > > > > > > > When disconnecting the cable from the host, I see this: > > > > > > > > > > > > > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > > > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > > > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > > > > > > > > > > > > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > > > > > > > time while connected. The last event is the "suspend" one. After that, total > > > > > > > silence. > > > > > > > > > > > > > > If you need traces, please point me to a description on how to obtain them. > > > > > > > > > > > > > > > > > > > > Let me know if you run into issues following this instructions to > > > > > > capture the tracepoints: > > > > > > https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ > > > > > I've attached the traces as a tarball. Hope it survives. > > > > Got them. Thanks. > > > > > > > > > At the start, the USB is up and running (and doing ethernet+mass storage). I > > > > > saved the trace after pulling the USB cable. > > > > > > > > > From the capture, we can see that there's no system suspend, so there's > > > > no soft-disconnect. > > > > > > > > Base on the suspend event, you're running in usb2 speed (ignore the > > > > incorrect U3 state, should be L2): > > > > > > > > irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] > > > > > > > > The DSTS from the regdump indicated that you're still in L2 despite > > > > disconnected. Looks like the phy was unable to detect and wakeup from > > > > the disconnection to notify the controller. > > > > > > > > Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable > > > > usb2 phy suspend. > > > Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is > > > identical. > > > > > > > > > > Does your device support SuperSpeed? If so, do you observe the same > > > > behavior while operating in SuperSpeed? > > > Just checked, still connects with superspeed. What led you to think it was > > > only high speed? > > > > > Bit(4) of event info (0003) from device event value (00030601) indicates > > usb2 speed. > > > > Register DSTS field 2:0 indicates fullspeed. Even though this was > > captured after disconnection, the linkstate did not change, which led me > > to think that the connected speed did not change to Es.Disable either. > > > > > Do you want me to send new traces? > > > > > Can you also try to disable usb3 phy suspend with > > "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? > > Added this to the devicetree, but also no change in behavior. > > > > Please capture the traces again if it's operating in SuperSpeed. > > I've attached new traces. Connected at superspeed (host reports "superspeed" > in its dmesg log, and the real data transfer speed is way above highspeed) > > I added register dumps before and after the disconnect. > Thanks for the trace. It's indeed operating in SuperSpeed in the connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set. Can you double check if you properly set the "snps,dis_u3_susphy_quirk"? Thanks, Thinh
On 08-06-2024 00:57, Thinh Nguyen wrote: > On Fri, Jun 07, 2024, Mike Looijmans wrote: >> On 06-06-2024 22:21, Thinh Nguyen wrote: >>> On Thu, Jun 06, 2024, Mike Looijmans wrote: >>>> On 06-06-2024 02:28, Thinh Nguyen wrote: >>>>> On Wed, Jun 05, 2024, Mike Looijmans wrote: >>>>>> On 05-06-2024 01:06, Thinh Nguyen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>>>>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>>>>>> until something resets it. >>>>>>>>>> >>>>>>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>>>>>> matches the gadget's state when really suspended. >>>>>>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>>>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>>>>>> address your issue. Can you provide the driver tracepoints? >>>>>>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>>>>>> in the kernel but added some dev_info() calls to determine what was going >>>>>>>> on. Added this to dwc3_process_event_entry(): >>>>>>>> >>>>>>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>>>>>> >>>>>>>> When disconnecting the cable from the host, I see this: >>>>>>>> >>>>>>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>>>>>> >>>>>>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>>>>>> time while connected. The last event is the "suspend" one. After that, total >>>>>>>> silence. >>>>>>>> >>>>>>>> If you need traces, please point me to a description on how to obtain them. >>>>>>>> >>>>>>>> >>>>>>> Let me know if you run into issues following this instructions to >>>>>>> capture the tracepoints: >>>>>>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >>>>>> I've attached the traces as a tarball. Hope it survives. >>>>> Got them. Thanks. >>>>> >>>>>> At the start, the USB is up and running (and doing ethernet+mass storage). I >>>>>> saved the trace after pulling the USB cable. >>>>>> >>>>> From the capture, we can see that there's no system suspend, so there's >>>>> no soft-disconnect. >>>>> >>>>> Base on the suspend event, you're running in usb2 speed (ignore the >>>>> incorrect U3 state, should be L2): >>>>> >>>>> irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] >>>>> >>>>> The DSTS from the regdump indicated that you're still in L2 despite >>>>> disconnected. Looks like the phy was unable to detect and wakeup from >>>>> the disconnection to notify the controller. >>>>> >>>>> Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable >>>>> usb2 phy suspend. >>>> Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is >>>> identical. >>>> >>>> >>>>> Does your device support SuperSpeed? If so, do you observe the same >>>>> behavior while operating in SuperSpeed? >>>> Just checked, still connects with superspeed. What led you to think it was >>>> only high speed? >>>> >>> Bit(4) of event info (0003) from device event value (00030601) indicates >>> usb2 speed. >>> >>> Register DSTS field 2:0 indicates fullspeed. Even though this was >>> captured after disconnection, the linkstate did not change, which led me >>> to think that the connected speed did not change to Es.Disable either. >>> >>>> Do you want me to send new traces? >>>> >>> Can you also try to disable usb3 phy suspend with >>> "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? >> Added this to the devicetree, but also no change in behavior. >> >> >>> Please capture the traces again if it's operating in SuperSpeed. >> I've attached new traces. Connected at superspeed (host reports "superspeed" >> in its dmesg log, and the real data transfer speed is way above highspeed) >> >> I added register dumps before and after the disconnect. >> > Thanks for the trace. It's indeed operating in SuperSpeed in the > connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set. > Can you double check if you properly set the "snps,dis_u3_susphy_quirk"? The trace was made before I added the property. It doesn't change the behavior. Should I create a new trace?
On 08-06-2024 00:57, Thinh Nguyen wrote: > On Fri, Jun 07, 2024, Mike Looijmans wrote: >> On 06-06-2024 22:21, Thinh Nguyen wrote: >>> On Thu, Jun 06, 2024, Mike Looijmans wrote: >>>> On 06-06-2024 02:28, Thinh Nguyen wrote: >>>>> On Wed, Jun 05, 2024, Mike Looijmans wrote: >>>>>> On 05-06-2024 01:06, Thinh Nguyen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>>>>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>>>>>> until something resets it. >>>>>>>>>> >>>>>>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>>>>>> matches the gadget's state when really suspended. >>>>>>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>>>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>>>>>> address your issue. Can you provide the driver tracepoints? >>>>>>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>>>>>> in the kernel but added some dev_info() calls to determine what was going >>>>>>>> on. Added this to dwc3_process_event_entry(): >>>>>>>> >>>>>>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>>>>>> >>>>>>>> When disconnecting the cable from the host, I see this: >>>>>>>> >>>>>>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>>>>>> >>>>>>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>>>>>> time while connected. The last event is the "suspend" one. After that, total >>>>>>>> silence. >>>>>>>> >>>>>>>> If you need traces, please point me to a description on how to obtain them. >>>>>>>> >>>>>>>> >>>>>>> Let me know if you run into issues following this instructions to >>>>>>> capture the tracepoints: >>>>>>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >>>>>> I've attached the traces as a tarball. Hope it survives. >>>>> Got them. Thanks. >>>>> >>>>>> At the start, the USB is up and running (and doing ethernet+mass storage). I >>>>>> saved the trace after pulling the USB cable. >>>>>> >>>>> From the capture, we can see that there's no system suspend, so there's >>>>> no soft-disconnect. >>>>> >>>>> Base on the suspend event, you're running in usb2 speed (ignore the >>>>> incorrect U3 state, should be L2): >>>>> >>>>> irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] >>>>> >>>>> The DSTS from the regdump indicated that you're still in L2 despite >>>>> disconnected. Looks like the phy was unable to detect and wakeup from >>>>> the disconnection to notify the controller. >>>>> >>>>> Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable >>>>> usb2 phy suspend. >>>> Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is >>>> identical. >>>> >>>> >>>>> Does your device support SuperSpeed? If so, do you observe the same >>>>> behavior while operating in SuperSpeed? >>>> Just checked, still connects with superspeed. What led you to think it was >>>> only high speed? >>>> >>> Bit(4) of event info (0003) from device event value (00030601) indicates >>> usb2 speed. >>> >>> Register DSTS field 2:0 indicates fullspeed. Even though this was >>> captured after disconnection, the linkstate did not change, which led me >>> to think that the connected speed did not change to Es.Disable either. >>> >>>> Do you want me to send new traces? >>>> >>> Can you also try to disable usb3 phy suspend with >>> "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? >> Added this to the devicetree, but also no change in behavior. >> >> >>> Please capture the traces again if it's operating in SuperSpeed. >> I've attached new traces. Connected at superspeed (host reports "superspeed" >> in its dmesg log, and the real data transfer speed is way above highspeed) >> >> I added register dumps before and after the disconnect. >> > Thanks for the trace. It's indeed operating in SuperSpeed in the > connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set. > Can you double check if you properly set the "snps,dis_u3_susphy_quirk"? > I've attached a trace with both "quirks" in the devicetree: snps,dis_u2_susphy_quirk; snps,dis_u3_susphy_quirk; Interestingly, it still goes into "suspended" mode when I remove the cable.
On Tue, Jun 11, 2024, Mike Looijmans wrote: > On 08-06-2024 00:57, Thinh Nguyen wrote: > > On Fri, Jun 07, 2024, Mike Looijmans wrote: > > > On 06-06-2024 22:21, Thinh Nguyen wrote: > > > > On Thu, Jun 06, 2024, Mike Looijmans wrote: > > > > > On 06-06-2024 02:28, Thinh Nguyen wrote: > > > > > > On Wed, Jun 05, 2024, Mike Looijmans wrote: > > > > > > > On 05-06-2024 01:06, Thinh Nguyen wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Tue, Jun 04, 2024, Mike Looijmans wrote: > > > > > > > > > On 04-06-2024 03:03, Thinh Nguyen wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On Mon, Jun 03, 2024, Mike Looijmans wrote: > > > > > > > > > > > When disconnecting the USB cable on an LS1028 device, nothing happens > > > > > > > > > > > in userspace, which keeps thinking everything is still up and running. > > > > > > > > > > > Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND > > > > > > > > > > > in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would > > > > > > > > > > > expect. As a result, sysfs attribute "state" remains "configured" > > > > > > > > > > > until something resets it. > > > > > > > > > > > > > > > > > > > > > > Forward the "suspended" state to sysfs, so that the "state" at least > > > > > > > > > > > changes into "suspended" when one removes the cable, and hence also > > > > > > > > > > > matches the gadget's state when really suspended. > > > > > > > > > > On disconnection, did you see disconnect interrupt? If so, it should > > > > > > > > > > transition to USB_STATE_NOATTACHED. This change doesn't seem to directly > > > > > > > > > > address your issue. Can you provide the driver tracepoints? > > > > > > > > > The device doesn't issue a disconnect event, I didn't have tracing enabled > > > > > > > > > in the kernel but added some dev_info() calls to determine what was going > > > > > > > > > on. Added this to dwc3_process_event_entry(): > > > > > > > > > > > > > > > > > > dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); > > > > > > > > > > > > > > > > > > When disconnecting the cable from the host, I see this: > > > > > > > > > > > > > > > > > > [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > > > > > [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > > > [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 > > > > > > > > > [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > > > [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 > > > > > > > > > [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 > > > > > > > > > > > > > > > > > > The "0x4086" and "0x6084" messages are endpoint events that occur all the > > > > > > > > > time while connected. The last event is the "suspend" one. After that, total > > > > > > > > > silence. > > > > > > > > > > > > > > > > > > If you need traces, please point me to a description on how to obtain them. > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know if you run into issues following this instructions to > > > > > > > > capture the tracepoints: > > > > > > > > https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ > > > > > > > I've attached the traces as a tarball. Hope it survives. > > > > > > Got them. Thanks. > > > > > > > > > > > > > At the start, the USB is up and running (and doing ethernet+mass storage). I > > > > > > > saved the trace after pulling the USB cable. > > > > > > > > > > > > > From the capture, we can see that there's no system suspend, so there's > > > > > > no soft-disconnect. > > > > > > > > > > > > Base on the suspend event, you're running in usb2 speed (ignore the > > > > > > incorrect U3 state, should be L2): > > > > > > > > > > > > irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] > > > > > > > > > > > > The DSTS from the regdump indicated that you're still in L2 despite > > > > > > disconnected. Looks like the phy was unable to detect and wakeup from > > > > > > the disconnection to notify the controller. > > > > > > > > > > > > Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable > > > > > > usb2 phy suspend. > > > > > Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is > > > > > identical. > > > > > > > > > > > > > > > > Does your device support SuperSpeed? If so, do you observe the same > > > > > > behavior while operating in SuperSpeed? > > > > > Just checked, still connects with superspeed. What led you to think it was > > > > > only high speed? > > > > > > > > > Bit(4) of event info (0003) from device event value (00030601) indicates > > > > usb2 speed. > > > > > > > > Register DSTS field 2:0 indicates fullspeed. Even though this was > > > > captured after disconnection, the linkstate did not change, which led me > > > > to think that the connected speed did not change to Es.Disable either. > > > > > > > > > Do you want me to send new traces? > > > > > > > > > Can you also try to disable usb3 phy suspend with > > > > "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? > > > Added this to the devicetree, but also no change in behavior. > > > > > > > > > > Please capture the traces again if it's operating in SuperSpeed. > > > I've attached new traces. Connected at superspeed (host reports "superspeed" > > > in its dmesg log, and the real data transfer speed is way above highspeed) > > > > > > I added register dumps before and after the disconnect. > > > > > Thanks for the trace. It's indeed operating in SuperSpeed in the > > connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set. > > Can you double check if you properly set the "snps,dis_u3_susphy_quirk"? > > > I've attached a trace with both "quirks" in the devicetree: > snps,dis_u2_susphy_quirk; > snps,dis_u3_susphy_quirk; > > Interestingly, it still goes into "suspended" mode when I remove the cable. > Wait, I thought the host initiated the usb suspend. Did you trigger usb suspend by putting the host in suspend? Or does the suspend event only come when you perform a disconnect? Can you confirm if the suspend event was there before you disconnect the device? Thanks, Thinh
On 13-06-2024 02:32, Thinh Nguyen wrote: > On Tue, Jun 11, 2024, Mike Looijmans wrote: >> On 08-06-2024 00:57, Thinh Nguyen wrote: >>> On Fri, Jun 07, 2024, Mike Looijmans wrote: >>>> On 06-06-2024 22:21, Thinh Nguyen wrote: >>>>> On Thu, Jun 06, 2024, Mike Looijmans wrote: >>>>>> On 06-06-2024 02:28, Thinh Nguyen wrote: >>>>>>> On Wed, Jun 05, 2024, Mike Looijmans wrote: >>>>>>>> On 05-06-2024 01:06, Thinh Nguyen wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Tue, Jun 04, 2024, Mike Looijmans wrote: >>>>>>>>>> On 04-06-2024 03:03, Thinh Nguyen wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On Mon, Jun 03, 2024, Mike Looijmans wrote: >>>>>>>>>>>> When disconnecting the USB cable on an LS1028 device, nothing happens >>>>>>>>>>>> in userspace, which keeps thinking everything is still up and running. >>>>>>>>>>>> Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND >>>>>>>>>>>> in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would >>>>>>>>>>>> expect. As a result, sysfs attribute "state" remains "configured" >>>>>>>>>>>> until something resets it. >>>>>>>>>>>> >>>>>>>>>>>> Forward the "suspended" state to sysfs, so that the "state" at least >>>>>>>>>>>> changes into "suspended" when one removes the cable, and hence also >>>>>>>>>>>> matches the gadget's state when really suspended. >>>>>>>>>>> On disconnection, did you see disconnect interrupt? If so, it should >>>>>>>>>>> transition to USB_STATE_NOATTACHED. This change doesn't seem to directly >>>>>>>>>>> address your issue. Can you provide the driver tracepoints? >>>>>>>>>> The device doesn't issue a disconnect event, I didn't have tracing enabled >>>>>>>>>> in the kernel but added some dev_info() calls to determine what was going >>>>>>>>>> on. Added this to dwc3_process_event_entry(): >>>>>>>>>> >>>>>>>>>> dev_info(dwc->dev, "event: 0x%x type=0x%x", event->raw, event->type.type); >>>>>>>>>> >>>>>>>>>> When disconnecting the cable from the host, I see this: >>>>>>>>>> >>>>>>>>>> [ 50.841411] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>>>> [ 50.841457] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>>>> [ 50.841494] dwc3 3110000.usb: event: 0x6084 type=0x42 >>>>>>>>>> [ 50.841534] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>>>> [ 50.841571] dwc3 3110000.usb: event: 0x4086 type=0x43 >>>>>>>>>> [ 52.650990] dwc3 3110000.usb: event: 0x30601 type=0x0 >>>>>>>>>> >>>>>>>>>> The "0x4086" and "0x6084" messages are endpoint events that occur all the >>>>>>>>>> time while connected. The last event is the "suspend" one. After that, total >>>>>>>>>> silence. >>>>>>>>>> >>>>>>>>>> If you need traces, please point me to a description on how to obtain them. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Let me know if you run into issues following this instructions to >>>>>>>>> capture the tracepoints: >>>>>>>>> https://urldefense.com/v3/__https://docs.kernel.org/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!bahfjil5HEUq-fOHAwDfusutLJCLognfyLHTFLiSlVuZotpr99XBGg7nB0zRRnNF_M1pqEKcVa4KxNJwh3_F2dZWwVKTkUY$ >>>>>>>> I've attached the traces as a tarball. Hope it survives. >>>>>>> Got them. Thanks. >>>>>>> >>>>>>>> At the start, the USB is up and running (and doing ethernet+mass storage). I >>>>>>>> saved the trace after pulling the USB cable. >>>>>>>> >>>>>>> From the capture, we can see that there's no system suspend, so there's >>>>>>> no soft-disconnect. >>>>>>> >>>>>>> Base on the suspend event, you're running in usb2 speed (ignore the >>>>>>> incorrect U3 state, should be L2): >>>>>>> >>>>>>> irq/94-dwc3-631 [000] D..1. 149.139290: dwc3_event: event (00030601): Suspend [U3] >>>>>>> >>>>>>> The DSTS from the regdump indicated that you're still in L2 despite >>>>>>> disconnected. Looks like the phy was unable to detect and wakeup from >>>>>>> the disconnection to notify the controller. >>>>>>> >>>>>>> Can you experiment with setting "snps,dis_u2_susphy_quirk" to disable >>>>>>> usb2 phy suspend. >>>>>> Adding snps,dis_u2_susphy_quirk doesn't make a difference, behavior is >>>>>> identical. >>>>>> >>>>>> >>>>>>> Does your device support SuperSpeed? If so, do you observe the same >>>>>>> behavior while operating in SuperSpeed? >>>>>> Just checked, still connects with superspeed. What led you to think it was >>>>>> only high speed? >>>>>> >>>>> Bit(4) of event info (0003) from device event value (00030601) indicates >>>>> usb2 speed. >>>>> >>>>> Register DSTS field 2:0 indicates fullspeed. Even though this was >>>>> captured after disconnection, the linkstate did not change, which led me >>>>> to think that the connected speed did not change to Es.Disable either. >>>>> >>>>>> Do you want me to send new traces? >>>>>> >>>>> Can you also try to disable usb3 phy suspend with >>>>> "snps,dis_u3_susphy_quirk" if you think it's connected in SuperSpeed? >>>> Added this to the devicetree, but also no change in behavior. >>>> >>>> >>>>> Please capture the traces again if it's operating in SuperSpeed. >>>> I've attached new traces. Connected at superspeed (host reports "superspeed" >>>> in its dmesg log, and the real data transfer speed is way above highspeed) >>>> >>>> I added register dumps before and after the disconnect. >>>> >>> Thanks for the trace. It's indeed operating in SuperSpeed in the >>> connected regdump. However, the GUSB3PIPECTL.SUSPENDENABLE is still set. >>> Can you double check if you properly set the "snps,dis_u3_susphy_quirk"? >>> >> I've attached a trace with both "quirks" in the devicetree: >> snps,dis_u2_susphy_quirk; >> snps,dis_u3_susphy_quirk; >> >> Interestingly, it still goes into "suspended" mode when I remove the cable. >> > > Wait, I thought the host initiated the usb suspend. Did you trigger usb > suspend by putting the host in suspend? Or does the suspend event only > come when you perform a disconnect? All I do is unplug the cable. The host (PC running Ubuntu 22) doesn't eject or suspend or anything like that. > > Can you confirm if the suspend event was there before you disconnect the > device? Disconnecting the cable is what leads to the "suspend" event. M.
On Thu, Jun 13, 2024, Mike Looijmans wrote: > > > > Wait, I thought the host initiated the usb suspend. Did you trigger usb > > suspend by putting the host in suspend? Or does the suspend event only > > come when you perform a disconnect? > > All I do is unplug the cable. The host (PC running Ubuntu 22) doesn't eject > or suspend or anything like that. > This is a very typical connect/disconnect flow. I'm surprised that it's not caught on your platform before. What's the compatible string for your platform? > > > > > Can you confirm if the suspend event was there before you disconnect the > > device? > > Disconnecting the cable is what leads to the "suspend" event. > Can you try this: It's a simple workaround, but may not catch the issue while operating in Fullspeed. diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..894ca1044281 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4339,6 +4339,18 @@ static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc, { enum dwc3_link_state next = evtinfo & DWC3_LINK_STATE_MASK; + if (next == DWC3_LINK_STATE_U3) { + u8 speed; + u32 reg; + + reg = dwc3_readl(dwc->regs, DWC3_DSTS); + speed = reg & DWC3_DSTS_CONNECTSPD; + if (dwc->speed != speed) { + dwc3_gadget_disconnect_interrupt(dwc); + return; + } + } + if (!dwc->suspended && next == DWC3_LINK_STATE_U3) { dwc->suspended = true; dwc3_suspend_gadget(dwc); Otherwise, there's no other SW workaround that I can think of. BR, Thinh
On Mon, Jun 17, 2024, Thinh Nguyen wrote: > On Thu, Jun 13, 2024, Mike Looijmans wrote: > > > > > > Wait, I thought the host initiated the usb suspend. Did you trigger usb > > > suspend by putting the host in suspend? Or does the suspend event only > > > come when you perform a disconnect? > > > > All I do is unplug the cable. The host (PC running Ubuntu 22) doesn't eject > > or suspend or anything like that. > > > > This is a very typical connect/disconnect flow. I'm surprised that it's > not caught on your platform before. What's the compatible string for > your platform? > > > > > > > > > Can you confirm if the suspend event was there before you disconnect the > > > device? > > > > Disconnecting the cable is what leads to the "suspend" event. > > > > Can you try this: > > It's a simple workaround, but may not catch the issue while operating in > Fullspeed. > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 89fc690fdf34..894ca1044281 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -4339,6 +4339,18 @@ static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc, > { > enum dwc3_link_state next = evtinfo & DWC3_LINK_STATE_MASK; > > + if (next == DWC3_LINK_STATE_U3) { > + u8 speed; > + u32 reg; > + > + reg = dwc3_readl(dwc->regs, DWC3_DSTS); > + speed = reg & DWC3_DSTS_CONNECTSPD; > + if (dwc->speed != speed) { Minor tweak to this condition to this instead: if (dwc->gadget->speed != USB_SPEED_UNKNOWN && dwc->speed != speed) { > + dwc3_gadget_disconnect_interrupt(dwc); > + return; > + } > + } > + > if (!dwc->suspended && next == DWC3_LINK_STATE_U3) { > dwc->suspended = true; > dwc3_suspend_gadget(dwc); > > > Otherwise, there's no other SW workaround that I can think of. > Thanks, Thinh
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 4df2661f6675..99e8ea9db600 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4343,6 +4343,7 @@ static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc, if (!dwc->suspended && next == DWC3_LINK_STATE_U3) { dwc->suspended = true; dwc3_suspend_gadget(dwc); + usb_gadget_set_state(dwc->gadget, USB_STATE_SUSPENDED); } dwc->link_state = next;
When disconnecting the USB cable on an LS1028 device, nothing happens in userspace, which keeps thinking everything is still up and running. Turns out that the DWC3 controller only sends DWC3_DEVICE_EVENT_SUSPEND in that case, and not a DWC3_DEVICE_EVENT_DISCONNECT as one would expect. As a result, sysfs attribute "state" remains "configured" until something resets it. Forward the "suspended" state to sysfs, so that the "state" at least changes into "suspended" when one removes the cable, and hence also matches the gadget's state when really suspended. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> --- drivers/usb/dwc3/gadget.c | 1 + 1 file changed, 1 insertion(+)