From: Greg KH <gregkh@linuxfoundation.org>
To: Wesley Cheng <quic_wcheng@quicinc.com>
Cc: Thinh.Nguyen@synopsys.com, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, quic_jackp@quicinc.com,
quic_ugoswami@quicinc.com
Subject: Re: [PATCH v3 2/3] usb: dwc3: gadget: Stall and restart EP0 if host is unresponsive
Date: Thu, 13 Apr 2023 09:47:50 +0200 [thread overview]
Message-ID: <2023041310-absolute-task-8ba6@gregkh> (raw)
In-Reply-To: <20230410231954.437-3-quic_wcheng@quicinc.com>
On Mon, Apr 10, 2023 at 04:19:53PM -0700, Wesley Cheng wrote:
> It was observed that there are hosts that may complete pending SETUP
> transactions before the stop active transfers and controller halt occurs,
> leading to lingering endxfer commands on DEPs on subsequent pullup/gadget
> start iterations.
>
> dwc3_gadget_ep_disable name=ep8in flags=0x3009 direction=1
> dwc3_gadget_ep_disable name=ep4in flags=1 direction=1
> dwc3_gadget_ep_disable name=ep3out flags=1 direction=0
> usb_gadget_disconnect deactivated=0 connected=0 ret=0
>
> The sequence shows that the USB gadget disconnect (dwc3_gadget_pullup(0))
> routine completed successfully, allowing for the USB gadget to proceed with
> a USB gadget connect. However, if this occurs the system runs into an
> issue where:
>
> BUG: spinlock already unlocked on CPU
> spin_bug+0x0
> dwc3_remove_requests+0x278
> dwc3_ep0_out_start+0xb0
> __dwc3_gadget_start+0x25c
>
> This is due to the pending endxfers, leading to gadget start (w/o lock
> held) to execute the remove requests, which will unlock the dwc3
> spinlock as part of giveback.
>
> To mitigate this, resolve the pending endxfers on the pullup disable
> path by re-locating the SETUP phase check after stop active transfers, since
> that is where the DWC3_EP_DELAY_STOP is potentially set. This also allows
> for handling of a host that may be unresponsive by using the completion
> timeout to trigger the stall and restart for EP0.
>
> Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage")
I'm confused. You have a Fixes: tag here, yet this patch depends on
patch 1/3, right? This implies that you do not want or need this to be
backported to any stable kernels, right?
Or do you? If so, put the bug fixes first, and properly add a cc:
stable tag, so that they will get backported correctly.
If not, then don't even put a fixes tag on it as obviously it isn't a
bugfix that is relevant to track anywhere, and then this is just a
normal new feature to be added to the driver.
Please resolve this and submit a new series based on your decision.
thanks,
greg k-h
next prev parent reply other threads:[~2023-04-13 7:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-10 23:19 [PATCH v3 0/3] Avoid having pending end transfers on soft disconnect Wesley Cheng
2023-04-10 23:19 ` [PATCH v3 1/3] usb: dwc3: gadget: Refactor EP0 forced stall/restart into a separate API Wesley Cheng
2023-04-11 1:13 ` Thinh Nguyen
2023-04-10 23:19 ` [PATCH v3 2/3] usb: dwc3: gadget: Stall and restart EP0 if host is unresponsive Wesley Cheng
2023-04-11 1:13 ` Thinh Nguyen
2023-04-13 7:47 ` Greg KH [this message]
2023-04-10 23:19 ` [PATCH v3 3/3] usb: dwc3: gadget: Execute gadget stop after halting the controller Wesley Cheng
2023-04-11 1:14 ` 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=2023041310-absolute-task-8ba6@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=quic_jackp@quicinc.com \
--cc=quic_ugoswami@quicinc.com \
--cc=quic_wcheng@quicinc.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