2018-12-20 20:19:09

by Zengtao (B)

[permalink] [raw]
Subject: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired

We have already returned EAGAIN for bus-expiry, and it's designed to
start with a future Frame number and start the transfer again. So we
should not remove the request for that case.

Signed-off-by: Zeng Tao <[email protected]>
---
drivers/usb/dwc3/gadget.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2ecde30..16a6e3c 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1250,7 +1250,7 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep)
}

ret = dwc3_send_gadget_ep_cmd(dep, cmd, &params);
- if (ret < 0) {
+ if (ret < 0 && ret != -EAGAIN) {
/*
* FIXME we need to iterate over the list of requests
* here and stop, unmap, free and del each of the linked
@@ -1259,10 +1259,9 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep)
if (req->trb)
memset(req->trb, 0, sizeof(struct dwc3_trb));
dwc3_gadget_del_and_unmap_request(dep, req, ret);
- return ret;
}

- return 0;
+ return ret;
}

static int __dwc3_gadget_get_frame(struct dwc3 *dwc)
--
2.7.4



2019-01-14 08:15:10

by Felipe Balbi

[permalink] [raw]
Subject: Re: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired


Hi,

Zeng Tao <[email protected]> writes:
> We have already returned EAGAIN for bus-expiry, and it's designed to
> start with a future Frame number and start the transfer again. So we
> should not remove the request for that case.
>
> Signed-off-by: Zeng Tao <[email protected]>

Do we need a Fixes tag here? How about Cc stable? Can you share
tracepoints exposing the problem?


thanks

--
balbi


Attachments:
signature.asc (847.00 B)

2019-01-21 09:07:26

by Felipe Balbi

[permalink] [raw]
Subject: RE: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired


Hi,

"Zengtao (B)" <[email protected]> writes:
>>-----Original Message-----
>>From: Felipe Balbi [mailto:[email protected]]
>>Sent: Monday, January 14, 2019 4:13 PM
>>To: Zengtao (B) <[email protected]>
>>Cc: Zengtao (B) <[email protected]>; Greg Kroah-Hartman
>><[email protected]>; [email protected];
>>[email protected]
>>Subject: Re: [PATCH] usb: dwc3: gadget: don't remove the request if
>>bus-expired
>>
>>* PGP Signed by an unknown key
>>
>>
>>Hi,
>>
>>Zeng Tao <[email protected]> writes:
>>> We have already returned EAGAIN for bus-expiry, and it's designed to
>>> start with a future Frame number and start the transfer again. So we
>>> should not remove the request for that case.
>>>
>>> Signed-off-by: Zeng Tao <[email protected]>
>>
>>Do we need a Fixes tag here? How about Cc stable? Can you share
>>tracepoints exposing the problem?
>>
>
> I am not sure that we need to Fixes tag, it's not related to any single patch, but
> there is definitely something wrong, after rethinking it again, I found that there
> are still some problems for this patch, for the reties inside the driver, we should not
> remove the request, but if we return -EAGAIN to the gadget layer, we should because
> the gadget will requeue the request again if we return -EAGAIN.
>
> Any suggestions.

Well, that needs to be patched, sure. I'm just saying that we need to
blame a patch that was incomplete so we know which stable releases need
this. Perhaps the patch at fault here was my patch adding the retry
method for isoc transfers.

--
balbi


Attachments:
signature.asc (847.00 B)

2019-01-21 09:35:51

by Zengtao (B)

[permalink] [raw]
Subject: RE: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired

Hi balbi:

>-----Original Message-----
>From: Felipe Balbi [mailto:[email protected]]
>Sent: Monday, January 14, 2019 4:13 PM
>To: Zengtao (B) <[email protected]>
>Cc: Zengtao (B) <[email protected]>; Greg Kroah-Hartman
><[email protected]>; [email protected];
>[email protected]
>Subject: Re: [PATCH] usb: dwc3: gadget: don't remove the request if
>bus-expired
>
>* PGP Signed by an unknown key
>
>
>Hi,
>
>Zeng Tao <[email protected]> writes:
>> We have already returned EAGAIN for bus-expiry, and it's designed to
>> start with a future Frame number and start the transfer again. So we
>> should not remove the request for that case.
>>
>> Signed-off-by: Zeng Tao <[email protected]>
>
>Do we need a Fixes tag here? How about Cc stable? Can you share
>tracepoints exposing the problem?
>

I am not sure that we need to Fixes tag, it's not related to any single patch, but
there is definitely something wrong, after rethinking it again, I found that there
are still some problems for this patch, for the reties inside the driver, we should not
remove the request, but if we return -EAGAIN to the gadget layer, we should because
the gadget will requeue the request again if we return -EAGAIN.

Any suggestions.

>
>thanks
>
>--
>balbi
>
>* Unknown Key
>* 0xE11A9906