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