linux-kernel - Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 06 Jun 2014 11:02:48 -0600
From:	Shuah Khan <shuah.kh@...sung.com>
To:	Eli Billauer <eli.billauer@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>
Cc:	Joerg Roedel <joro@...tes.org>, devel@...verdev.osuosl.org,
	discuss@...-64.org, linux-kernel@...r.kernel.org,
	bhelgaas@...gle.com, iommu@...ts.linux-foundation.org,
	linux-pci@...r.kernel.org, Tejun Heo <tj@...nel.org>,
	Shuah Khan <shuah.kh@...sung.com>
Subject: Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for
 dma_map_single()

On 06/06/2014 10:21 AM, Eli Billauer wrote:
> On 06/06/14 19:01, Greg KH wrote:
>>> Please try to put yourself in my position: I have a driver that I care
>>> >  about, which works fine for a few years. It's based upon
>>> dma_map_single(),
>>> >  which seems to be the common way to get non-coherent memory, even
>>> for the
>>> >  driver's entire lifespan. I realize that dma_alloc_* was the
>>> intended way to
>>> >  do it, but fact is that dma_map_* has become the common choice.
>>>
>> Is your driver in the kernel tree?  If not, you really are on your own :(
>>
> It's the Xillybus driver in the staging area. I don't know if this
> counts for being in the kernel tree...
>
> The suggested patchset would allow replacing my use of dma_map_single()
> with a managed version of that function. This will clean the driver's
> code considerably.
>
> But I think that the discussion here is if it's valid to use
> dma_map_single() for a device-permanent DMA mapping, or if
> dma_alloc_noncoherent() is the only way. If the answer is no, there's
> quite obviously no point in a devres version for that function.
>

Eli,

dma_map_single() and dma_unmap_single() are streaming DMA APIs. These
are intended for one DMA transfer and unmapped right after it is done.

dma buffers are limited shared resources for streaming that are
shared by several drivers. Hence the need for use and release
model.

Please refer to the Using Streaming DMA mappings in DMA-API-HOWTO.txt

"- Streaming DMA mappings which are usually mapped for one DMA
   transfer, unmapped right after it (unless you use dma_sync_* below)
   and for which hardware can optimize for sequential accesses.

   This of "streaming" as "asynchronous" or "outside the coherency
   domain".

   Good examples of what to use streaming mappings for are:

         - Networking buffers transmitted/received by a device.
         - Filesystem buffers written/read by a SCSI device."


If I understand your intended usage correctly, you are looking to
allocate and hold the buffers for the lifetime of the driver. For
such cases, dma_alloc_*() interfaces are the ones to use.

Please also refer to DMA-API.txt as well. Hope this helps.

-- Shuah


-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@...sung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/