[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191113.121132.1658930697082028145.davem@davemloft.net>
Date: Wed, 13 Nov 2019 12:11:32 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: laurentiu.tudor@....com
Cc: hch@....de, robin.murphy@....com, joro@...tes.org,
ruxandra.radulescu@....com, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, netdev@...r.kernel.org,
ioana.ciornei@....com, leoyang.li@....com, diana.craciun@....com,
madalin.bucur@....com, camelia.groza@....com
Subject: Re: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync
variants
From: Laurentiu Tudor <laurentiu.tudor@....com>
Date: Wed, 13 Nov 2019 12:24:17 +0000
> From: Laurentiu Tudor <laurentiu.tudor@....com>
>
> This series introduces a few new dma unmap and sync api variants that,
> on top of what the originals do, return the virtual address
> corresponding to the input dma address. In order to do that a new dma
> map op is added, .get_virt_addr that takes the input dma address and
> returns the virtual address backing it up.
> The second patch adds an implementation for this new dma map op in the
> generic iommu dma glue code and wires it in.
> The third patch updates the dpaa2-eth driver to use the new apis.
The driver should store the mapping in it's private software state if
it needs this kind of conversion.
This is huge precendence for this, and there is therefore no need to
add even more complication and methods and burdon to architecture code
for the sake of this.
Thank you.
Powered by blists - more mailing lists