For example, is it a mandatory thing to set the urb transfer_buffer size same as the device endpoint max packet size? What could happen if the urb transfer_buffer
size is different from the max packet size?
Don't make the i/o buffers small unless they need to be; it's a lot faster to transfer 4 KBytes in one shot (a few milliseconds at full speed) than several dozen small transfers (likely one msec each).
Also, what's the advantage of using usb_submit_urb() over something like usb_bulk_msg()?
The asynchronous call lets you queue requests, giving you I/O overlap, and lets your waits be interruptible.
usb-skeleton.c, it's mentioned about a urb->status race condition,
how can I avoid such race condition?
Don't access urb->status until the URB completion is called. It's undefined until then ... the USB controller driver owns that field, its value could even change multiple times before the completion function is called.
Would setting urb transfer_flags such as USB_QUEUE_BULK be able to avoid it?
No. The race is there because the status is part of the URB, rather than a parameter to the completion callback. Artifact of an old API design, which exposes internal state.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
