This patch implements separate flag bits to indicate which of transfer_dma
and setup_dma are already valid. It provides greater flexibility to device drivers by allowing for control transfers in which only one of the two buffers has been mapped.
Looks good, minor comments below.
Alterations to the core were minimal. However, as a side effect of this patch usb_buffer_map/sync/unmap() can now legally be used for control transfers. I also fixed a bug in usb_hcd_giveback_urb(), whereby the code would attempt to unmap the buffers even for non-DMA host controllers.
You don't need to keep the URB_NO_DMA_MAP bitmask around; it'll be clearer to delete it. And I must have missed the code in usb_buffer_{map,dmasync,unmap}() for setup buffers; unless you meant to not include that? (OK, just quirky.)
- Dave
+ * @transfer_dma: When transfer_flags includes URB_NO_TRANSFER_DMA_MAP, + * the device driver is saying that it provided this DMA address, + * which the host controller driver should use instead of the + * transfer_buffer.
Make that "in preference to ..." since PIO style controllers can't use DMA addresses. USB device drivers aren't supposed to need to know if there's a PIO HCD underneath them.
+ * @setup_dma: For control transfers with URB_NO_SETUP_DMA_MAP set, the + * device driver has provided this DMA address for the setup packet. + * The host controller driver should use this instead of setup_packet.
Make that "in preference to setup_packet"; same reason.
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
