[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3013606.q8hexDUEqF@wuerfel>
Date: Thu, 12 Jan 2017 14:28:03 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Nikita Yushchenko <nikita.yoush@...entembedded.com>
Cc: Robin Murphy <robin.murphy@....com>,
Will Deacon <will.deacon@....com>,
linux-arm-kernel@...ts.infradead.org,
linux-renesas-soc@...r.kernel.org,
Simon Horman <horms@...ge.net.au>,
Bjorn Helgaas <bhelgaas@...gle.com>, fkan@....com,
linux-kernel@...r.kernel.org,
Artemi Ivanov <artemi.ivanov@...entembedded.com>
Subject: Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
On Thursday, January 12, 2017 9:33:32 AM CET Nikita Yushchenko wrote:
> >> Hmm, I think when the dma-ranges are missing, we should either enforce
> >> a 32-bit mask, or disallow DMA completely. It's probably too late for
> >> the latter, I wish we had done this earlier in order to force everyone
> >> on ARM64 to have a valid dma-ranges property for any DMA master.
> >
> > This can be done over time.
> >
> > However the very idea of this version of patch is - keep working pieces
> > as-is, thus for now setting enforce_range to false in case of no defined
> > dma-ranges is intentional.
>
> What we can do is - check bus width (as it is defined in DT) and set
> enforce_range to true if bus is 32-bit
>
> > What I should re-check is - does rcar dtsi set dma-ranges, and add it if
> > it does not.
>
> It does not, will have to add.
>
> In DT bus is defined as 64-bit. But looks like physically it is 32-bit.
> Maybe DT needs fixing.
I think we always assumed that the lack of a dma-ranges property
implied a 32-bit width, as that is the safe fallback as well as the
most common case.
AFAICT, this means you are actually fine on rcar, and all other
platforms will keep working as we enforce it, but might get slowed
down if they relied on the unintended behavior of allowing 64-bit
DMA.
Arnd
Powered by blists - more mailing lists