All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Michal Nazarewicz <mina86@mina86.com>, linux-usb@vger.kernel.org
Subject: usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS
Date: Fri, 12 Jan 2018 14:01:45 +0200	[thread overview]
Message-ID: <87h8rrwaja.fsf@linux.intel.com> (raw)

Hi,

Lars-Peter Clausen <lars@metafoo.de> writes:
>> Lars-Peter Clausen <lars@metafoo.de> writes:
>>> Some UDC drivers (like the DWC3) expect that the response to a setup()
>> 
>> not some, but *all*. You can only queue a response later IFF you return
>> USB_GADGET_DELAYED_STATUS.
>
> Yeah, but most drivers don't care. DWC3 is one of two which handles
> USB_GADGET_DELAYED_STATUS.

those drivers probably wouldn't work with g_mass_storage ;-)

>>> This fixed random occasional failures that were previously observed on a
>>> DWC3 based system under high system load.
>> 
>> I need to see tracepoint capture from the failure ;-) Care to send them
>> to me for analysis?
>
> I've attached the full trace up to the point where the failure occurs. (The
> tracing infrastructure in the DWC3 driver was very helpful in tracking this
> down btw.).

yeah, that was the idea. I see, however, that you're using an older
kernel based on the your trace format. Just to make sure, did you try
with v4.14? I see the problem is pretty clear and  we will take the
patch, but just to make sure, can you try v4.14?

> The important parts are around:
>
> 125.504109: dwc3_complete_trb: ep0out: ...
> 125.504111: dwc3_prepare_trb: ep0out: ...
>
> Then a few moments later
>
> 125.508529: dwc3_ep0: queueing request ffffffc8787b6d00 to ep0out ...
>
> Usually the queuing would happen before the dwc3_complete_trb and this
> function would remove the URB from the queue. But now it will just sit on

correct :-)

> the pending list waiting for something to happen since the original transfer
> is already over.
>
> When the next control request comes in and we try to queue something for EP0
> the 'list_empty(&dep->pending_list)' check will fail, we return an error and
> the endpoint is stalled and the host will observe an error.

right :-)

btw, you can enable only some events from dwc3 if you want. Usually I
enable all (echo 1 > /.../events/dwc3/enable) and disable read/writel
(echo 0 > /.../events/dwc3/dwc3_readl/enable && echo 0 >
/.../events/dwc3/dwc3_writel/enable), that helps a lot :-)

             reply	other threads:[~2018-01-12 12:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 12:01 Felipe Balbi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-01-12 14:10 usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS Lars-Peter Clausen
2018-01-12 11:41 Lars-Peter Clausen
2018-01-12 11:26 Felipe Balbi
2018-01-12 10:26 Lars-Peter Clausen

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=87h8rrwaja.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-usb@vger.kernel.org \
    --cc=mina86@mina86.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.