linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	John Youn <John.Youn@synopsys.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Fix dwc3_calc_trbs_left()
Date: Fri, 20 Aug 2021 13:04:15 +0300	[thread overview]
Message-ID: <87bl5sfn4k.fsf@kernel.org> (raw)
In-Reply-To: <bba2b747-dc16-5ad8-b80b-c8fb6b11a3d3@synopsys.com>


Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:

> Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
>>> We can't depend on the TRB's HWO bit to determine if the TRB ring is
>>> "full". A TRB is only available when the driver had processed it, not
>>> when the controller consumed and relinquished the TRB's ownership to the
>>> driver. Otherwise, the driver may overwrite unprocessed TRBs. This can
>>> happen when many transfer events accumulate and the system is slow to
>>> process them and/or when there are too many small requests.
>>>
>>> If a request is in the started_list, that means there is one or more
>>> unprocessed TRBs remained. Check this instead of the TRB's HWO bit
>>> whether the TRB ring is full.
>>>
>>> Cc: <stable@vger.kernel.org>
>>> Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too")
>>> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
>>> ---
>>>  drivers/usb/dwc3/gadget.c | 16 ++++++++--------
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 84fe57ef5a49..1e6ddbc986ba 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -940,19 +940,19 @@ static struct dwc3_trb *dwc3_ep_prev_trb(struct dwc3_ep *dep, u8 index)
>>>  
>>>  static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
>>>  {
>>> -	struct dwc3_trb		*tmp;
>>>  	u8			trbs_left;
>>>  
>>>  	/*
>>> -	 * If enqueue & dequeue are equal than it is either full or empty.
>>> -	 *
>>> -	 * One way to know for sure is if the TRB right before us has HWO bit
>>> -	 * set or not. If it has, then we're definitely full and can't fit any
>>> -	 * more transfers in our ring.
>>> +	 * If the enqueue & dequeue are equal then the TRB ring is either full
>>> +	 * or empty. It's considered full when there are DWC3_TRB_NUM-1 of TRBs
>>> +	 * pending to be processed by the driver.
>>>  	 */
>>>  	if (dep->trb_enqueue == dep->trb_dequeue) {
>>> -		tmp = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
>>> -		if (tmp->ctrl & DWC3_TRB_CTRL_HWO)
>>> +		/*
>>> +		 * If there is any request remained in the started_list at
>>> +		 * this point, that means there is no TRB available.
>>> +		 */
>>> +		if (!list_empty(&dep->started_list))
>>>  			return 0;
>> 
>> we could also do away with calc_trbs_left() completely if we just add an
>> actual counter that gets incremented decremented together with the
>> enqueue/dequeue pointers. Since we have 256 TRBs per endpoint and only
>> 255 are usable, this means we can do away with a single u8 per
>> endpoint. Perhaps that could be done as a second step after this fix is
>> merged?
>> 
>
> Yes, that would simplify the logic. We can do that after merging this fix.

sounds good:

Acked-by: Felipe Balbi <balbi@kernel.org>

-- 
balbi

      reply	other threads:[~2021-08-20 10:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  1:17 [PATCH] usb: dwc3: gadget: Fix dwc3_calc_trbs_left() Thinh Nguyen
2021-08-19  5:32 ` Felipe Balbi
2021-08-20  0:59   ` Thinh Nguyen
2021-08-20 10:04     ` Felipe Balbi [this message]

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=87bl5sfn4k.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@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).