| Message ID | da702dc9b6f2413da5f8e8967ef1e591293102b1.1599098161.git.thinhn@synopsys.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | usb: dwc3: gadget: Fix TRB preparation | expand |
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 5bb4327ae237..b531f63d19de 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -979,7 +979,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc, false); ret = dwc3_ep0_start_trans(dep); } else if (IS_ALIGNED(req->request.length, dep->endpoint.maxpacket) && - req->request.length && req->request.zero) { + req->request.length && req->request.zero && req->direction) { ret = usb_gadget_map_request_by_dev(dwc->sysdev, &req->request, dep->number);
The current implementation for ZLP handling of usb_request->zero for ep0 is only for control IN requests. For OUT direction, DWC3 needs to check and set up for MPS boundary alignment, and it doesn't do that at the moment. Usually, control OUT requests can indicate its transfer size via the wLength field of the control message. So usb_request->zero is usually not needed for OUT direction. To handle ZLP OUT for control endpoint, we'd need to allocate at least 3 TRBs for control requests (we have 2 at the moment). For now, let's just make sure the current ZLP setup is only for IN direction. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> --- Changes in v3: - None Changes in v2: - None drivers/usb/dwc3/ep0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)