The attached driver is *not yet functional* because of this problem.
As indicated in my post at: http://sourceforge.net/mailarchive/forum.php?thread_name=4651EDD0.4060504%40ceibo.fiec.espol.edu.ec&forum_name=irda-usersthis dongle is a very weird one. Long story short, it uses control packets (not interrupt or bulk) for data transfers, and also performs obfuscation (in the form of XOR with variable single-byte keys) on the traffic, which consists of wrapped SIR frames. There are full details on the protocol (as gleaned from SnoopyPro logs) at the start of the source file ks-959.c in the tarball.
The problem is that I am getting a delayed -EPIPE (-32) on the submission callback of the control urb on reception. This -EPIPE is visible in the output of usbmon inside the tarball.
This urb is prepared as follows: /* Start first reception */kingsun->rx_setuprequest->bRequestType = USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE;
kingsun->rx_setuprequest->bRequest = KINGSUN_REQ_RECV;
kingsun->rx_setuprequest->wValue = cpu_to_le16(0x0200);
kingsun->rx_setuprequest->wIndex = cpu_to_le16(0x0000);
kingsun->rx_setuprequest->wLength = cpu_to_le16(0);
usb_fill_control_urb(kingsun->rx_urb, kingsun->usbdev,
usb_rcvctrlpipe(kingsun->usbdev, 0),
(unsigned char *)kingsun->rx_setuprequest,
kingsun->rx_buf, KINGSUN_FIFO_SIZE,
ks959_rcv_irq, kingsun);
kingsun->rx_urb->status = 0;
err = usb_submit_urb(kingsun->rx_urb, GFP_KERNEL);
if (err) {
err("ks-959: first urb-submit failed: %d", err);
goto close_irlap;
}
This tries to mimic as closely as possible what I am seeing in the
SnoopyPro logs. According to the logs, the driver sends a control urb
with 0x00 as bRequestType (USB_DIR_OUT | USB_TYPE_STANDARD |
USB_RECIP_DEVICE), 0x01 as bRequest, 0x0200 for wValue, 0x0000 for
wIndex, 0x0000 for wLength, and expects the device to answer with a data
payload that contains the received data. The actual sequence for the
setup packet in the logs is [00 01 00 02 00 00 00 00].
The constant KINGSUN_REQ_RECV is defined as 0x01 earlier in the code. I can see from the USB headers (linux/usb/ch9.h), that this value is the same as USB_REQ_CLEAR_FEATURE. So my first guess is that the setup packet is invalid. In particular, I am suspicious of the use of USB_DIR_OUT with a request that is supposed to return data. Also, USB_REQ_CLEAR_FEATURE is supposed to have an answer without any data payload. So I have a couple of questions:
Is this control URB valid?Will the kernel actually send such a control URB over the wire, when requested by the driver? Can the kernel handle a data payload for this particular kind of request (USB_REQ_CLEAR_FEATURE)? If this control URB is not valid, who is responsible for answering -EPIPE? The device (as a response), or the USB stack (because it rejects the urb without sending it over the wire)? Is it possible that the SnoopyPro log is not showing correct data? How can I be sure?
Any comments on this are welcome.
Alex Villacís Lasso
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
ks-959.tar.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
