stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).