From: Wesley Cheng <wcheng@codeaurora.org>
To: balbi@kernel.org, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Wesley Cheng <wcheng@codeaurora.org>
Subject: [PATCH 0/2] Fix allowing of ep queuing while stopping transfers
Date: Fri, 19 Mar 2021 02:31:23 -0700 [thread overview]
Message-ID: <1616146285-19149-1-git-send-email-wcheng@codeaurora.org> (raw)
commit f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping
transfers") addressed an issue where the DWC3 gadget was still allowing EP
queuing to occur while the pullup disable routine was executing. This led to
a situation where the controller prepares a TRB, which will be unmapped by the
stop active transfer call.
In addition to the above, there are a few other places in the DWC3 gadget where
we need to block preparing of TRBs:
1. While the DWC3 gadget cleans up completed TRBs (during
dwc3_gadget_endpoint_trbs_complete()), DWC3 gadget giveback is utilized and
will release the dwc->lock. If a pullup disable call occurs while the
cleanup is happening, then there is a chance dwc3_gadget_ep_should_continue
will prepare a TRB, which will later on be unmapped by the stop active
transfer in the pullup disable path.
2. If we are in the CONFIGURED state and the host issues a bus RESET. In this
situation, the connected flag is still set to true while we stop active
transfers, which can lead to the same initial problem. Ideally, function
drivers would stop any pending usb requests through dwc3_reset_gadget()
using the EP disable call, but for some function drivers, this does not
occur synchronously in their disable() callback. These functions would rely
on the stop active transfers in the reset handler to issue the endxfer cmd.
Wesley Cheng (2):
usb: dwc3: gadget: Avoid continuing preparing TRBs during teardown
usb: dwc3: gadget: Ignore EP queue requests during bus reset
drivers/usb/dwc3/gadget.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next reply other threads:[~2021-03-19 9:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 9:31 Wesley Cheng [this message]
2021-03-19 9:31 ` [PATCH 1/2] usb: dwc3: gadget: Avoid continuing preparing TRBs during teardown Wesley Cheng
2021-03-19 9:31 ` [PATCH 2/2] usb: dwc3: gadget: Ignore EP queue requests during bus reset Wesley Cheng
2021-03-20 0:40 ` Thinh Nguyen
2021-03-20 1:07 ` Wesley Cheng
2021-03-20 2:01 ` Thinh Nguyen
2021-03-20 2:14 ` Thinh Nguyen
2021-03-20 5:30 ` Wesley Cheng
2021-03-23 23:47 ` Thinh Nguyen
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=1616146285-19149-1-git-send-email-wcheng@codeaurora.org \
--to=wcheng@codeaurora.org \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.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).