<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/dma, branch v5.0</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.0</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.0'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2019-01-16T14:59:17Z</updated>
<entry>
<title>swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit</title>
<updated>2019-01-16T14:59:17Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-01-14T20:14:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=227a76b64718888c1687cc237463aa000ae6fb2b'/>
<id>urn:sha1:227a76b64718888c1687cc237463aa000ae6fb2b</id>
<content type='text'>
Otherwise is_swiotlb_buffer will return false positives when
we first initialize a swiotlb buffer, but then free it because
we have an IOMMU available.

Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")
Reported-by: Sibren Vasse &lt;sibren@sibrenvasse.nl&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Sibren Vasse &lt;sibren@sibrenvasse.nl&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
</content>
</entry>
<entry>
<title>dma-direct: fix DMA_ATTR_NO_KERNEL_MAPPING for remapped allocations</title>
<updated>2019-01-05T07:28:29Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-01-04T17:31:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8270f3a11ceef64bdb0ab141180e8d2f17c619ec'/>
<id>urn:sha1:8270f3a11ceef64bdb0ab141180e8d2f17c619ec</id>
<content type='text'>
We need to return a dma_addr_t even if we don't have a kernel mapping.
Do so by consolidating the phys_to_dma call in a single place and jump
to it from all the branches that return successfully.

Fixes: bfd56cd60521 ("dma-mapping: support highmem in the generic remap allocator")
Reported-by: Liviu Dudau &lt;liviu@dudau.co.uk
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: Liviu Dudau &lt;liviu@dudau.co.uk&gt;
</content>
</entry>
<entry>
<title>dma-mapping: remove a few unused exports</title>
<updated>2019-01-04T08:03:17Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-01-01T16:14:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=48e638fb68be8fecdca0611beff53a9c947704e3'/>
<id>urn:sha1:48e638fb68be8fecdca0611beff53a9c947704e3</id>
<content type='text'>
Now that the slow path DMA API calls are implemented out of line a few
helpers only used by them don't need to be exported anymore.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>dma-mapping: remove dmam_{declare,release}_coherent_memory</title>
<updated>2019-01-04T08:03:17Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-12-26T06:51:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4788ba5792cc1368ba4867e1488dc168b4fe97b7'/>
<id>urn:sha1:4788ba5792cc1368ba4867e1488dc168b4fe97b7</id>
<content type='text'>
These functions have never been used.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>dma-mapping: implement dmam_alloc_coherent using dmam_alloc_attrs</title>
<updated>2019-01-04T08:03:16Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-12-25T16:44:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d7076f07840851bbe57cb21ba052d6a4a9b1efa9'/>
<id>urn:sha1:d7076f07840851bbe57cb21ba052d6a4a9b1efa9</id>
<content type='text'>
dmam_alloc_coherent is just the default no-flags case of
dmam_alloc_attrs, so take advantage of this similar to the non-managed
version.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>dma-mapping: implement dma_map_single_attrs using dma_map_page_attrs</title>
<updated>2019-01-04T08:02:17Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-12-25T07:50:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2e05ea5cdc1ac55d9ef678ed5ea6c38acf7fd2a3'/>
<id>urn:sha1:2e05ea5cdc1ac55d9ef678ed5ea6c38acf7fd2a3</id>
<content type='text'>
And also switch the way we implement the unmap side around to stay
consistent.  This ensures dma-debug works again because it records which
function we used for mapping to ensure it is also used for unmapping,
and also reduces further code duplication.  Last but not least this
also officially allows calling dma_sync_single_* for mappings created
using dma_map_page, which is perfectly fine given that the sync calls
only take a dma_addr_t, but not a virtual address or struct page.

Fixes: 7f0fee242e ("dma-mapping: merge dma_unmap_page_attrs and dma_unmap_single_attrs")
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Tested-by: LABBE Corentin &lt;clabbe.montjoie@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping</title>
<updated>2018-12-28T22:12:21Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-12-28T22:12:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=af7ddd8a627c62a835524b3f5b471edbbbcce025'/>
<id>urn:sha1:af7ddd8a627c62a835524b3f5b471edbbbcce025</id>
<content type='text'>
Pull DMA mapping updates from Christoph Hellwig:
 "A huge update this time, but a lot of that is just consolidating or
  removing code:

   - provide a common DMA_MAPPING_ERROR definition and avoid indirect
     calls for dma_map_* error checking

   - use direct calls for the DMA direct mapping case, avoiding huge
     retpoline overhead for high performance workloads

   - merge the swiotlb dma_map_ops into dma-direct

   - provide a generic remapping DMA consistent allocator for
     architectures that have devices that perform DMA that is not cache
     coherent. Based on the existing arm64 implementation and also used
     for csky now.

   - improve the dma-debug infrastructure, including dynamic allocation
     of entries (Robin Murphy)

   - default to providing chaining scatterlist everywhere, with opt-outs
     for the few architectures (alpha, parisc, most arm32 variants) that
     can't cope with it

   - misc sparc32 dma-related cleanups

   - remove the dma_mark_clean arch hook used by swiotlb on ia64 and
     replace it with the generic noncoherent infrastructure

   - fix the return type of dma_set_max_seg_size (Niklas Söderlund)

   - move the dummy dma ops for not DMA capable devices from arm64 to
     common code (Robin Murphy)

   - ensure dma_alloc_coherent returns zeroed memory to avoid kernel
     data leaks through userspace. We already did this for most common
     architectures, but this ensures we do it everywhere.
     dma_zalloc_coherent has been deprecated and can hopefully be
     removed after -rc1 with a coccinelle script"

* tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping: (73 commits)
  dma-mapping: fix inverted logic in dma_supported
  dma-mapping: deprecate dma_zalloc_coherent
  dma-mapping: zero memory returned from dma_alloc_*
  sparc/iommu: fix -&gt;map_sg return value
  sparc/io-unit: fix -&gt;map_sg return value
  arm64: default to the direct mapping in get_arch_dma_ops
  PCI: Remove unused attr variable in pci_dma_configure
  ia64: only select ARCH_HAS_DMA_COHERENT_TO_PFN if swiotlb is enabled
  dma-mapping: bypass indirect calls for dma-direct
  vmd: use the proper dma_* APIs instead of direct methods calls
  dma-direct: merge swiotlb_dma_ops into the dma_direct code
  dma-direct: use dma_direct_map_page to implement dma_direct_map_sg
  dma-direct: improve addressability error reporting
  swiotlb: remove dma_mark_clean
  swiotlb: remove SWIOTLB_MAP_ERROR
  ACPI / scan: Refactor _CCA enforcement
  dma-mapping: factor out dummy DMA ops
  dma-mapping: always build the direct mapping code
  dma-mapping: move dma_cache_sync out of line
  dma-mapping: move various slow path functions out of line
  ...
</content>
</entry>
<entry>
<title>dma-mapping: fix inverted logic in dma_supported</title>
<updated>2018-12-20T16:47:55Z</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2018-12-20T16:35:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8b1cce9f5832a8eda17d37a3c49fb7dd2d650f46'/>
<id>urn:sha1:8b1cce9f5832a8eda17d37a3c49fb7dd2d650f46</id>
<content type='text'>
The cleanup in commit 356da6d0cde3 ("dma-mapping: bypass indirect calls
for dma-direct") accidentally inverted the logic in the check for the
presence of a -&gt;dma_supported() callback. Switch this back to the way it
was to prevent a crash on boot.

Fixes: 356da6d0cde3 ("dma-mapping: bypass indirect calls for dma-direct")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>dma-mapping: zero memory returned from dma_alloc_*</title>
<updated>2018-12-20T07:13:52Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-12-14T08:00:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=518a2f1925c3165befbf06b75e07636549d92c1c'/>
<id>urn:sha1:518a2f1925c3165befbf06b75e07636549d92c1c</id>
<content type='text'>
If we want to map memory from the DMA allocator to userspace it must be
zeroed at allocation time to prevent stale data leaks.   We already do
this on most common architectures, but some architectures don't do this
yet, fix them up, either by passing GFP_ZERO when we use the normal page
allocator or doing a manual memset otherwise.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt; [m68k]
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt; [sparc]
</content>
</entry>
<entry>
<title>dma-direct: do not include SME mask in the DMA supported check</title>
<updated>2018-12-17T17:02:11Z</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2018-12-17T14:39:16Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c92a54cfa0257e8ffd66b2a17d49e9c0bd4b769f'/>
<id>urn:sha1:c92a54cfa0257e8ffd66b2a17d49e9c0bd4b769f</id>
<content type='text'>
The dma_direct_supported() function intends to check the DMA mask against
specific values. However, the phys_to_dma() function includes the SME
encryption mask, which defeats the intended purpose of the check. This
results in drivers that support less than 48-bit DMA (SME encryption mask
is bit 47) from being able to set the DMA mask successfully when SME is
active, which results in the driver failing to initialize.

Change the function used to check the mask from phys_to_dma() to
__phys_to_dma() so that the SME encryption mask is not part of the check.

Fixes: c1d0af1a1d5d ("kernel/dma/direct: take DMA offset into account in dma_direct_supported")
Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
</feed>
