From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: "Yang\, Fei" <fei.yang@intel.com>,
"john.stultz\@linaro.org" <john.stultz@linaro.org>,
"andrzej.p\@collabora.com" <andrzej.p@collabora.com>,
"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"stable\@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH V2] usb: dwc3: gadget: trb_dequeue is not updated properly
Date: Fri, 19 Jul 2019 10:27:57 +0300 [thread overview]
Message-ID: <87muhascua.fsf@linux.intel.com> (raw)
In-Reply-To: <02E7334B1630744CBDC55DA8586225837F8DD883@ORSMSX102.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]
"Yang, Fei" <fei.yang@intel.com> writes:
Hi,
>> Can only be true for last TRB
>>
> | if (event->status & DEPEVT_STATUS_IOC)
> | return 1;
>
> This is the problem. The whole USB request gets only one interrupt
> when the last TRB completes, so dwc3_gadget_ep_reclaim_trb_sg() gets
> called with event->status = 0x6 which has DEPEVT_STATUS_IOC bit
> set. Thus dwc3_gadget_ep_reclaim_completed_trb() returns 1 for the
> first TRB and the for-loop ends without having a chance to iterate
> through the sg list.
IOC is only set for the last TRB, so this will iterate over and over
again until it reaches the last TRB. Please collect tracepoints of the
failure case.
>> If we have a short packet, then we may fall here. Is that the case?
>
> No need for a short packet to make it fail. In my case below, a 16384
> byte request got slipt into 4 TRBs of 4096 bytes. All TRBs were
> completed normally, but the for-loop in
> dwc3_gadget_ep_reclaim_trb_sg() was terminated right after handling
> the first TRB. After that the trb_dequeue is messed up.
I need tracepoints to se what's going on, please collect tracepoints.
> buffer_addr,size,type,ioc,isp_imi,csp,chn,lst,hwo
> 0000000077849000, 4096,normal,0,0,1,1,0,0
> 000000007784a000, 4096,normal,0,0,1,1,0,0
> 000000007784b000, 4096,normal,0,0,1,1,0,0
> 000000007784c000, 4096,normal,1,0,1,0,0,0
> 000000007784d000, 512,normal,1,0,1,0,0,0
>
> My first version of the patch was trying to address the issue in
> dwc3_gadget_ep_reclaim_completed_trb(), but then I thought it's a bad
> idea to touch this function because that is also called from non
> scatter_gather list case, and I was not sure if returning 1 for the
> linear case is correct or not.
That function *must* be called for all cases. We want to reduce the
amount of special cases so code is more straight forward and easier to
maintain. Again, please collect tracepoints of the failure case with the
latest tag from Linus, otherwise you won't be able to convince me we
need your patch.
I also think your version is the wrong way to sort it out.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-07-19 7:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 20:53 [PATCH V2] usb: dwc3: gadget: trb_dequeue is not updated properly fei.yang
2019-07-18 8:55 ` Felipe Balbi
2019-07-18 18:26 ` Yang, Fei
2019-07-19 0:54 ` Yang, Fei
2019-07-19 7:27 ` Felipe Balbi [this message]
2019-07-19 21:04 ` Yang, Fei
2019-08-08 6:01 ` Felipe Balbi
2019-08-09 18:53 ` Yang, Fei
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=87muhascua.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=andrzej.p@collabora.com \
--cc=fei.yang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).