From: Guenter Roeck <linux@roeck-us.net>
To: Boris ARZUR <boris@konbu.org>
Cc: linux-usb@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Minas Harutyunyan <hminas@synopsys.com>,
William Wu <william.wu@rock-chips.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Douglas Anderson <dianders@chromium.org>,
a.seppala@gmail.com
Subject: Re: [PATCH] usb: dwc2: extend treatment for incomplete transfer
Date: Mon, 24 Feb 2020 16:18:00 -0800 [thread overview]
Message-ID: <20200225001800.GA13099@roeck-us.net> (raw)
In-Reply-To: <20200223120247.GA21552@tungsten>
On Sun, Feb 23, 2020 at 09:02:47PM +0900, Boris ARZUR wrote:
> Hi Guenter,
>
> I tried your series of patch. rndis_host tethering & loading the machine
> seems to work fine. No more crashing.
>
> That being said, I now have an issue with regular USB keys (I tried a few):
> usb 3-1: reset high-speed USB device number 2 using dwc2
>
> I was able to reproduce this issue with the unpatched kernel, by disabling
> the early return in dwc2_alloc_dma_aligned_buffer(), see attached.
> There are times were re-allocation fails, either with your patch or with
> the (almost-)original code.
>
> In particular it seems that there is a packet of lenght 13, usb_urb_dir_in() == true,
> usb_pipetype(urb->pipe) == PIPE_BULK, that comes in every 2s or so, that
> does not reallocate properly.
>
Those packets have URB_NO_TRANSFER_DMA_MAP set. If that is the case,
the packet is not received into the transfer buffer but into an already
assigned DMA buffer/address. Providing a temporary buffer does not have
an effect; the packet is still received into the orginal buffer (and then
overwritten with the data in the temporary buffer). That means we have
to leave such packets alone.
I'll send out an updated series later tonight or tomorrow. I'll probably
send it as RFT series this time.
Guenter
next prev parent reply other threads:[~2020-02-25 0:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 21:39 [PATCH] usb: dwc2: extend treatment for incomplete transfer Guenter Roeck
2020-02-11 5:49 ` Boris ARZUR
2020-02-11 13:26 ` Guenter Roeck
2020-02-11 16:15 ` Guenter Roeck
2020-02-15 5:36 ` Boris ARZUR
2020-02-19 21:10 ` Guenter Roeck
2020-02-23 11:00 ` Antti Seppälä
2020-02-23 12:10 ` Boris ARZUR
2020-02-23 13:45 ` Guenter Roeck
2020-02-23 18:20 ` Antti Seppälä
2020-02-23 18:47 ` Guenter Roeck
2020-02-23 12:02 ` Boris ARZUR
2020-02-23 13:53 ` Guenter Roeck
2020-02-25 0:18 ` Guenter Roeck [this message]
2020-02-20 21:22 ` Guenter Roeck
-- strict thread matches above, loose matches on Subject: below --
2019-11-05 3:29 Boris ARZUR
2019-11-05 3:39 ` Boris ARZUR
2020-01-31 22:09 ` Guenter Roeck
2020-02-02 5:15 ` Boris ARZUR
2020-02-02 18:52 ` Guenter Roeck
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=20200225001800.GA13099@roeck-us.net \
--to=linux@roeck-us.net \
--cc=a.seppala@gmail.com \
--cc=boris@konbu.org \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hminas@synopsys.com \
--cc=linux-usb@vger.kernel.org \
--cc=william.wu@rock-chips.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 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).