On Sunday 03 February 2008, James Bottomley wrote: > That's caused by this commit: > > commit aa24886e379d2b641c5117e178b15ce1d5d366ba > Author: David Brownell <[EMAIL PROTECTED]> > Date: Fri Aug 10 13:10:27 2007 -0700 > > dma_free_coherent() needs irqs enabled (sigh) > > I've cc'd the people responsible for this apparent bit of idiocy. Since > the API addition to dma_alloc_coherent() was the GFP flags so you could > call it from interrupt context with GFP_ATOMIC if so desired, > (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth > would the corresponding free routine require non-atomic semantics?
That was my reaction ... but I was told this would not be fixed. See also 8a3c1f573c771e60f67ef172d2392d1a28385b4a ... several other controller drivers needed similar logic at one point. (I eventually ripped that programming interface out, or *EVERY* driver would have needed crap like that. The interface was mostly misused anyway, so it was no big loss.) > Is it seriously true that you can call dma_alloc_coherent() from atomic > context on arm, but not dma_free_coherent()? Lacking a tasklet in dma_free_coherent() analagous to that omap_udc commit I referenced ... - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
