On Wed, Jan 10, 2018 at 03:31:08PM +, Robin Murphy wrote:
> Yes indeed, modulo Vladimir's comments - it does seem prudent to fix the
> obvious off-by-ones as we touch them. I've wanted to do something like this
> for ages, but never got around to it myself.
I've fixed these now in a
On 10/01/18 15:26, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote:
I took a look at these, and it seems their phys_to_dma() usage is doing the
thing which we subsequently formalised as dma_map_resource(). I've had a
crack at a quick patch to update the
On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote:
> I took a look at these, and it seems their phys_to_dma() usage is doing the
> thing which we subsequently formalised as dma_map_resource(). I've had a
> crack at a quick patch to update the CESA driver; qcom_nandc looks slightly
>
On Wed, Jan 10, 2018 at 09:31:45AM +, Vladimir Murzin wrote:
> I know it is copy, but it seems it has off by one error and it should be
>
> return addr + size - 1 <= *dev->dma_mask;
I've added a new patch to fix the mips dma_capable() definition,
thanks.
On 10/01/18 08:00, Christoph Hellwig wrote:
phys_to_dma, dma_to_phys and dma_capable are helpers published by
architecture code for use of swiotlb and xen-swiotlb only. Drivers are
not supposed to use these directly, but use the DMA API instead.
Move these to a new asm/dma-direct.h helper,
On 10/01/18 08:00, Christoph Hellwig wrote:
> index 9110988b92a1..f00833acb626 100644
> --- a/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h
> +++ b/arch/mips/include/asm/mach-cavium-octeon/dma-coherence.h
> @@ -61,6 +61,14 @@ static inline void plat_post_dma_flush(struct device *dev)
>
phys_to_dma, dma_to_phys and dma_capable are helpers published by
architecture code for use of swiotlb and xen-swiotlb only. Drivers are
not supposed to use these directly, but use the DMA API instead.
Move these to a new asm/dma-direct.h helper, included by a
linux/dma-direct.h wrapper that
