From: "He, Bo" <bo.he@intel.com>
To: Felipe Balbi <felipe.balbi@linux.intel.com>,
Evan Green <evgreen@google.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Sam Protsenko <semen.protsenko@linaro.org>,
Doug Anderson <dianders@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>
Subject: RE: Backporting dwc3 gadget fixes
Date: Wed, 23 Jan 2019 06:55:50 +0000 [thread overview]
Message-ID: <CD6925E8781EFD4D8E11882D20FC406D52A37B7A@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <8736pjkhp6.fsf@linux.intel.com>
the issue is not seen on 4.9, I check the commit cf3113d8 is first introduced in kernel 4.11-rc2.
commit cf3113d893d4427b166ec8695460efa7aa660923
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date: Fri Feb 17 11:12:44 2017 +0200
usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue
If request was already started, this means we had to
stop the transfer. With that we also need to ignore
all TRBs used by the request, however TRBs can only
be modified after completion of END_TRANSFER
command. So what we have to do here is wait for
END_TRANSFER completion and only after that jump
over TRBs by clearing HWO and incrementing dequeue
pointer.
Note that we have 2 possible types of transfers
here:
i) Linear buffer request
ii) SG-list based request
SG-list based requests will have r->num_pending_sgs
set to a valid number (> 0). Linear requests,
normally use a single TRB.
For each of these two cases, if r->unaligned flag is
set, one extra TRB has been used to align transfer
size to wMaxPacketSize.
All of these cases need to be taken into
consideration so we don't mess up our TRB ring
pointers.
Tested-by: Janusz Dziedzic <januszx.dziedzic@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
-----Original Message-----
From: Felipe Balbi <felipe.balbi@linux.intel.com>
Sent: Wednesday, January 23, 2019 2:32 PM
To: Evan Green <evgreen@google.com>; stable@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>; Sam Protsenko <semen.protsenko@linaro.org>; He, Bo <bo.he@intel.com>; Doug Anderson <dianders@chromium.org>; Stephen Boyd <swboyd@chromium.org>; Matthias Kaehlcke <mka@chromium.org>
Subject: Re: Backporting dwc3 gadget fixes
Hi Evan,
Evan Green <evgreen@google.com> writes:
> Hello stablers,
>
> With the following revert being backported to stable:
> a9c859033f6ec Revert "usb: gadget: ffs: Fix BUG when userland exits
> with submitted AIO transfers"
>
> The original bug it fixed is back. I wonder if we should be
Is it so that the original bug only happens with dwc3? If so, then we should definitely backport the series below.
> backporting the series that seems to quietly fix that issue:
> fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer
> d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list
> d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list
> 7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()
> c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on
> ->dequeue()
> 09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request
> 1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags
>
> (Patch 1/8 of the original series was already backported). I know we
> saw this with 4.19, I'm not sure which other versions it would go
> into.
We could ask Greg to backport at least for v4.14. I'm not sure this applies to v4.9.
--
balbi
next prev parent reply other threads:[~2019-01-23 6:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 0:37 Backporting dwc3 gadget fixes Evan Green
2019-01-23 6:32 ` Felipe Balbi
2019-01-23 6:55 ` He, Bo [this message]
2019-01-23 18:46 ` Evan Green
2019-01-29 10:22 ` Greg KH
2019-01-29 19:15 ` Evan Green
2019-02-04 9:11 ` Greg KH
2019-02-04 21:13 ` Evan Green
2019-02-11 13:41 ` Greg KH
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=CD6925E8781EFD4D8E11882D20FC406D52A37B7A@SHSMSX103.ccr.corp.intel.com \
--to=bo.he@intel.com \
--cc=dianders@chromium.org \
--cc=evgreen@google.com \
--cc=felipe.balbi@linux.intel.com \
--cc=mka@chromium.org \
--cc=semen.protsenko@linaro.org \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=swboyd@chromium.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).