[PATCH] usb: dwc3: gadget: Inform system of suspended state

[PATCH] usb: dwc3: gadget: Inform system of suspended state

[Mike Looijmans]

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(+)

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
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Thinh Nguyen]

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?

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
> System Expert
> 
> 
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
> 
> T: +31 (0) 499 33 69 69
> E: mike.looijmans@topic.nl
> W: https://urldefense.com/v3/__http://www.topic.nl__;!!A4F2R9G_pg!dXv5bN6_FJRVB7pQogk6ZxPOb97r2m4CJ9R2rvxelfjbfNhJjQ9ilRpqRBgO983Jxof9Hs8f8rY6nX1hyIvD6ZNIwnKmb9c$ 
> 
> Please consider the environment before printing this e-mail

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Mike Looijmans]

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


-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Krishna Kurapati PSSNV]

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,

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Mike Looijmans]

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".

-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Krishna Kurapati PSSNV]

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".
> 

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Thinh Nguyen]

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

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Mike Looijmans]

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.

-- 

Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Thinh Nguyen]

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

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Ravineet Singh]

[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]

Hi.

Sorry to resurrect this old thread but as far as I can see,
this issue was dropped.
As we have the same issue, not receiving a disconnect when cable is disconnected,
we altered the patch and this version works for us.

Any thought on the patch?

Regards
/Ravineet



On Thu, Jun 06, 2024 at 12:29:13AM +0000, 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!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

[-- Attachment #2: 0001-usb-dwc3-gadget-set-device-in-disconnected-state-whe.patch --]
[-- Type: text/x-diff, Size: 1492 bytes --]

From a689256e5d6cacdea09299014746522ae928f7c5 Mon Sep 17 00:00:00 2001
From: Ravineet Singh <ravineet.a.singh@est.tech>
Date: Mon, 2 Mar 2026 16:44:46 +0100
Subject: [PATCH] usb: dwc3: gadget: set device in disconnected state when
 unplugged

When a USB cable is disconnected on an LS1028 device, the DWC3
controller only sends DWC3_DEVICE_EVENT_SUSPEND and not a
DWC3_DEVICE_EVENT_DISCONNECT.

Set device in disconnected state by issuing
DWC3_DEVICE_EVENT_DISCONNECT.

Signed-off-by: Ravineet Singh <ravineet.a.singh@est.tech>
---
 drivers/usb/dwc3/gadget.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6e90f2ad0426..94e191a9ceb8 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -4440,9 +4440,22 @@ static void dwc3_gadget_suspend_interrupt(struct dwc3 *dwc,
 {
 	enum dwc3_link_state next = evtinfo & DWC3_LINK_STATE_MASK;
 
-	if (!dwc->suspended && next == DWC3_LINK_STATE_U3) {
-		dwc->suspended = true;
-		dwc3_suspend_gadget(dwc);
+	if (next == DWC3_LINK_STATE_U3) {
+		u8 speed;
+		u32 reg;
+
+		reg = dwc3_readl(dwc->regs, DWC3_DSTS);
+		speed = reg & DWC3_DSTS_CONNECTSPD;
+		if (dwc->gadget->speed != USB_SPEED_UNKNOWN &&
+		    speed == USB_SPEED_UNKNOWN) {
+			dwc3_gadget_disconnect_interrupt(dwc);
+			return;
+		}
+
+		if (!dwc->suspended) {
+			dwc->suspended = true;
+			dwc3_suspend_gadget(dwc);
+		}
 	}
 
 	dwc->link_state = next;
-- 
2.43.0

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Thinh Nguyen]

On Thu, Mar 05, 2026, Ravineet Singh wrote:
> Hi.
> 
> Sorry to resurrect this old thread but as far as I can see,
> this issue was dropped.
> As we have the same issue, not receiving a disconnect when cable is disconnected,
> we altered the patch and this version works for us.
> 
> Any thought on the patch?
> 
> Regards
> /Ravineet
> 
> 

Please avoid sending patches as attachment so we can keep track of the
context. You can send as RFC patch and reference back to this discussion.

Regarding the patch, no it's not right. You're comparing the
usb_device_speed enum value to the DSTS register value.

Can you share the regdump after disconnection?

BR,
Thinh

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Ravineet Singh]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Understood, my bad, will send a RFC patch in the future.

Regdumps (without the patch) are attached.
Regards
/Ravineet

On Fri, Mar 06, 2026 at 02:06:24AM +0000, Thinh Nguyen wrote:
> On Thu, Mar 05, 2026, Ravineet Singh wrote:
> > Hi.
> >
> > Sorry to resurrect this old thread but as far as I can see,
> > this issue was dropped.
> > As we have the same issue, not receiving a disconnect when cable is disconnected,
> > we altered the patch and this version works for us.
> >
> > Any thought on the patch?
> >
> > Regards
> > /Ravineet
> >
> >
>
> Please avoid sending patches as attachment so we can keep track of the
> context. You can send as RFC patch and reference back to this discussion.
>
> Regarding the patch, no it's not right. You're comparing the
> usb_device_speed enum value to the DSTS register value.
>
> Can you share the regdump after disconnection?
>
> BR,
> Thinh

[-- Attachment #2: regdump.after --]
[-- Type: text/plain, Size: 8201 bytes --]

GSBUSCFG0 = 0x22220009
GSBUSCFG1 = 0x00000700
GTXTHRCFG = 0x00000000
GRXTHRCFG = 0x00000000
GCTL = 0x30c12004
GEVTEN = 0x00000000
GSTS = 0x7e800000
GUCTL1 = 0x0104018a
GSNPSID = 0x5533290a
GGPIO = 0x00000000
GUID = 0x0006066c
GUCTL = 0x02008010
GBUSERRADDR0 = 0x00000000
GBUSERRADDR1 = 0x00000000
GPRTBIMAP0 = 0x00000000
GPRTBIMAP1 = 0x00000000
GHWPARAMS0 = 0x4020400a
GHWPARAMS1 = 0x81e0c93b
GHWPARAMS2 = 0x0130290a
GHWPARAMS3 = 0x04108485
GHWPARAMS4 = 0x47822004
GHWPARAMS5 = 0x04204108
GHWPARAMS6 = 0x09049c20
GHWPARAMS7 = 0x0308044d
GDBGFIFOSPACE = 0x00420000
GDBGLTSSM = 0x41090658
GDBGBMU = 0x01300010
GPRTBIMAP_HS0 = 0x00000000
GPRTBIMAP_HS1 = 0x00000000
GPRTBIMAP_FS0 = 0x00000000
GPRTBIMAP_FS1 = 0x00000000
GUCTL2 = 0x00000000
VER_NUMBER = 0x00000000
VER_TYPE = 0x00000000
GUSB2PHYCFG(0) = 0x40102540
GUSB2PHYCFG(1) = 0x00000000
GUSB2PHYCFG(2) = 0x00000000
GUSB2PHYCFG(3) = 0x00000000
GUSB2PHYCFG(4) = 0x00000000
GUSB2PHYCFG(5) = 0x00000000
GUSB2PHYCFG(6) = 0x00000000
GUSB2PHYCFG(7) = 0x00000000
GUSB2PHYCFG(8) = 0x00000000
GUSB2PHYCFG(9) = 0x00000000
GUSB2PHYCFG(10) = 0x00000000
GUSB2PHYCFG(11) = 0x00000000
GUSB2PHYCFG(12) = 0x00000000
GUSB2PHYCFG(13) = 0x00000000
GUSB2PHYCFG(14) = 0x00000000
GUSB2PHYCFG(15) = 0x00000000
GUSB2I2CCTL(0) = 0x00000000
GUSB2I2CCTL(1) = 0x00000000
GUSB2I2CCTL(2) = 0x00000000
GUSB2I2CCTL(3) = 0x00000000
GUSB2I2CCTL(4) = 0x00000000
GUSB2I2CCTL(5) = 0x00000000
GUSB2I2CCTL(6) = 0x00000000
GUSB2I2CCTL(7) = 0x00000000
GUSB2I2CCTL(8) = 0x00000000
GUSB2I2CCTL(9) = 0x00000000
GUSB2I2CCTL(10) = 0x00000000
GUSB2I2CCTL(11) = 0x00000000
GUSB2I2CCTL(12) = 0x00000000
GUSB2I2CCTL(13) = 0x00000000
GUSB2I2CCTL(14) = 0x00000000
GUSB2I2CCTL(15) = 0x00000000
GUSB2PHYACC(0) = 0x00000000
GUSB2PHYACC(1) = 0x00000000
GUSB2PHYACC(2) = 0x00000000
GUSB2PHYACC(3) = 0x00000000
GUSB2PHYACC(4) = 0x00000000
GUSB2PHYACC(5) = 0x00000000
GUSB2PHYACC(6) = 0x00000000
GUSB2PHYACC(7) = 0x00000000
GUSB2PHYACC(8) = 0x00000000
GUSB2PHYACC(9) = 0x00000000
GUSB2PHYACC(10) = 0x00000000
GUSB2PHYACC(11) = 0x00000000
GUSB2PHYACC(12) = 0x00000000
GUSB2PHYACC(13) = 0x00000000
GUSB2PHYACC(14) = 0x00000000
GUSB2PHYACC(15) = 0x00000000
GUSB3PIPECTL(0) = 0x110e0002
GUSB3PIPECTL(1) = 0x00000000
GUSB3PIPECTL(2) = 0x00000000
GUSB3PIPECTL(3) = 0x00000000
GUSB3PIPECTL(4) = 0x00000000
GUSB3PIPECTL(5) = 0x00000000
GUSB3PIPECTL(6) = 0x00000000
GUSB3PIPECTL(7) = 0x00000000
GUSB3PIPECTL(8) = 0x00000000
GUSB3PIPECTL(9) = 0x00000000
GUSB3PIPECTL(10) = 0x00000000
GUSB3PIPECTL(11) = 0x00000000
GUSB3PIPECTL(12) = 0x00000000
GUSB3PIPECTL(13) = 0x00000000
GUSB3PIPECTL(14) = 0x00000000
GUSB3PIPECTL(15) = 0x00000000
GTXFIFOSIZ(0) = 0x00000042
GTXFIFOSIZ(1) = 0x00420184
GTXFIFOSIZ(2) = 0x01c60184
GTXFIFOSIZ(3) = 0x034a0103
GTXFIFOSIZ(4) = 0x00000000
GTXFIFOSIZ(5) = 0x00000000
GTXFIFOSIZ(6) = 0x00000000
GTXFIFOSIZ(7) = 0x00000000
GTXFIFOSIZ(8) = 0x00000000
GTXFIFOSIZ(9) = 0x00000000
GTXFIFOSIZ(10) = 0x00000000
GTXFIFOSIZ(11) = 0x00000000
GTXFIFOSIZ(12) = 0x00000000
GTXFIFOSIZ(13) = 0x00000000
GTXFIFOSIZ(14) = 0x00000000
GTXFIFOSIZ(15) = 0x00000000
GTXFIFOSIZ(16) = 0x00000000
GTXFIFOSIZ(17) = 0x00000000
GTXFIFOSIZ(18) = 0x00000000
GTXFIFOSIZ(19) = 0x00000000
GTXFIFOSIZ(20) = 0x00000000
GTXFIFOSIZ(21) = 0x00000000
GTXFIFOSIZ(22) = 0x00000000
GTXFIFOSIZ(23) = 0x00000000
GTXFIFOSIZ(24) = 0x00000000
GTXFIFOSIZ(25) = 0x00000000
GTXFIFOSIZ(26) = 0x00000000
GTXFIFOSIZ(27) = 0x00000000
GTXFIFOSIZ(28) = 0x00000000
GTXFIFOSIZ(29) = 0x00000000
GTXFIFOSIZ(30) = 0x00000000
GTXFIFOSIZ(31) = 0x00000000
GRXFIFOSIZ(0) = 0x00000305
GRXFIFOSIZ(1) = 0x03050000
GRXFIFOSIZ(2) = 0x03050000
GRXFIFOSIZ(3) = 0x00000000
GRXFIFOSIZ(4) = 0x00000000
GRXFIFOSIZ(5) = 0x00000000
GRXFIFOSIZ(6) = 0x00000000
GRXFIFOSIZ(7) = 0x00000000
GRXFIFOSIZ(8) = 0x00000000
GRXFIFOSIZ(9) = 0x00000000
GRXFIFOSIZ(10) = 0x00000000
GRXFIFOSIZ(11) = 0x00000000
GRXFIFOSIZ(12) = 0x00000000
GRXFIFOSIZ(13) = 0x00000000
GRXFIFOSIZ(14) = 0x00000000
GRXFIFOSIZ(15) = 0x00000000
GRXFIFOSIZ(16) = 0x00000000
GRXFIFOSIZ(17) = 0x00000000
GRXFIFOSIZ(18) = 0x00000000
GRXFIFOSIZ(19) = 0x00000000
GRXFIFOSIZ(20) = 0x00000000
GRXFIFOSIZ(21) = 0x00000000
GRXFIFOSIZ(22) = 0x00000000
GRXFIFOSIZ(23) = 0x00000000
GRXFIFOSIZ(24) = 0x00000000
GRXFIFOSIZ(25) = 0x00000000
GRXFIFOSIZ(26) = 0x00000000
GRXFIFOSIZ(27) = 0x00000000
GRXFIFOSIZ(28) = 0x00000000
GRXFIFOSIZ(29) = 0x00000000
GRXFIFOSIZ(30) = 0x00000000
GRXFIFOSIZ(31) = 0x00000000
GEVNTADRLO(0) = 0xfffff000
GEVNTADRHI(0) = 0x0000ffff
GEVNTSIZ(0) = 0x00001000
GEVNTCOUNT(0) = 0x00000000
GHWPARAMS8 = 0x00000904
GUCTL3 = 0x00000000
GFLADJ = 0x000000a0
DCFG = 0x00cc0814
DCTL = 0x8cf00a00
DEVTEN = 0x00000257
DSTS = 0x000eec88
DGCMDPAR = 0x00000000
DGCMD = 0x00000000
DALEPENA = 0x0000002f
DEPCMDPAR2(0) = 0x00000000
DEPCMDPAR1(0) = 0xffffe000
DEPCMDPAR0(0) = 0x0000ffff
DEPCMD(0) = 0x00000006
DEPCMDPAR2(1) = 0x00000000
DEPCMDPAR1(1) = 0xffffe000
DEPCMDPAR0(1) = 0x0000ffff
DEPCMD(1) = 0x00010006
DEPCMDPAR2(2) = 0x00000000
DEPCMDPAR1(2) = 0xffffc000
DEPCMDPAR0(2) = 0x0000ffff
DEPCMD(2) = 0x00040007
DEPCMDPAR2(3) = 0x00000000
DEPCMDPAR1(3) = 0xffffb000
DEPCMDPAR0(3) = 0x0000ffff
DEPCMD(3) = 0x00030007
DEPCMDPAR2(4) = 0x00000000
DEPCMDPAR1(4) = 0x00000000
DEPCMDPAR0(4) = 0x00000000
DEPCMD(4) = 0x00000000
DEPCMDPAR2(5) = 0x00000000
DEPCMDPAR1(5) = 0xffff9000
DEPCMDPAR0(5) = 0x0000ffff
DEPCMD(5) = 0x00020007
DEPCMDPAR2(6) = 0x00000000
DEPCMDPAR1(6) = 0x00000000
DEPCMDPAR0(6) = 0x00000000
DEPCMD(6) = 0x00000000
DEPCMDPAR2(7) = 0x00000000
DEPCMDPAR1(7) = 0x00000000
DEPCMDPAR0(7) = 0x00000000
DEPCMD(7) = 0x00000000
DEPCMDPAR2(8) = 0x00000000
DEPCMDPAR1(8) = 0x00000000
DEPCMDPAR0(8) = 0x00000000
DEPCMD(8) = 0x00000000
DEPCMDPAR2(9) = 0x00000000
DEPCMDPAR1(9) = 0x00000000
DEPCMDPAR0(9) = 0x00000000
DEPCMD(9) = 0x00000000
DEPCMDPAR2(10) = 0x00000000
DEPCMDPAR1(10) = 0x00000000
DEPCMDPAR0(10) = 0x00000000
DEPCMD(10) = 0x00000000
DEPCMDPAR2(11) = 0x00000000
DEPCMDPAR1(11) = 0x00000000
DEPCMDPAR0(11) = 0x00000000
DEPCMD(11) = 0x00000000
DEPCMDPAR2(12) = 0x00000000
DEPCMDPAR1(12) = 0x00000000
DEPCMDPAR0(12) = 0x00000000
DEPCMD(12) = 0x00000000
DEPCMDPAR2(13) = 0x00000000
DEPCMDPAR1(13) = 0x00000000
DEPCMDPAR0(13) = 0x00000000
DEPCMD(13) = 0x00000000
DEPCMDPAR2(14) = 0x00000000
DEPCMDPAR1(14) = 0x00000000
DEPCMDPAR0(14) = 0x00000000
DEPCMD(14) = 0x00000000
DEPCMDPAR2(15) = 0x00000000
DEPCMDPAR1(15) = 0x00000000
DEPCMDPAR0(15) = 0x00000000
DEPCMD(15) = 0x00000000
DEPCMDPAR2(16) = 0x00000000
DEPCMDPAR1(16) = 0x00000000
DEPCMDPAR0(16) = 0x00000000
DEPCMD(16) = 0x00000000
DEPCMDPAR2(17) = 0x00000000
DEPCMDPAR1(17) = 0x00000000
DEPCMDPAR0(17) = 0x00000000
DEPCMD(17) = 0x00000000
DEPCMDPAR2(18) = 0x00000000
DEPCMDPAR1(18) = 0x00000000
DEPCMDPAR0(18) = 0x00000000
DEPCMD(18) = 0x00000000
DEPCMDPAR2(19) = 0x00000000
DEPCMDPAR1(19) = 0x00000000
DEPCMDPAR0(19) = 0x00000000
DEPCMD(19) = 0x00000000
DEPCMDPAR2(20) = 0x00000000
DEPCMDPAR1(20) = 0x00000000
DEPCMDPAR0(20) = 0x00000000
DEPCMD(20) = 0x00000000
DEPCMDPAR2(21) = 0x00000000
DEPCMDPAR1(21) = 0x00000000
DEPCMDPAR0(21) = 0x00000000
DEPCMD(21) = 0x00000000
DEPCMDPAR2(22) = 0x00000000
DEPCMDPAR1(22) = 0x00000000
DEPCMDPAR0(22) = 0x00000000
DEPCMD(22) = 0x00000000
DEPCMDPAR2(23) = 0x00000000
DEPCMDPAR1(23) = 0x00000000
DEPCMDPAR0(23) = 0x00000000
DEPCMD(23) = 0x00000000
DEPCMDPAR2(24) = 0x00000000
DEPCMDPAR1(24) = 0x00000000
DEPCMDPAR0(24) = 0x00000000
DEPCMD(24) = 0x00000000
DEPCMDPAR2(25) = 0x00000000
DEPCMDPAR1(25) = 0x00000000
DEPCMDPAR0(25) = 0x00000000
DEPCMD(25) = 0x00000000
DEPCMDPAR2(26) = 0x00000000
DEPCMDPAR1(26) = 0x00000000
DEPCMDPAR0(26) = 0x00000000
DEPCMD(26) = 0x00000000
DEPCMDPAR2(27) = 0x00000000
DEPCMDPAR1(27) = 0x00000000
DEPCMDPAR0(27) = 0x00000000
DEPCMD(27) = 0x00000000
DEPCMDPAR2(28) = 0x00000000
DEPCMDPAR1(28) = 0x00000000
DEPCMDPAR0(28) = 0x00000000
DEPCMD(28) = 0x00000000
DEPCMDPAR2(29) = 0x00000000
DEPCMDPAR1(29) = 0x00000000
DEPCMDPAR0(29) = 0x00000000
DEPCMD(29) = 0x00000000
DEPCMDPAR2(30) = 0x00000000
DEPCMDPAR1(30) = 0x00000000
DEPCMDPAR0(30) = 0x00000000
DEPCMD(30) = 0x00000000
DEPCMDPAR2(31) = 0x00000000
DEPCMDPAR1(31) = 0x00000000
DEPCMDPAR0(31) = 0x00000000
DEPCMD(31) = 0x00000000
OCFG = 0x00000000
OCTL = 0x00000040
OEVT = 0x80000000
OEVTEN = 0x00000000
OSTS = 0x0000201f

[-- Attachment #3: regdump.before --]
[-- Type: text/plain, Size: 8201 bytes --]

GSBUSCFG0 = 0x22220009
GSBUSCFG1 = 0x00000700
GTXTHRCFG = 0x00000000
GRXTHRCFG = 0x00000000
GCTL = 0x30c12004
GEVTEN = 0x00000000
GSTS = 0x7e800000
GUCTL1 = 0x0104018a
GSNPSID = 0x5533290a
GGPIO = 0x00000000
GUID = 0x0006066c
GUCTL = 0x02008010
GBUSERRADDR0 = 0x00000000
GBUSERRADDR1 = 0x00000000
GPRTBIMAP0 = 0x00000000
GPRTBIMAP1 = 0x00000000
GHWPARAMS0 = 0x4020400a
GHWPARAMS1 = 0x81e0c93b
GHWPARAMS2 = 0x0130290a
GHWPARAMS3 = 0x04108485
GHWPARAMS4 = 0x47822004
GHWPARAMS5 = 0x04204108
GHWPARAMS6 = 0x09049c20
GHWPARAMS7 = 0x0308044d
GDBGFIFOSPACE = 0x00420000
GDBGLTSSM = 0x41090658
GDBGBMU = 0x01300010
GPRTBIMAP_HS0 = 0x00000000
GPRTBIMAP_HS1 = 0x00000000
GPRTBIMAP_FS0 = 0x00000000
GPRTBIMAP_FS1 = 0x00000000
GUCTL2 = 0x00000000
VER_NUMBER = 0x00000000
VER_TYPE = 0x00000000
GUSB2PHYCFG(0) = 0x40102540
GUSB2PHYCFG(1) = 0x00000000
GUSB2PHYCFG(2) = 0x00000000
GUSB2PHYCFG(3) = 0x00000000
GUSB2PHYCFG(4) = 0x00000000
GUSB2PHYCFG(5) = 0x00000000
GUSB2PHYCFG(6) = 0x00000000
GUSB2PHYCFG(7) = 0x00000000
GUSB2PHYCFG(8) = 0x00000000
GUSB2PHYCFG(9) = 0x00000000
GUSB2PHYCFG(10) = 0x00000000
GUSB2PHYCFG(11) = 0x00000000
GUSB2PHYCFG(12) = 0x00000000
GUSB2PHYCFG(13) = 0x00000000
GUSB2PHYCFG(14) = 0x00000000
GUSB2PHYCFG(15) = 0x00000000
GUSB2I2CCTL(0) = 0x00000000
GUSB2I2CCTL(1) = 0x00000000
GUSB2I2CCTL(2) = 0x00000000
GUSB2I2CCTL(3) = 0x00000000
GUSB2I2CCTL(4) = 0x00000000
GUSB2I2CCTL(5) = 0x00000000
GUSB2I2CCTL(6) = 0x00000000
GUSB2I2CCTL(7) = 0x00000000
GUSB2I2CCTL(8) = 0x00000000
GUSB2I2CCTL(9) = 0x00000000
GUSB2I2CCTL(10) = 0x00000000
GUSB2I2CCTL(11) = 0x00000000
GUSB2I2CCTL(12) = 0x00000000
GUSB2I2CCTL(13) = 0x00000000
GUSB2I2CCTL(14) = 0x00000000
GUSB2I2CCTL(15) = 0x00000000
GUSB2PHYACC(0) = 0x00000000
GUSB2PHYACC(1) = 0x00000000
GUSB2PHYACC(2) = 0x00000000
GUSB2PHYACC(3) = 0x00000000
GUSB2PHYACC(4) = 0x00000000
GUSB2PHYACC(5) = 0x00000000
GUSB2PHYACC(6) = 0x00000000
GUSB2PHYACC(7) = 0x00000000
GUSB2PHYACC(8) = 0x00000000
GUSB2PHYACC(9) = 0x00000000
GUSB2PHYACC(10) = 0x00000000
GUSB2PHYACC(11) = 0x00000000
GUSB2PHYACC(12) = 0x00000000
GUSB2PHYACC(13) = 0x00000000
GUSB2PHYACC(14) = 0x00000000
GUSB2PHYACC(15) = 0x00000000
GUSB3PIPECTL(0) = 0x110e0002
GUSB3PIPECTL(1) = 0x00000000
GUSB3PIPECTL(2) = 0x00000000
GUSB3PIPECTL(3) = 0x00000000
GUSB3PIPECTL(4) = 0x00000000
GUSB3PIPECTL(5) = 0x00000000
GUSB3PIPECTL(6) = 0x00000000
GUSB3PIPECTL(7) = 0x00000000
GUSB3PIPECTL(8) = 0x00000000
GUSB3PIPECTL(9) = 0x00000000
GUSB3PIPECTL(10) = 0x00000000
GUSB3PIPECTL(11) = 0x00000000
GUSB3PIPECTL(12) = 0x00000000
GUSB3PIPECTL(13) = 0x00000000
GUSB3PIPECTL(14) = 0x00000000
GUSB3PIPECTL(15) = 0x00000000
GTXFIFOSIZ(0) = 0x00000042
GTXFIFOSIZ(1) = 0x00420184
GTXFIFOSIZ(2) = 0x01c60184
GTXFIFOSIZ(3) = 0x034a0103
GTXFIFOSIZ(4) = 0x00000000
GTXFIFOSIZ(5) = 0x00000000
GTXFIFOSIZ(6) = 0x00000000
GTXFIFOSIZ(7) = 0x00000000
GTXFIFOSIZ(8) = 0x00000000
GTXFIFOSIZ(9) = 0x00000000
GTXFIFOSIZ(10) = 0x00000000
GTXFIFOSIZ(11) = 0x00000000
GTXFIFOSIZ(12) = 0x00000000
GTXFIFOSIZ(13) = 0x00000000
GTXFIFOSIZ(14) = 0x00000000
GTXFIFOSIZ(15) = 0x00000000
GTXFIFOSIZ(16) = 0x00000000
GTXFIFOSIZ(17) = 0x00000000
GTXFIFOSIZ(18) = 0x00000000
GTXFIFOSIZ(19) = 0x00000000
GTXFIFOSIZ(20) = 0x00000000
GTXFIFOSIZ(21) = 0x00000000
GTXFIFOSIZ(22) = 0x00000000
GTXFIFOSIZ(23) = 0x00000000
GTXFIFOSIZ(24) = 0x00000000
GTXFIFOSIZ(25) = 0x00000000
GTXFIFOSIZ(26) = 0x00000000
GTXFIFOSIZ(27) = 0x00000000
GTXFIFOSIZ(28) = 0x00000000
GTXFIFOSIZ(29) = 0x00000000
GTXFIFOSIZ(30) = 0x00000000
GTXFIFOSIZ(31) = 0x00000000
GRXFIFOSIZ(0) = 0x00000305
GRXFIFOSIZ(1) = 0x03050000
GRXFIFOSIZ(2) = 0x03050000
GRXFIFOSIZ(3) = 0x00000000
GRXFIFOSIZ(4) = 0x00000000
GRXFIFOSIZ(5) = 0x00000000
GRXFIFOSIZ(6) = 0x00000000
GRXFIFOSIZ(7) = 0x00000000
GRXFIFOSIZ(8) = 0x00000000
GRXFIFOSIZ(9) = 0x00000000
GRXFIFOSIZ(10) = 0x00000000
GRXFIFOSIZ(11) = 0x00000000
GRXFIFOSIZ(12) = 0x00000000
GRXFIFOSIZ(13) = 0x00000000
GRXFIFOSIZ(14) = 0x00000000
GRXFIFOSIZ(15) = 0x00000000
GRXFIFOSIZ(16) = 0x00000000
GRXFIFOSIZ(17) = 0x00000000
GRXFIFOSIZ(18) = 0x00000000
GRXFIFOSIZ(19) = 0x00000000
GRXFIFOSIZ(20) = 0x00000000
GRXFIFOSIZ(21) = 0x00000000
GRXFIFOSIZ(22) = 0x00000000
GRXFIFOSIZ(23) = 0x00000000
GRXFIFOSIZ(24) = 0x00000000
GRXFIFOSIZ(25) = 0x00000000
GRXFIFOSIZ(26) = 0x00000000
GRXFIFOSIZ(27) = 0x00000000
GRXFIFOSIZ(28) = 0x00000000
GRXFIFOSIZ(29) = 0x00000000
GRXFIFOSIZ(30) = 0x00000000
GRXFIFOSIZ(31) = 0x00000000
GEVNTADRLO(0) = 0xfffff000
GEVNTADRHI(0) = 0x0000ffff
GEVNTSIZ(0) = 0x00001000
GEVNTCOUNT(0) = 0x00000000
GHWPARAMS8 = 0x00000904
GUCTL3 = 0x00000000
GFLADJ = 0x000000a0
DCFG = 0x00cc0814
DCTL = 0x8cf00a00
DEVTEN = 0x00000257
DSTS = 0x0002cc40
DGCMDPAR = 0x00000000
DGCMD = 0x00000000
DALEPENA = 0x0000002f
DEPCMDPAR2(0) = 0x00000000
DEPCMDPAR1(0) = 0xffffe000
DEPCMDPAR0(0) = 0x0000ffff
DEPCMD(0) = 0x00000006
DEPCMDPAR2(1) = 0x00000000
DEPCMDPAR1(1) = 0xffffe000
DEPCMDPAR0(1) = 0x0000ffff
DEPCMD(1) = 0x00010006
DEPCMDPAR2(2) = 0x00000000
DEPCMDPAR1(2) = 0xffffc000
DEPCMDPAR0(2) = 0x0000ffff
DEPCMD(2) = 0x00040007
DEPCMDPAR2(3) = 0x00000000
DEPCMDPAR1(3) = 0xffffb000
DEPCMDPAR0(3) = 0x0000ffff
DEPCMD(3) = 0x00030007
DEPCMDPAR2(4) = 0x00000000
DEPCMDPAR1(4) = 0x00000000
DEPCMDPAR0(4) = 0x00000000
DEPCMD(4) = 0x00000000
DEPCMDPAR2(5) = 0x00000000
DEPCMDPAR1(5) = 0xffff9000
DEPCMDPAR0(5) = 0x0000ffff
DEPCMD(5) = 0x00020007
DEPCMDPAR2(6) = 0x00000000
DEPCMDPAR1(6) = 0x00000000
DEPCMDPAR0(6) = 0x00000000
DEPCMD(6) = 0x00000000
DEPCMDPAR2(7) = 0x00000000
DEPCMDPAR1(7) = 0x00000000
DEPCMDPAR0(7) = 0x00000000
DEPCMD(7) = 0x00000000
DEPCMDPAR2(8) = 0x00000000
DEPCMDPAR1(8) = 0x00000000
DEPCMDPAR0(8) = 0x00000000
DEPCMD(8) = 0x00000000
DEPCMDPAR2(9) = 0x00000000
DEPCMDPAR1(9) = 0x00000000
DEPCMDPAR0(9) = 0x00000000
DEPCMD(9) = 0x00000000
DEPCMDPAR2(10) = 0x00000000
DEPCMDPAR1(10) = 0x00000000
DEPCMDPAR0(10) = 0x00000000
DEPCMD(10) = 0x00000000
DEPCMDPAR2(11) = 0x00000000
DEPCMDPAR1(11) = 0x00000000
DEPCMDPAR0(11) = 0x00000000
DEPCMD(11) = 0x00000000
DEPCMDPAR2(12) = 0x00000000
DEPCMDPAR1(12) = 0x00000000
DEPCMDPAR0(12) = 0x00000000
DEPCMD(12) = 0x00000000
DEPCMDPAR2(13) = 0x00000000
DEPCMDPAR1(13) = 0x00000000
DEPCMDPAR0(13) = 0x00000000
DEPCMD(13) = 0x00000000
DEPCMDPAR2(14) = 0x00000000
DEPCMDPAR1(14) = 0x00000000
DEPCMDPAR0(14) = 0x00000000
DEPCMD(14) = 0x00000000
DEPCMDPAR2(15) = 0x00000000
DEPCMDPAR1(15) = 0x00000000
DEPCMDPAR0(15) = 0x00000000
DEPCMD(15) = 0x00000000
DEPCMDPAR2(16) = 0x00000000
DEPCMDPAR1(16) = 0x00000000
DEPCMDPAR0(16) = 0x00000000
DEPCMD(16) = 0x00000000
DEPCMDPAR2(17) = 0x00000000
DEPCMDPAR1(17) = 0x00000000
DEPCMDPAR0(17) = 0x00000000
DEPCMD(17) = 0x00000000
DEPCMDPAR2(18) = 0x00000000
DEPCMDPAR1(18) = 0x00000000
DEPCMDPAR0(18) = 0x00000000
DEPCMD(18) = 0x00000000
DEPCMDPAR2(19) = 0x00000000
DEPCMDPAR1(19) = 0x00000000
DEPCMDPAR0(19) = 0x00000000
DEPCMD(19) = 0x00000000
DEPCMDPAR2(20) = 0x00000000
DEPCMDPAR1(20) = 0x00000000
DEPCMDPAR0(20) = 0x00000000
DEPCMD(20) = 0x00000000
DEPCMDPAR2(21) = 0x00000000
DEPCMDPAR1(21) = 0x00000000
DEPCMDPAR0(21) = 0x00000000
DEPCMD(21) = 0x00000000
DEPCMDPAR2(22) = 0x00000000
DEPCMDPAR1(22) = 0x00000000
DEPCMDPAR0(22) = 0x00000000
DEPCMD(22) = 0x00000000
DEPCMDPAR2(23) = 0x00000000
DEPCMDPAR1(23) = 0x00000000
DEPCMDPAR0(23) = 0x00000000
DEPCMD(23) = 0x00000000
DEPCMDPAR2(24) = 0x00000000
DEPCMDPAR1(24) = 0x00000000
DEPCMDPAR0(24) = 0x00000000
DEPCMD(24) = 0x00000000
DEPCMDPAR2(25) = 0x00000000
DEPCMDPAR1(25) = 0x00000000
DEPCMDPAR0(25) = 0x00000000
DEPCMD(25) = 0x00000000
DEPCMDPAR2(26) = 0x00000000
DEPCMDPAR1(26) = 0x00000000
DEPCMDPAR0(26) = 0x00000000
DEPCMD(26) = 0x00000000
DEPCMDPAR2(27) = 0x00000000
DEPCMDPAR1(27) = 0x00000000
DEPCMDPAR0(27) = 0x00000000
DEPCMD(27) = 0x00000000
DEPCMDPAR2(28) = 0x00000000
DEPCMDPAR1(28) = 0x00000000
DEPCMDPAR0(28) = 0x00000000
DEPCMD(28) = 0x00000000
DEPCMDPAR2(29) = 0x00000000
DEPCMDPAR1(29) = 0x00000000
DEPCMDPAR0(29) = 0x00000000
DEPCMD(29) = 0x00000000
DEPCMDPAR2(30) = 0x00000000
DEPCMDPAR1(30) = 0x00000000
DEPCMDPAR0(30) = 0x00000000
DEPCMD(30) = 0x00000000
DEPCMDPAR2(31) = 0x00000000
DEPCMDPAR1(31) = 0x00000000
DEPCMDPAR0(31) = 0x00000000
DEPCMD(31) = 0x00000000
OCFG = 0x00000000
OCTL = 0x00000040
OEVT = 0x80000000
OEVTEN = 0x00000000
OSTS = 0x0000201f

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Thinh Nguyen]

On Fri, Mar 06, 2026, Ravineet Singh wrote:
> Understood, my bad, will send a RFC patch in the future.
> 
> Regdumps (without the patch) are attached.

Please no top-post.

This looks like an issue with the integration of the controller and the
phy/connector. Your phy vbus detection logic needs to properly assert
the proper signals (e.g. vbusvalid/powerpresent etc.) on
connection/disconnection detection.

It's best to fix it there. Forcing every U3/L2 transition to be treated
as if it's a disconnection is problematic. If there's a real U3/L2 state
change and then the host resumes, the device and host are out of sync.

I don't see a good workaround for this.

BR,
Thinh

Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state

[Ravineet Singh]

On Fri, Mar 06, 2026 at 11:05:00PM +0000, Thinh Nguyen wrote:
> On Fri, Mar 06, 2026, Ravineet Singh wrote:
> > Understood, my bad, will send a RFC patch in the future.
> >
> > Regdumps (without the patch) are attached.
>
> Please no top-post.
>
> This looks like an issue with the integration of the controller and the
> phy/connector. Your phy vbus detection logic needs to properly assert
> the proper signals (e.g. vbusvalid/powerpresent etc.) on
> connection/disconnection detection.
>
> It's best to fix it there. Forcing every U3/L2 transition to be treated
> as if it's a disconnection is problematic. If there's a real U3/L2 state
> change and then the host resumes, the device and host are out of sync.
>
> I don't see a good workaround for this.
>
> BR,
> Thinh
Understood, thanks!

BR
Ravineet