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.