All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.