From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Linux USB <linux-usb@vger.kernel.org>,
"stable\@vger.kernel.org" <stable@vger.kernel.org>,
John Youn <John.Youn@synopsys.com>
Subject: RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid
Date: Wed, 08 Mar 2017 13:55:39 +0200 [thread overview]
Message-ID: <87k2800ypw.fsf@linux.intel.com> (raw)
In-Reply-To: <87mvcw0zxc.fsf@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
Hi,
Felipe Balbi <felipe.balbi@linux.intel.com> writes:
>>> I've been looking at this and based on sniffer and dwc3 tracepoints, it
>>> seems like dwc3 is behaving properly. The real issue seems to be that
>>> g_mass_storage isn't queueing a new request to IN endpoint.
>>>
>>> I'll continue debugging this and try to find a solution that doesn't
>>> involve reverting $subject.
>>
>> oh no, wait. ep2out misses XferInProgress:
>>
>> file-storage-1592 [000] d..1 152.809922: dwc3_ep_queue: ep2out: req ffff88003cd6ee40 length 0/512 zsI ==> -115
>> file-storage-1592 [000] d..1 152.809931: dwc3_prepare_trb: ep2out: 3/8 trb ffff88003a196050 buf 000000002d5e4000 size 512 ctrl 00000819 (HlcS:sC:normal)
>> file-storage-1592 [000] d..1 152.809942: dwc3_gadget_ep_cmd: ep2out: cmd 'Update Transfer' [262151] params 00000000 00000000 00000000 --> status: Successful
>> file-storage-1592 [000] .... 152.809951: usb_ep_queue: ep2out: length 0/512 sgs 0/0 stream 0 zsI status -115 --> 0
>> irq/34-dwc3-1593 [001] d..1 152.810212: dwc3_event: event (0000c040): ep0out: Transfer Complete [Setup Phase]
>> irq/34-dwc3-1593 [001] d..1 152.810218: dwc3_ctrl_req: bRequestType 02 bRequest 01 wValue 0000 wIndex 0002 wLength 0
>> irq/34-dwc3-1593 [001] d..1 152.810228: __dwc3_gadget_ep_set_halt: ep2out: NOT stalled
>>
>> Sniffer shows me this completing, but I don't see IRQ for this.
>
> BTW, I just tested without $subject and it fails the same way. This is
> caused by something else. Can you rerun your bisect while I look at the
> problem here?
Okay, found it. This is caused by the ep_dequeue bug that I already
fixed. see [1] for that
[1] https://marc.info/?i=20170217105759.24356-1-felipe.balbi@linux.intel.com
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-03-08 11:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 11:40 [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid Felipe Balbi
[not found] ` <30102591E157244384E984126FC3CB4F2FF567F3@US01WEMBX2.internal.synopsys.com>
2017-03-08 9:29 ` Felipe Balbi
2017-03-08 9:33 ` Felipe Balbi
2017-03-08 11:29 ` Felipe Balbi
2017-03-08 11:55 ` Felipe Balbi [this message]
2017-04-04 8:09 ` Felipe Balbi
2017-04-04 15:53 ` John Youn
2017-04-05 8:31 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k2800ypw.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=John.Youn@synopsys.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.