mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Sergej Pupykin <ps@lx-ltd.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Bugs in usb-skeleton.c??? :)
Date: Thu, 13 Jul 2006 15:00:50 +0200	[thread overview]
Message-ID: <1152795650.3024.44.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <m37j2helb4.fsf@lx-ltd.ru>

On Thu, 2006-07-13 at 16:33 +0400, Sergej Pupykin wrote:
>  >> As I understand, USB subsystem uses urb->transfer_buffer directly with
>  >> DMA. I see that usb-skeleton.c and (at least) bluez's hci_usb allocates it
>  >> without GFP_DMA flag. (skeleton with GFP_KERNEL, bluez with GFP_ATOMIC)
> 
>  AvdV> I think GFP_DMA means something different than that you think it means.
>  AvdV> GFP_DMA is a bad old hack that means "this is for ISA bus cards to DMA
>  AvdV> to/from". Since there are no ISA bus USB controllers... the USB code
>  AvdV> doesn't need to use GFP_DMA.
> 
> Does kmalloc always allocate pages that can be used in DMA?

normally yes. HOWEVER....
> 
> I see pci_map_single gives address that incremented later without page
> boundary checking. Are allocated pages sequented? (usb-ohci.c)

..it is nicer to use the DMA allocation API (which internally may fall
back to kmalloc etc), while kmalloc may work, it can be quite slow in
how it's made to work. So it's just nicer to just use the DMA memory
allocators... (see Documentation/DMA-API.txt file for a description of
this)

Greetings,
   Arjan van de Ven


  reply	other threads:[~2006-07-13 13:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-13 11:26 Sergej Pupykin
2006-07-13 11:58 ` Arjan van de Ven
2006-07-13 12:33   ` Sergej Pupykin
2006-07-13 13:00     ` Arjan van de Ven [this message]
2006-07-13 13:10       ` Sergej Pupykin
2006-07-13 14:24         ` Manuel Lauss

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=1152795650.3024.44.camel@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ps@lx-ltd.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®