Re: Buffer allocation for USB transfers

From: Robert Hancock
Date: Wed Jan 14 2009 - 19:22:00 EST


Christian Eggers wrote:
In different drivers I've found several methods for allocating buffers transfered with usb_control_msg() or usb_submit_urb():

- usb_stor_msg_common() in "drivers/usb/storage/transport.c" uses buffers allocated with usb_buffer_alloc(). These buffers are used with URB_NO_xxx_DMA_MAP in urb->transfer_flags.

- asix_read_cmd() in "drivers/net/usb/asix.c" uses kmalloc(GFP_KERNEL).

- mcs7830_get_reg() in "drivers/net/usb/mcs7830.c" uses buffers from the stack.

At least the latter does not work on my SH-4 platform. It seems that other variables on the stack are overwritten after calling usb_control_msg(), probably as result of incorrect alignment.

Indeed, DMA to/from the stack is not allowed (on some platforms it may invalidate other data in the same cache line, etc. which is likely what you are seeing). Assuming that the USB core is DMAing directly to/from that memory, it's a bug in that mcs7830 driver.


For some reason the second example (kmalloc()) doesn't seem to cause problems (on my platform) but is there are guarantee that kmalloc() without GFP_DMA does always return a DMA capable buffer?

Yes, as long as the DMA mapping API is used properly to map the buffer (which I'm assuming it is, not being a USB core expert.) GFP_DMA is not intended for this, drivers should not be using that flag, unless maybe they are doing ISA transfers which is not the case with USB.


Shall all buffers used for usb_control_msg() and usb_submit_urb() be allocated with usb_buffer_alloc()? It seems that usb_control_msg() doesn't offer a way to set the URB_NO_xxx_DMA_MAP in urb->transfer_flags so that usb_buffer_alloc() can not be used here???

regards
Christian Eggers

Please CC to ceggers@xxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/