On Fri, Dec 28, 2018 at 06:59:00PM +0100, Christoph Hellwig wrote:
> On Fri, Dec 28, 2018 at 05:30:57PM +, Liviu Dudau wrote:
> > On Wed, Dec 19, 2018 at 05:55:02PM +0100, Christoph Hellwig wrote:
> > > As all maintainers seem to be off to their holidays already I've
> > > applied this now give
On Fri, Dec 28, 2018 at 05:30:57PM +, Liviu Dudau wrote:
> On Wed, Dec 19, 2018 at 05:55:02PM +0100, Christoph Hellwig wrote:
> > As all maintainers seem to be off to their holidays already I've
> > applied this now given that I don't want to leave arm64 in broken
> > state in linux-next any lo
On Wed, Dec 19, 2018 at 05:55:02PM +0100, Christoph Hellwig wrote:
> As all maintainers seem to be off to their holidays already I've
> applied this now given that I don't want to leave arm64 in broken
> state in linux-next any longer.
Hi Christoph,
Talking about linux-next being broken, I found
On Wed, Dec 19, 2018 at 04:59:03PM +, Robin Murphy wrote:
> On 14/12/2018 15:02, Christoph Hellwig wrote:
>> Otherwise the direct mapping won't work at all given that a NULL
>> dev->dma_ops causes a fallback. Note that we already explicitly set
>> dev->dma_ops to dma_dummy_ops for dma-incapabl
On 14/12/2018 15:02, Christoph Hellwig wrote:
Otherwise the direct mapping won't work at all given that a NULL
dev->dma_ops causes a fallback. Note that we already explicitly set
dev->dma_ops to dma_dummy_ops for dma-incapable devices, so this
fallback should not be needed anyway.
Sorry, I'd s
As all maintainers seem to be off to their holidays already I've
applied this now given that I don't want to leave arm64 in broken
state in linux-next any longer.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/ma
Otherwise the direct mapping won't work at all given that a NULL
dev->dma_ops causes a fallback. Note that we already explicitly set
dev->dma_ops to dma_dummy_ops for dma-incapable devices, so this
fallback should not be needed anyway.
Fixes: 356da6d0cd ("dma-mapping: bypass indirect calls for dm
