[PATCH] powerpc/dma: Fix invalid DMA mmap behavior
Shawn Anastasio
shawn at anastas.io
Fri Jul 19 17:36:42 AEST 2019
On 7/19/19 2:06 AM, Christoph Hellwig wrote:
> What is inherently architecture specific here over the fact that
> the pgprot_* expand to architecture specific bits?
What I meant is that different architectures seem to have different
criteria for setting the different pgprot_ bits. i.e. ppc checks
for cache coherency, arm64 checks for cache coherency and
writecombine, mips just checks for writecombine, etc.
That being said, I'm no expert here and there is probably some behavior
here that would make for a much more sane default.
> I'd rather not create boilerplate code where we don't have to it. Note
> that arch_dma_mmap_pgprot is a little misnamed now, as we also use it
> for the in-kernel remapping in kernel/dma/remap.c, which I'm slowly
> switching a lot of architectures to. powerpc will follow soon once
> I get the ppc44x that was given to me to actually boot with a recent
> kernel (not that I've tried much so far).
Fair enough. I didn't realize that most of the other architectures
don't use the common code anyways as you mention below.
> Every arch except for arm32 now uses dma direct for the direct mapping,
> and thus the common code without the indeed odd default. I also have
> a series to remove the default fallback, which is inherently a bad idea:
>
>
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-no-defaults
Awesome. This is great to hear.
> I think your patch that started this thread is fine for 5.3 and -stable:
>
> Reviewed-by: Christoph Hellwig <hch at lst.de>
Thanks!
> But going forward I'd rather have a sane default.
Agreed.
More information about the Linuxppc-dev
mailing list