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@xxxxxxxx
W: www.topic.nl