On Sat, Jun 11, 2011 at 11:18:46AM -0600, Robert Hancock wrote: > It sounds to me like these drivers using GFP_DMA should really be fixed > to use the proper DMA API. That's what it's there for. The problem is > that GFP_DMA doesn't really mean anything generically other than "memory > suitable for DMA according to some criteria". It would be really nice to have an allocation interface which takes a DMA mask and returns memory which satisfies that DMA mask, but that's a pipedream I've had for the last 12 years or so. GFP_DMA is not about the DMA API - the DMA API does _not_ deal with memory allocation for streaming transfers at all. It only deals with coherent DMA memory allocation which is something completely different. So it really isn't about "these drivers should be fixed to use the proper DMA API" because there isn't one. If the concensus is to remove GFP_DMA, there would need to be some ground work done first: (a) audit whether GFP_DMA is really needed (iow, is the allocated structure actually DMA'd from/to, or did the driver writer just slap GFP_DMA on it without thinking?) (b) audit whether we have a DMA mask available at the GFP_DMA allocator call site That should reveal whether it is even possible to move to a different solution. Depending on (b), provide a new allocation API which takes the DMA mask and internally calls the standard allocator with GFP_DMA if the DMA mask is anything less than "all memory". -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>