Thanks very much for such a quick feedback. The information is very helpful. Under 2.4, does that mean I have to set USE_QUEUE_BULK in transfer_flags if I want to invoke usb_submit_urb() multiple times without waiting for the completion handler to be called?
Thanks, Gary --- Alan Stern <[EMAIL PROTECTED]> wrote: > On Tue, 8 Jul 2003, Gary Ng wrote: > > > Hi guys, > > I am newbie trying to come up with my first USB driver, I've read > > through the usb-skeleton.c file and find it to be a very helpful > > starting point for a beginner like myself. There are several things > > > though I am interested to learn a bit more. 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? Also, what's the > advantage > > of using usb_submit_urb() over something like usb_bulk_msg()? In > the > > usb-skeleton.c, it's mentioned about a urb->status race condition, > > how can I avoid such race condition? Would setting urb > transfer_flags > > such as USB_QUEUE_BULK be able to avoid it? > > > > All comments and suggestions are welcome! Thanks in advance. > > Gary > > All right. To start with, you might want to try writing for Linux > 2.5 > rather than 2.4, because the USB support is much better in the > development > kernel. > > It's not mandatory to make the transfer_buffer size the same as > the device's max packet size. The transfer_buffer can be larger or > smaller, and it won't matter. The only thing that _is_ mandatory is > to > make the transfer_buffer's size at least as large as the value you > place > in transfer_buffer_length. > > If the transfer_buffer size is different from the max packet size, > the transfer will proceed normally and will work okay. > > The advantages to usb_submit_urb() over usb_bulk/control_msg() > are: usb_submit_urb() can handle iso. and interrupt transfer; it lets > you > set special transfer_flags bits; and it gives you a way to cancel an > URB > without waiting for it to complete or a timeout to expire. The > disadvantages are: usb_submit_urb() requires you to perform more of > the > setup yourself; and it doesn't give you a way to specify a timeout. > > I believe the race condition you refer to in usb-skeleton.c meant > that after calling usb_submit_urb(), a device driver should not look > at or > change urb->status until the completion routine runs. It's a race > because > the USB core routines change the value of urb->status at various > unpredictable times, based on the actual USB I/O events, and you > don't > want to interfere with that. To avoid the race, simply don't touch > your > URB after it has been submitted and before the completion routine is > called. > > The transfer flags have nothing to do with the race condition > mentioned above. Furthermore, USB_QUEUE_BULK isn't even supported > under > 2.5 because it's unnecessary -- bulk URBs are always queued. That's > one > of the ways in which 2.5 is superior to 2.4. > > Alan Stern > ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ------------------------------------------------------- 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
