From: Felipe Balbi <balbi@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>,
Yang Fei <fei.yang@intel.com>, Thinh Nguyen <thinhn@synopsys.com>,
Tejas Joglekar <tejas.joglekar@synopsys.com>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>,
Jack Pham <jackp@codeaurora.org>, Todd Kjos <tkjos@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
Linux USB List <linux-usb@vger.kernel.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: gadget: Check for IOC/LST bit in TRB->ctrl fields
Date: Wed, 29 Jan 2020 13:19:03 +0200 [thread overview]
Message-ID: <87imku8q8o.fsf@kernel.org> (raw)
In-Reply-To: <CALAqxLUNg_Oww17U=BW9XTzZAdkCoCWCg=92Js17SexhT8gy6g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]
Hi,
John Stultz <john.stultz@linaro.org> writes:
> On Tue, Jan 28, 2020 at 11:23 PM Felipe Balbi <balbi@kernel.org> wrote:
>> John Stultz <john.stultz@linaro.org> writes:
>> > From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
>> >
>> > The current code in dwc3_gadget_ep_reclaim_completed_trb() will
>> > check for IOC/LST bit in the event->status and returns if
>> > IOC/LST bit is set. This logic doesn't work if multiple TRBs
>> > are queued per request and the IOC/LST bit is set on the last
>> > TRB of that request.
>> >
>> > Consider an example where a queued request has multiple queued
>> > TRBs and IOC/LST bit is set only for the last TRB. In this case,
>> > the core generates XferComplete/XferInProgress events only for
>> > the last TRB (since IOC/LST are set only for the last TRB). As
>> > per the logic in dwc3_gadget_ep_reclaim_completed_trb()
>> > event->status is checked for IOC/LST bit and returns on the
>> > first TRB. This leaves the remaining TRBs left unhandled.
>> >
>> > Similarly, if the gadget function enqueues an unaligned request
>> > with sglist already in it, it should fail the same way, since we
>> > will append another TRB to something that already uses more than
>> > one TRB.
>> >
>> > To aviod this, this patch changes the code to check for IOC/LST
>> > bits in TRB->ctrl instead.
>> >
>> > At a practical level, this patch resolves USB transfer stalls seen
>> > with adb on dwc3 based HiKey960 after functionfs gadget added
>> > scatter-gather support around v4.20.
>> >
>> > Cc: Felipe Balbi <balbi@kernel.org>
>> > Cc: Yang Fei <fei.yang@intel.com>
>> > Cc: Thinh Nguyen <thinhn@synopsys.com>
>> > Cc: Tejas Joglekar <tejas.joglekar@synopsys.com>
>> > Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>> > Cc: Jack Pham <jackp@codeaurora.org>
>> > Cc: Todd Kjos <tkjos@google.com>
>> > Cc: Greg KH <gregkh@linuxfoundation.org>
>> > Cc: Linux USB List <linux-usb@vger.kernel.org>
>> > Cc: stable <stable@vger.kernel.org>
>> > Tested-by: Tejas Joglekar <tejas.joglekar@synopsys.com>
>> > Reviewed-by: Thinh Nguyen <thinhn@synopsys.com>
>> > Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
>> > [jstultz: forward ported to mainline, reworded commit log, reworked
>> > to only check trb->ctrl as suggested by Felipe]
>> > Signed-off-by: John Stultz <john.stultz@linaro.org>
>>
>> since v5.5 is already merged, I'll send this to Greg once -rc1 is
>> tagged. It's already in my testing/fixes branch waiting for a pull
>> request.
>
> Great, thanks so much for queueing this! I'll be digging on the db845c
no worries, it was way past the time :-)
> side wrt the dma-api issue to hopefully get that one sorted as well.
Thanks, that would, indeed, be great :-)
> Thanks again for the help and analysis!
no worries. If you find anything odd, just collect traces and I can help
have a look.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2020-01-29 11:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 19:30 [PATCH v2] usb: dwc3: gadget: Check for IOC/LST bit in TRB->ctrl fields John Stultz
2020-01-28 13:22 ` Felipe Balbi
2020-01-28 17:55 ` John Stultz
2020-01-28 18:23 ` Thinh Nguyen
2020-01-29 7:16 ` Felipe Balbi
2020-01-29 7:23 ` Felipe Balbi
2020-01-29 7:35 ` John Stultz
2020-01-29 11:19 ` Felipe Balbi [this message]
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=87imku8q8o.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=andrzej.p@collabora.com \
--cc=anurag.kumar.vulisha@xilinx.com \
--cc=fei.yang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jackp@codeaurora.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tejas.joglekar@synopsys.com \
--cc=thinhn@synopsys.com \
--cc=tkjos@google.com \
/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.