linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wesley Cheng <quic_wcheng@quicinc.com>
To: Daehwan Jung <dh10.jung@samsung.com>,
	Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	<quic_jackp@quicinc.com>, <Thinh.Nguyen@synopsys.com>
Subject: Re: [PATCH v1 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER_PENDING in ep cmd fails
Date: Mon, 14 Feb 2022 10:53:14 -0800	[thread overview]
Message-ID: <e4b18b77-ab33-bd70-c239-b009210c3864@quicinc.com> (raw)
In-Reply-To: <1644831438-125403-2-git-send-email-dh10.jung@samsung.com>

Hi Daehwan,

On 2/14/2022 1:37 AM, Daehwan Jung wrote:
> It always sets DWC3_EP_END_TRANSFER_PENDING in dwc3_stop_active_transfer
> even if dwc3_send_gadget_ep_cmd fails. It can cause some problems like
> skipping clear stall commmand or giveback from dequeue. We fix to set it
> only when ep cmd success. Additionally, We clear DWC3_EP_TRANSFER_STARTED
> for next trb to start transfer not update transfer.
> 
> Change-Id: I2e6b58acc99f385e467e8b639a3792a5e5f4d2bb
> Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
> ---
>  drivers/usb/dwc3/gadget.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 183b90923f51..3ad3bc5813ca 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2044,6 +2044,12 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
>  				dwc3_gadget_move_cancelled_request(r,
>  						DWC3_REQUEST_STATUS_DEQUEUED);
>  
> +			/* If ep cmd fails, then force to giveback cancelled requests here */
> +			if (!(dep->flags & DWC3_EP_END_TRANSFER_PENDING)) {
> +				dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
> +				dwc3_gadget_ep_cleanup_cancelled_requests(dep);
> +			}
> +
What I realized when looking at the endxfer command fail due to TIMEOUT,
was that it would lead to subsequent controller halt failures as well
(during pullup disable case).  It might not be safe to forcefully unmap
the request buffers if the controller may still be "working" on it.

I found some interesting quirks with regards to endxfer timeouts as
well, which I'm trying to get some more feedback on [1].  What is the
end issue being seen that requires this change? (we may have run into
the same issue as well.

[1] -
https://lore.kernel.org/linux-usb/20220203080017.27339-1-quic_wcheng@quicinc.com/

Thanks
Wesley Cheng
>  			dep->flags &= ~DWC3_EP_WAIT_TRANSFER_COMPLETE;
>  
>  			goto out;
> @@ -3645,7 +3651,7 @@ static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
>  
>  	if (!interrupt)
>  		dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
> -	else
> +	else if (!ret)
>  		dep->flags |= DWC3_EP_END_TRANSFER_PENDING;
>  }
>  

  reply	other threads:[~2022-02-14 18:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220214094040epcas2p3cc844d30f54793f51f16bb2b59b432e1@epcas2p3.samsung.com>
2022-02-14  9:37 ` [PATCH v1 0/2] Fix ep command fail issue in dequeue Daehwan Jung
     [not found]   ` <CGME20220214094041epcas2p2ec37c252dd5f9508454e9449c95e6c7a@epcas2p2.samsung.com>
2022-02-14  9:37     ` [PATCH v1 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER_PENDING in ep cmd fails Daehwan Jung
2022-02-14 18:53       ` Wesley Cheng [this message]
2022-02-15  6:08         ` Jung Daehwan
     [not found]   ` <CGME20220214094042epcas2p118ac06692ad14f321a3fd59e57bcf1d5@epcas2p1.samsung.com>
2022-02-14  9:37     ` [PATCH v1 2/2] usb: dwc3: Prevent cleanup cancelled requests at the same time Daehwan Jung
2022-02-14 10:42       ` Greg Kroah-Hartman
2022-02-14 10:46         ` Jung Daehwan

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=e4b18b77-ab33-bd70-c239-b009210c3864@quicinc.com \
    --to=quic_wcheng@quicinc.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=dh10.jung@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_jackp@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;
as well as URLs for NNTP newsgroup(s).