diff mbox series

[v3] usb: cdnsp: Fix wrong transmission direction of EP0

Message ID 20221101061730.8991-1-jleng@ambarella.com
State New
Headers
Series [v3] usb: cdnsp: Fix wrong transmission direction of EP0 |

Commit Message

Jing Leng Nov. 1, 2022, 6:17 a.m. UTC 
  EP0 transfer is bi-directional, but in the cdnsp gadget, the
transmission direction of EP0 is not changed after it is
initialized to IN, so the OUT data from EP0 received by the host
is invalid.

The value of ep0_expect_in will change according to the value of
bRequestType in the SETUP transaction of control transfer, so we
can use it as the transmission direction of EP0.

Signed-off-by: Jing Leng <jleng@ambarella.com>
---
ChangeLog v2->v3:
- Repair my email address.
ChangeLog v1->v2:
- Rebase the patch.
- Make email addresses ('From' and 'Signed-off-by') consistent.
---
 drivers/usb/cdns3/cdnsp-gadget.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Comments

Greg KH Nov. 1, 2022, 9:43 a.m. UTC | #1 
On Tue, Nov 01, 2022 at 02:17:30PM +0800, Jing Leng wrote:
> EP0 transfer is bi-directional, but in the cdnsp gadget, the
> transmission direction of EP0 is not changed after it is
> initialized to IN, so the OUT data from EP0 received by the host
> is invalid.
> 
> The value of ep0_expect_in will change according to the value of
> bRequestType in the SETUP transaction of control transfer, so we
> can use it as the transmission direction of EP0.
> 
> Signed-off-by: Jing Leng <jleng@ambarella.com>
> ---
> ChangeLog v2->v3:
> - Repair my email address.

Yes, it works, and it's validated!

Nice job, thanks.  I'll let the cdns3 maintainer review it first, but
just wanted to say thanks for fixing this up, it makes my life a lot
easier when accepting patches.

greg k-h
Pawel Laszczak Nov. 2, 2022, 7:35 a.m. UTC | #2 
>
>On Tue, Nov 01, 2022 at 02:17:30PM +0800, Jing Leng wrote:
>> EP0 transfer is bi-directional, but in the cdnsp gadget, the
>> transmission direction of EP0 is not changed after it is initialized
>> to IN, so the OUT data from EP0 received by the host is invalid.
>>
>> The value of ep0_expect_in will change according to the value of
>> bRequestType in the SETUP transaction of control transfer, so we can
>> use it as the transmission direction of EP0.
>>
>> Signed-off-by: Jing Leng <jleng@ambarella.com>

Acked-by: Pawel Laszczak <pawell@cadence.com>

Thanks,
Pawel Laaszczak

>> ---
>> ChangeLog v2->v3:
>> - Repair my email address.
>
>Yes, it works, and it's validated!
>
>Nice job, thanks.  I'll let the cdns3 maintainer review it first, but just wanted to
>say thanks for fixing this up, it makes my life a lot easier when accepting
>patches.
>
>greg k-h
Greg KH Nov. 3, 2022, 2:45 p.m. UTC | #3 
On Tue, Nov 01, 2022 at 10:43:21AM +0100, Greg KH wrote:
> On Tue, Nov 01, 2022 at 02:17:30PM +0800, Jing Leng wrote:
> > EP0 transfer is bi-directional, but in the cdnsp gadget, the
> > transmission direction of EP0 is not changed after it is
> > initialized to IN, so the OUT data from EP0 received by the host
> > is invalid.
> > 
> > The value of ep0_expect_in will change according to the value of
> > bRequestType in the SETUP transaction of control transfer, so we
> > can use it as the transmission direction of EP0.
> > 
> > Signed-off-by: Jing Leng <jleng@ambarella.com>
> > ---
> > ChangeLog v2->v3:
> > - Repair my email address.
> 
> Yes, it works, and it's validated!
> 
> Nice job, thanks.  I'll let the cdns3 maintainer review it first, but
> just wanted to say thanks for fixing this up, it makes my life a lot
> easier when accepting patches.

Oops, I missed that email footer, sorry.  That is NOT compatible with
Linux kernel development, and as per the recommendation from my legal
people, I have to go revert that change as we can't take it as-is
because it might have been sent out incorrectly as it was stated to be
"Proprietary and/or Confidential Information" which is not allowed in
the Linux kernel.

thanks,

greg k-h
diff mbox series

Patch

diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c
index c67715f6f756..526f80651d35 100644
--- a/drivers/usb/cdns3/cdnsp-gadget.c
+++ b/drivers/usb/cdns3/cdnsp-gadget.c
@@ -345,6 +345,7 @@  int cdnsp_ep_enqueue(struct cdnsp_ep *pep, struct cdnsp_request *preq)
 {
 	struct cdnsp_device *pdev = pep->pdev;
 	struct usb_request *request;
+	u8 direction;
 	int ret;
 
 	if (preq->epnum == 0 && !list_empty(&pep->pending_list)) {
@@ -355,11 +356,14 @@  int cdnsp_ep_enqueue(struct cdnsp_ep *pep, struct cdnsp_request *preq)
 	request = &preq->request;
 	request->actual = 0;
 	request->status = -EINPROGRESS;
-	preq->direction = pep->direction;
+
+	direction = usb_endpoint_xfer_control(pep->endpoint.desc) ?
+		    pdev->ep0_expect_in : pep->direction;
+	preq->direction = direction;
 	preq->epnum = pep->number;
 	preq->td.drbl = 0;
 
-	ret = usb_gadget_map_request_by_dev(pdev->dev, request, pep->direction);
+	ret = usb_gadget_map_request_by_dev(pdev->dev, request, direction);
 	if (ret) {
 		trace_cdnsp_request_enqueue_error(preq);
 		return ret;
@@ -387,8 +391,7 @@  int cdnsp_ep_enqueue(struct cdnsp_ep *pep, struct cdnsp_request *preq)
 	return 0;
 
 unmap:
-	usb_gadget_unmap_request_by_dev(pdev->dev, &preq->request,
-					pep->direction);
+	usb_gadget_unmap_request_by_dev(pdev->dev, &preq->request, direction);
 	list_del(&preq->list);
 	trace_cdnsp_request_enqueue_error(preq);