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