Hello I've been following this list for a couple months, this is the first time I
think I can contribute, hopefully I am right :D
I've been working in a test for f_loopback.c configuration. And I've noticed
that when a bulk transfer is attempted from the device to the host using
usbtest driver, the test simply hangs waiting for the transfer.
I used the following comand:
#sudo ./testusb -a -t2 -c1 -s4096
This is appreciated in the following usbmon trace:
f28bc800 0.778172 S Co:1:015:0 s 01 0b 0000 0000 0000 0
f28bc800 0.779222 C Co:1:015:0 0 0
f28bc800 0.779246 S Bi:1:015:1 - 4096 <
I believe this is because there is no IN request allocated. Applying the
following patch this is fixed.
--------------------------------------------------------------------------------------------------------------------------------------------
Allocating for the request buffer is missing for the IN
endpoint. Because of this testusb gets stuck in test 2;
read X bytes Y times.
Signed-off-by: Aldo Brett Cedillo Martinez <aldo.cedillo@xxxxxx>
---
drivers/usb/gadget/f_loopback.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c
index 6cb29d3..0000782 100644
--- a/drivers/usb/gadget/f_loopback.c
+++ b/drivers/usb/gadget/f_loopback.c
@@ -266,6 +266,21 @@ enable_loopback(struct usb_composite_dev *cdev, struct f_loopback *loop)
return result;
ep->driver_data = loop;
+ /* Allocate buffer for the IN endpoint */
+ req = alloc_ep_req (ep);
+ if (req) {
+ req->complete = loopback_complete;
+ printk (KERN_INFO "req->length = %d\n", req->length);
+ result = usb_ep_queue (ep, req, GFP_ATOMIC);
+ if (result)
+ ERROR (cdev, "%s queue req --> %d\n", ep->name, result);
+ } else {
+ usb_ep_disable (ep);
+ ep->driver_data = NULL;
+ result = -ENOMEM;
+ goto fail0;
+ }
+
/* one endpoint just reads OUT packets */
ep = loop->out_ep;
result = usb_ep_enable(ep, sink);
--
1.6.3.3
--------------------------------------------------------------------------------------------------------------------------------------------
After applying the patch I got the following usbmon trace:
f28cd880 0.074198 S Co:1:016:0 s 01 0b 0000 0000 0000 0
f28cd880 0.078352 C Co:1:016:0 0 0
f28cd880 0.078379 S Bi:1:016:1 - 4096 <
f28cd880 0.078599 C Bi:1:016:1 0 4096 = 00657865 635f6d61 78007265 73756c74 0074696d 6572005f 5f706172 616d5f61
Hopefully I'm right, and of course I will appreciate any comments you have. Thanks in advance.
Aldo Cedillo.--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
