In case there is a host which takes time to complete a SETUP transaction,
during the soft disconnect sequence multiple DWC3 EPs will have their
DWC3_EP_DELAY_STOP flag set w/o issuing the end transfer command. Once the
controller halt sequence occurs, the soft disconnect is successful, and
the subsequent soft connect will attempt to flush the pending end transfers.
Soft disconnect sequence:
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
Soft connect bug:
BUG: spinlock already unlocked on CPU
spin_bug+0x0
dwc3_remove_requests+0x278
dwc3_ep0_out_start+0xb0
__dwc3_gadget_start+0x25c
The bug occurs due to the flush of the pending end transfers, as the gadget
start routine is not held with a spinlock. However, if the DWC3_EP_DELAY_STOP
is set, it will call the giveback API, which attempts to unlock the dwc->lock.
Ideally, the DWC3 gadget should not have pending end transfers on a soft
connect, so fix this by:
1. 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.
2. Do not call gadget stop until the poll for controller halt is
completed. DEVTEN is cleared as part of gadget stop, so the intention to
allow ep0 events to continue while waiting for controller halt is not
happening.
Changes in v3:
- Removed fixes tag in the refactor change
Wesley Cheng (3):
usb: dwc3: gadget: Refactor EP0 forced stall/restart into a separate
API
usb: dwc3: gadget: Stall and restart EP0 if host is unresponsive
usb: dwc3: gadget: Execute gadget stop after halting the controller
drivers/usb/dwc3/gadget.c | 101 ++++++++++++++++++++++----------------
1 file changed, 58 insertions(+), 43 deletions(-)
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")
Signed-off-by: Wesley Cheng <[email protected]>
---
drivers/usb/dwc3/gadget.c | 42 +++++++++++++++++++++++----------------
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 320e30476c88..91768f1bdbaf 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2546,29 +2546,17 @@ static int __dwc3_gadget_start(struct dwc3 *dwc);
static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc)
{
unsigned long flags;
+ int ret;
spin_lock_irqsave(&dwc->lock, flags);
dwc->connected = false;
/*
- * Per databook, when we want to stop the gadget, if a control transfer
- * is still in process, complete it and get the core into setup phase.
+ * Attempt to end pending SETUP status phase, and not wait for the
+ * function to do so.
*/
- if (dwc->ep0state != EP0_SETUP_PHASE) {
- int ret;
-
- if (dwc->delayed_status)
- dwc3_ep0_send_delayed_status(dwc);
-
- reinit_completion(&dwc->ep0_in_setup);
-
- spin_unlock_irqrestore(&dwc->lock, flags);
- ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
- msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
- spin_lock_irqsave(&dwc->lock, flags);
- if (ret == 0)
- dev_warn(dwc->dev, "timed out waiting for SETUP phase\n");
- }
+ if (dwc->delayed_status)
+ dwc3_ep0_send_delayed_status(dwc);
/*
* In the Synopsys DesignWare Cores USB3 Databook Rev. 3.30a
@@ -2581,6 +2569,26 @@ static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc)
__dwc3_gadget_stop(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
+ /*
+ * Per databook, when we want to stop the gadget, if a control transfer
+ * is still in process, complete it and get the core into setup phase.
+ * In case the host is unresponsive to a SETUP transaction, forcefully
+ * stall the transfer, and move back to the SETUP phase, so that any
+ * pending endxfers can be executed.
+ */
+ if (dwc->ep0state != EP0_SETUP_PHASE) {
+ reinit_completion(&dwc->ep0_in_setup);
+
+ ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
+ msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
+ if (ret == 0) {
+ dev_warn(dwc->dev, "wait for SETUP phase timed out\n");
+ spin_lock_irqsave(&dwc->lock, flags);
+ dwc3_ep0_reset_state(dwc);
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ }
+ }
+
/*
* Note: if the GEVNTCOUNT indicates events in the event buffer, the
* driver needs to acknowledge them before the controller can halt.
Several sequences utilize the same routine for forcing the control endpoint
back into the SETUP phase. This is required, because those operations need
to ensure that EP0 is back in the default state.
Signed-off-by: Wesley Cheng <[email protected]>
---
drivers/usb/dwc3/gadget.c | 44 ++++++++++++++++++---------------------
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3c63fa97a680..320e30476c88 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -139,6 +139,24 @@ int dwc3_gadget_set_link_state(struct dwc3 *dwc, enum dwc3_link_state state)
return -ETIMEDOUT;
}
+static void dwc3_ep0_reset_state(struct dwc3 *dwc)
+{
+ unsigned int dir;
+
+ if (dwc->ep0state != EP0_SETUP_PHASE) {
+ dir = !!dwc->ep0_expect_in;
+ if (dwc->ep0state == EP0_DATA_PHASE)
+ dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
+ else
+ dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
+
+ dwc->eps[0]->trb_enqueue = 0;
+ dwc->eps[1]->trb_enqueue = 0;
+
+ dwc3_ep0_stall_and_restart(dwc);
+ }
+}
+
/**
* dwc3_ep_inc_trb - increment a trb index.
* @index: Pointer to the TRB index to increment.
@@ -3821,16 +3839,7 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3 *dwc)
dwc->setup_packet_pending = false;
usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED);
- if (dwc->ep0state != EP0_SETUP_PHASE) {
- unsigned int dir;
-
- dir = !!dwc->ep0_expect_in;
- if (dwc->ep0state == EP0_DATA_PHASE)
- dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
- else
- dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
- dwc3_ep0_stall_and_restart(dwc);
- }
+ dwc3_ep0_reset_state(dwc);
}
static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
@@ -3884,20 +3893,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
* phase. So ensure that EP0 is in setup phase by issuing a stall
* and restart if EP0 is not in setup phase.
*/
- if (dwc->ep0state != EP0_SETUP_PHASE) {
- unsigned int dir;
-
- dir = !!dwc->ep0_expect_in;
- if (dwc->ep0state == EP0_DATA_PHASE)
- dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
- else
- dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
-
- dwc->eps[0]->trb_enqueue = 0;
- dwc->eps[1]->trb_enqueue = 0;
-
- dwc3_ep0_stall_and_restart(dwc);
- }
+ dwc3_ep0_reset_state(dwc);
/*
* In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
On Mon, Apr 10, 2023, Wesley Cheng wrote:
> Several sequences utilize the same routine for forcing the control endpoint
> back into the SETUP phase. This is required, because those operations need
> to ensure that EP0 is back in the default state.
>
> Signed-off-by: Wesley Cheng <[email protected]>
> ---
> drivers/usb/dwc3/gadget.c | 44 ++++++++++++++++++---------------------
> 1 file changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 3c63fa97a680..320e30476c88 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -139,6 +139,24 @@ int dwc3_gadget_set_link_state(struct dwc3 *dwc, enum dwc3_link_state state)
> return -ETIMEDOUT;
> }
>
> +static void dwc3_ep0_reset_state(struct dwc3 *dwc)
> +{
> + unsigned int dir;
> +
> + if (dwc->ep0state != EP0_SETUP_PHASE) {
> + dir = !!dwc->ep0_expect_in;
> + if (dwc->ep0state == EP0_DATA_PHASE)
> + dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
> + else
> + dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
> +
> + dwc->eps[0]->trb_enqueue = 0;
> + dwc->eps[1]->trb_enqueue = 0;
> +
> + dwc3_ep0_stall_and_restart(dwc);
> + }
> +}
> +
> /**
> * dwc3_ep_inc_trb - increment a trb index.
> * @index: Pointer to the TRB index to increment.
> @@ -3821,16 +3839,7 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3 *dwc)
> dwc->setup_packet_pending = false;
> usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED);
>
> - if (dwc->ep0state != EP0_SETUP_PHASE) {
> - unsigned int dir;
> -
> - dir = !!dwc->ep0_expect_in;
> - if (dwc->ep0state == EP0_DATA_PHASE)
> - dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
> - else
> - dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
> - dwc3_ep0_stall_and_restart(dwc);
> - }
> + dwc3_ep0_reset_state(dwc);
> }
>
> static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
> @@ -3884,20 +3893,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
> * phase. So ensure that EP0 is in setup phase by issuing a stall
> * and restart if EP0 is not in setup phase.
> */
> - if (dwc->ep0state != EP0_SETUP_PHASE) {
> - unsigned int dir;
> -
> - dir = !!dwc->ep0_expect_in;
> - if (dwc->ep0state == EP0_DATA_PHASE)
> - dwc3_ep0_end_control_data(dwc, dwc->eps[dir]);
> - else
> - dwc3_ep0_end_control_data(dwc, dwc->eps[!dir]);
> -
> - dwc->eps[0]->trb_enqueue = 0;
> - dwc->eps[1]->trb_enqueue = 0;
> -
> - dwc3_ep0_stall_and_restart(dwc);
> - }
> + dwc3_ep0_reset_state(dwc);
>
> /*
> * In the Synopsis DesignWare Cores USB3 Databook Rev. 3.30a
Acked-by: Thinh Nguyen <[email protected]>
Thanks,
Thinh
On Mon, Apr 10, 2023, 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")
> Signed-off-by: Wesley Cheng <[email protected]>
> ---
> drivers/usb/dwc3/gadget.c | 42 +++++++++++++++++++++++----------------
> 1 file changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 320e30476c88..91768f1bdbaf 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2546,29 +2546,17 @@ static int __dwc3_gadget_start(struct dwc3 *dwc);
> static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc)
> {
> unsigned long flags;
> + int ret;
>
> spin_lock_irqsave(&dwc->lock, flags);
> dwc->connected = false;
>
> /*
> - * Per databook, when we want to stop the gadget, if a control transfer
> - * is still in process, complete it and get the core into setup phase.
> + * Attempt to end pending SETUP status phase, and not wait for the
> + * function to do so.
> */
> - if (dwc->ep0state != EP0_SETUP_PHASE) {
> - int ret;
> -
> - if (dwc->delayed_status)
> - dwc3_ep0_send_delayed_status(dwc);
> -
> - reinit_completion(&dwc->ep0_in_setup);
> -
> - spin_unlock_irqrestore(&dwc->lock, flags);
> - ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
> - msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
> - spin_lock_irqsave(&dwc->lock, flags);
> - if (ret == 0)
> - dev_warn(dwc->dev, "timed out waiting for SETUP phase\n");
> - }
> + if (dwc->delayed_status)
> + dwc3_ep0_send_delayed_status(dwc);
>
> /*
> * In the Synopsys DesignWare Cores USB3 Databook Rev. 3.30a
> @@ -2581,6 +2569,26 @@ static int dwc3_gadget_soft_disconnect(struct dwc3 *dwc)
> __dwc3_gadget_stop(dwc);
> spin_unlock_irqrestore(&dwc->lock, flags);
>
> + /*
> + * Per databook, when we want to stop the gadget, if a control transfer
> + * is still in process, complete it and get the core into setup phase.
> + * In case the host is unresponsive to a SETUP transaction, forcefully
> + * stall the transfer, and move back to the SETUP phase, so that any
> + * pending endxfers can be executed.
> + */
> + if (dwc->ep0state != EP0_SETUP_PHASE) {
> + reinit_completion(&dwc->ep0_in_setup);
> +
> + ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
> + msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
> + if (ret == 0) {
> + dev_warn(dwc->dev, "wait for SETUP phase timed out\n");
> + spin_lock_irqsave(&dwc->lock, flags);
> + dwc3_ep0_reset_state(dwc);
> + spin_unlock_irqrestore(&dwc->lock, flags);
> + }
> + }
> +
> /*
> * Note: if the GEVNTCOUNT indicates events in the event buffer, the
> * driver needs to acknowledge them before the controller can halt.
Acked-by: Thinh Nguyen <[email protected]>
Thanks,
Thinh
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