All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: linux-scsi@vger.kernel.org
Cc: Christoph Lameter <clameter@sgi.com>
Subject: GFP_DMA use in SCSI midlayer
Date: Sun, 1 Oct 2006 22:13:24 +0200	[thread overview]
Message-ID: <200610012213.24123.ak@suse.de> (raw)


>From a quick grep the SCSI midlayer still uses a lot of GFP_DMA
for various things:

% gid GFP_DMA | grep scsi
drivers/scsi/aha1542.c:704:             SCpnt->host_scribble = (unsigned char *) kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/ch.c:266:  buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/ch.c:323:  buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/ch.c:773:          buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/eata.c:1358:               gfp_t gfp_mask = (shost->unchecked_isa_dma ? GFP_DMA : 0) | GFP_ATOMIC;
drivers/scsi/initio.c:2830:             if ((tul_scb = (SCB *) kmalloc(i, GFP_ATOMIC | GFP_DMA)) != NULL)
drivers/scsi/osst.c:5250:               priority |= GFP_DMA;
drivers/scsi/pluto.c:120:       fcs = (struct ctrl_inquiry *) kmalloc (sizeof (struct ctrl_inquiry) * fcscount, GFP_DMA);
drivers/scsi/sg.c:1660:  * XXX(hch): we shouldn't need GFP_DMA for the actual S/G list.
drivers/scsi/sg.c:1663:          gfp_flags |= GFP_DMA;
drivers/scsi/sg.c:2453:         page_mask = GFP_ATOMIC | GFP_DMA | __GFP_COMP | __GFP_NOWARN;
drivers/scsi/sr.c:628:  buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/sr.c:728:  buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/sr_ioctl.c:34:/* primitive to determine whether we need to have GFP_DMA set based on
drivers/scsi/sr_ioctl.c:36:#define SR_GFP_DMA(cd) (((cd)->device->host->unchecked_isa_dma) ? GFP_DMA : 0)
drivers/scsi/sr_vendor.c:120:   buffer = (unsigned char *) kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/sr_vendor.c:167:   buffer = (unsigned char *) kmalloc(512, GFP_KERNEL | GFP_DMA);
drivers/scsi/st.c:3627:         priority |= GFP_DMA;
drivers/scsi/u14-34f.c:983:            (sh[j]->unchecked_isa_dma ? GFP_DMA : 0) | GFP_ATOMIC))) {

GFP_DMA in general is deprecated and should be replaced by appropiate dma_alloc_coherent()
or similar.  And I can't imagine any modern systems still need them, and for 
the few still non CONFIG_BROKEN ISA drivers maybe some other way can be found?
And do they really require the mid layer data structures to be GFP_DMA too?

Is it possible to get rid of those GFP_DMAs in the mid layer and the 
higher level drivers like sd,sr,ch etc.?

Thanks,

-Andi

             reply	other threads:[~2006-10-01 20:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-01 20:13 Andi Kleen [this message]
2006-10-01 20:40 ` GFP_DMA use in SCSI midlayer James Bottomley
2006-10-01 20:55   ` Andi Kleen
2006-10-02 14:52     ` James Bottomley
2006-10-02 19:18       ` Andi Kleen
2006-10-02 22:24         ` Christoph Lameter
2006-10-02 18:43   ` Mike Christie
2006-10-02 18:51     ` Mike Christie

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=200610012213.24123.ak@suse.de \
    --to=ak@suse.de \
    --cc=clameter@sgi.com \
    --cc=linux-scsi@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.