Re: Kingsun KS-959 USB IrDA dongle protocol - help needed with control urb for reception

On Mon, 16 Jul 2007, Alex Villací­s Lasso wrote:

> 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?

No.  Of course, there's nothing to stop the device from accepting an 
invalid URB.

> Will the kernel actually send such a control URB over the wire, when 
> requested by the driver?

Yes.  This is not one of the things it checks for.

> Can the kernel handle a data payload for this particular kind of request 
> (USB_REQ_CLEAR_FEATURE)?

The kernel doesn't know or care anything about the type of the request.  
It just tries to do what the driver asks.

> 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)?

The device.

> Is it possible that the SnoopyPro log is not showing correct data? How 
> can I be sure?

It seems pretty unlikely that SnoopyPro is making a mistake.  But maybe 
you have misinterpreted the data.

If you want to be sure, you have to use a USB bus analyzer.

> Any comments on this are welcome.

Can you post the portion of the SnoopyPro log containing both the UP
and DOWN reports for this questionable URB?

Alan Stern


-------------------------------------------------------------------------
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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel