[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <494065F6.3010602@shaw.ca>
Date: Wed, 10 Dec 2008 18:59:34 -0600
From: Robert Hancock <hancockr@...w.ca>
To: Wu Fengguang
<public-fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@...h.gmane.org>
CC: Gilad Ben-Yossef
<public-gilad-f4XOiQkOAtcdH0auuBZGHA@...h.gmane.org>,
Laurent Pinchart
<public-laurent.pinchart-AgBVmzD5pcezQB+pC5nmwQ@...h.gmane.org>,
LKML <public-linux-kernel-u79uwXL29TY76Z2rM5mHXA@...h.gmane.org>,
Greg Kroah-Hartman <public-gregkh-l3A5Bk7waGM@...h.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@...lic.gmane.org"
<public-linux-usb-u79uwXL29TY76Z2rM5mHXA@...h.gmane.org>
Subject: Re: [PATCH] USB: use stack allocation for struct usb_ctrlrequest
Wu Fengguang wrote:
>> In many cases there is no problem to DMA high memory. If you happen to
>> be working with a device that does have problems with full 32 bit
>> addresses then GFP_DMA would be the right flag, not GFP_NOIO.
>
> For 64bit systems, we can easily go beyond 4GB physical memory.
> So at least we should add GFP_DMA32 in addition to GFP_NOIO?
No. The DMA mapping API handles either setting up the IOMMU or doing
software bounce buffering to handle the DMA transfer regardless of where
the memory is located, so drivers don't need to mess with GFP_DMA32.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists