[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79f52dae-7c16-4545-b36a-fcf481e66da5@quicinc.com>
Date: Tue, 4 Jun 2024 14:22:19 +0530
From: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To: Mike Looijmans <mike.looijmans@...ic.nl>,
Thinh Nguyen
<Thinh.Nguyen@...opsys.com>
CC: "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
Greg
Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Inform system of suspended state
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".
>
Powered by blists - more mailing lists