linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>
Cc: John Youn <John.Youn@synopsys.com>
Subject: Re: [PATCH] usb: dwc3: gadget: Remove incomplete check
Date: Mon, 16 Mar 2020 09:00:12 +0200	[thread overview]
Message-ID: <87blow239f.fsf@kernel.org> (raw)
In-Reply-To: <df600201-0063-bb5f-19be-ecbeaada37f0@synopsys.com>

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


Hi,

Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
>> Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
>>> We only care to resume transfer for SG because the request maybe
>>> partially completed. dwc3_gadget_ep_request_completed() doesn't check
>>> that of a request, at least not fully.
>>>
>>> 1) It doesn't account for OUT direction.
>>> 2) It doesn't account for isoc. For isoc, a request maybe completed with
>>> partial data.
>> I would rather fix the function for these cases instead of removing it
>> completely. While at that, also move the req->num_pending_sgs check
>> inside dwc3_gadget_ep_request_completed()
>>
>
> If we want to keep this function, the only thing this function does is 
> to check req->num_pending_sgs. We'd only resume the request because 
> there are pending TRBs from SG not completed yet. If all the TRBs of a 
> request are completed, regardless if all the data are received/sent, we 
> don't queue them again. Do you still want to have this function?

The function gives a name to a very specific "concept", that of a
completed request. You can see that even today, the function is super
simple: OUT direction is always completed, IN direction is completed
when actual == length, we're just missing the pending_sgs check. So
something like the hunks below.

One thing I don't get from your patch is why you're completely removing
the function and why isn't req->direction and actual == length not
needed anymore. Could you explain?

hunks:

@@ -2482,7 +2482,8 @@ static int dwc3_gadget_ep_reclaim_trb_linear(struct dwc3_ep *dep,
 			event, status, false);
 }
 
-static bool dwc3_gadget_ep_request_completed(struct dwc3_request *req)
+static bool dwc3_gadget_ep_request_completed(struct dwc3_ep *dep,
+		struct dwc3_request *req)
 {
 	/*
 	 * For OUT direction, host may send less than the setup
@@ -2491,6 +2492,16 @@ static bool dwc3_gadget_ep_request_completed(struct dwc3_request *req)
 	if (!req->direction)
 		return true;
 
+	/*
+	 * If there are pending scatterlist entries, we should
+	 * continue processing them.
+	 */
+	if (req->num_pending_sgs)
+		return false;
+
+	if (usb_endpoint_xfer_isoc(dep->endpoint.desc))
+		do_something();
+
 	return req->request.actual == req->request.length;
 }
 
@@ -2515,8 +2526,7 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
 
 	req->request.actual = req->request.length - req->remaining;
 
-	if (!dwc3_gadget_ep_request_completed(req) ||
-			req->num_pending_sgs) {
+	if (!dwc3_gadget_ep_request_completed(dep, req))
 		__dwc3_gadget_kick_transfer(dep);
 		goto out;
 	}

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2020-03-16  7:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06  3:44 [PATCH] usb: dwc3: gadget: Remove incomplete check Thinh Nguyen
2020-03-15  9:19 ` Felipe Balbi
2020-03-16  0:33   ` Thinh Nguyen
2020-03-16  7:00     ` Felipe Balbi [this message]
2020-03-16 20:37       ` Thinh Nguyen
2020-03-29  8:03         ` Felipe Balbi
2020-03-29 23:44           ` Thinh Nguyen
2020-03-30  8:26             ` Felipe Balbi
2020-03-30 19:30               ` Thinh Nguyen
2020-03-30 21:34                 ` Felipe Balbi
2020-03-31  1:47                   ` Thinh Nguyen
2020-03-31  8:12                     ` Felipe Balbi
2020-03-31  8:39                       ` Thinh Nguyen

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=87blow239f.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@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).