All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Christian Eggers <ceggers@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Buffer allocation for USB transfers
Date: Wed, 14 Jan 2009 18:21:39 -0600	[thread overview]
Message-ID: <496E8193.9070603@shaw.ca> (raw)
In-Reply-To: <496E43F4.24792.158F9B@ceggers.gmx.de>

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@gmx.de
> 


  reply	other threads:[~2009-01-15  0:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-14 18:58 Buffer allocation for USB transfers Christian Eggers
2009-01-15  0:21 ` Robert Hancock [this message]
2009-01-15 13:31 ` Oliver Neukum
2009-01-15 15:43 ` Oliver Neukum
2009-01-15 18:50   ` Christian Eggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=496E8193.9070603@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=ceggers@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.