All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: felipe.balbi@linux.intel.com, brian.e.rogers@intel.com,
	gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "usb: dwc3: gadget: fix for short pkts during chained xfers" has been added to the 4.7-stable tree
Date: Fri, 02 Sep 2016 16:23:57 +0200	[thread overview]
Message-ID: <14728262376678@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    usb: dwc3: gadget: fix for short pkts during chained xfers

to the 4.7-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     usb-dwc3-gadget-fix-for-short-pkts-during-chained-xfers.patch
and it can be found in the queue-4.7 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From e5b36ae2f851024d43c76e51f395d32ce8d769ce Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Wed, 10 Aug 2016 11:13:26 +0300
Subject: usb: dwc3: gadget: fix for short pkts during chained xfers

From: Felipe Balbi <felipe.balbi@linux.intel.com>

commit e5b36ae2f851024d43c76e51f395d32ce8d769ce upstream.

DWC3 has one interesting peculiarity with chained
transfers. If we setup N chained transfers and we
get a short packet before processing all N TRBs,
DWC3 will (conditionally) issue a XferComplete or
XferInProgress event and retire all TRBs from the
one which got a short packet to the last without
clearing their HWO bits.

This means SW must clear HWO bit manually, which
this patch is doing.

Cc: Brian E Rogers <brian.e.rogers@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/dwc3/gadget.c |   23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1897,7 +1897,8 @@ static void dwc3_gadget_free_endpoints(s
 
 static int __dwc3_cleanup_done_trbs(struct dwc3 *dwc, struct dwc3_ep *dep,
 		struct dwc3_request *req, struct dwc3_trb *trb,
-		const struct dwc3_event_depevt *event, int status)
+		const struct dwc3_event_depevt *event, int status,
+		int chain)
 {
 	unsigned int		count;
 	unsigned int		s_pkt = 0;
@@ -1905,6 +1906,19 @@ static int __dwc3_cleanup_done_trbs(stru
 
 	trace_dwc3_complete_trb(dep, trb);
 
+	/*
+	 * If we're in the middle of series of chained TRBs and we
+	 * receive a short transfer along the way, DWC3 will skip
+	 * through all TRBs including the last TRB in the chain (the
+	 * where CHN bit is zero. DWC3 will also avoid clearing HWO
+	 * bit and SW has to do it manually.
+	 *
+	 * We're going to do that here to avoid problems of HW trying
+	 * to use bogus TRBs for transfers.
+	 */
+	if (chain && (trb->ctrl & DWC3_TRB_CTRL_HWO))
+		trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+
 	if ((trb->ctrl & DWC3_TRB_CTRL_HWO) && status != -ESHUTDOWN)
 		/*
 		 * We continue despite the error. There is not much we
@@ -1916,6 +1930,7 @@ static int __dwc3_cleanup_done_trbs(stru
 		 */
 		dev_err(dwc->dev, "%s's TRB (%p) still owned by HW\n",
 				dep->name, trb);
+
 	count = trb->size & DWC3_TRB_SIZE_MASK;
 
 	if (dep->direction) {
@@ -1977,10 +1992,13 @@ static int dwc3_cleanup_done_reqs(struct
 	int			ret;
 
 	do {
+		int chain;
+
 		req = next_request(&dep->started_list);
 		if (WARN_ON_ONCE(!req))
 			return 1;
 
+		chain = req->request.num_mapped_sgs > 0;
 		i = 0;
 		do {
 			slot = req->first_trb_index + i;
@@ -1990,9 +2008,8 @@ static int dwc3_cleanup_done_reqs(struct
 			trb = &dep->trb_pool[slot];
 			count += trb->size & DWC3_TRB_SIZE_MASK;
 
-
 			ret = __dwc3_cleanup_done_trbs(dwc, dep, req, trb,
-					event, status);
+					event, status, chain);
 			if (ret)
 				break;
 		} while (++i < req->request.num_mapped_sgs);


Patches currently in stable-queue which might be from felipe.balbi@linux.intel.com are

queue-4.7/usb-dwc3-pci-add-intel-kabylake-pci-id.patch
queue-4.7/usb-misc-usbtest-usbtest_do_ioctl-may-return-positive-integer.patch
queue-4.7/usb-renesas_usbhs-fix-receiving-data-corrupt-on-r-car-gen3-with-dmac.patch
queue-4.7/usb-renesas_usbhs-clear-the-brdysts-in-usbhsg_ep_enable.patch
queue-4.7/usb-gadget-fix-gadgetfs-aio-support.patch
queue-4.7/usb-dwc3-gadget-always-cleanup-all-trbs.patch
queue-4.7/usb-renesas_usbhs-use-dmac-only-if-the-pipe-type-is-bulk.patch
queue-4.7/usb-gadget-fsl_qe_udc-off-by-one-in-setup_received_handle.patch
queue-4.7/usb-dwc3-gadget-fix-for-short-pkts-during-chained-xfers.patch
queue-4.7/usb-dwc3-gadget-increment-request-actual-once.patch

                 reply	other threads:[~2016-09-02 14:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=14728262376678@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=brian.e.rogers@intel.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=stable-commits@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.