Re: [Bug 9880] dma_free_coherent in arcmsr when calling areca tools

[David Brownell <david-b@pacbell.net>]

On Sunday 03 February 2008, James Bottomley wrote:
> That's caused by this commit:
> 
> commit aa24886e379d2b641c5117e178b15ce1d5d366ba
> Author: David Brownell <david-b@pacbell.net>
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html