From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org
Cc: Shawn Anastasio <shawn@anastas.io>,
Michael Ellerman <mpe@ellerman.id.au>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
linuxppc-dev@lists.ozlabs.org, linux-mips@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: fix default dma_mmap_* pgprot v3
Date: Wed, 7 Aug 2019 09:16:00 +0300 [thread overview]
Message-ID: <20190807061602.31217-1-hch@lst.de> (raw)
Hi all,
As Shawn pointed out we've had issues with the dma mmap pgprots ever
since the dma_common_mmap helper was added beyong the initial
architectures - we default to uncached mappings, but for devices that
are DMA coherent, or if the DMA_ATTR_NON_CONSISTENT is set (and
supported) this can lead to aliasing of cache attributes. This patch
fixes that. My explanation of why this hasn't been much of an issue
is that the dma_mmap_ helpers aren't used widely and mostly just in
architecture specific drivers.
Changes since v2:
- fix m68knommu compile by inlining dma_prprot helper and providing
a stub for !CONFIG_MMU
- fix various typos in the commit messages
Changes since v1:
- fix handling of DMA_ATTR_NON_CONSISTENT where it is a no-op
(which is most architectures)
- remove DMA_ATTR_WRITE_COMBINE on mips, as it seem dangerous as-is
next reply other threads:[~2019-08-07 6:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 6:16 Christoph Hellwig [this message]
2019-08-07 6:16 ` [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_* Christoph Hellwig
2019-08-07 6:16 ` [PATCH 2/2] MIPS: remove support for DMA_ATTR_WRITE_COMBINE Christoph Hellwig
2019-09-18 19:50 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190807061602.31217-1-hch@lst.de \
--to=hch@lst.de \
--cc=catalin.marinas@arm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jhogan@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paul.burton@mips.com \
--cc=robin.murphy@arm.com \
--cc=shawn@anastas.io \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).