From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751606AbdALN2t (ORCPT ); Thu, 12 Jan 2017 08:28:49 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:63806 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbdALN2r (ORCPT ); Thu, 12 Jan 2017 08:28:47 -0500 From: Arnd Bergmann To: Nikita Yushchenko Cc: Robin Murphy , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, Simon Horman , Bjorn Helgaas , fkan@apm.com, linux-kernel@vger.kernel.org, Artemi Ivanov Subject: Re: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops() Date: Thu, 12 Jan 2017 14:28:03 +0100 Message-ID: <3013606.q8hexDUEqF@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com> References: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com> <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:lFm48XIzEe2H1qQPOiYB0cV2ZVp8wNo71WbrR0VAmWl0WLlyB4H l8TxO1utJpxm+L/9gu0NbIfzyI0lwxKVBf8o4QakGGNS8y2F8HFPl7P2vpvguTprlrnXZRa KKW+wB9ZS1s88wDQKQkiWgpQBTPqI4d/RsniqWszoYghsT/thLZDkI1M+TdKsHxmHWXfe/Z Of2HIKUSOWn3LriO6QUxw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tdH4QV2blQ4=:/LNmQd51yjH7HiloyiSnjo tF5Q5jJPdgnitlM9plQBnUDvzD2MFBKfwjzj6D1fuuWDp8zubNlff1aO5ZiP9092n9P1IjKYj Qt+/4BDY8rKX3I79MqmvyMkYmt5KSuY+fOuzsVUHcZfvB5Dz65nL9zMXRbhsUzg054JZy8jxq 58GqQoTi36SULQTSzwRO5l7QNEyOFVKkFcfEXUtSQZYcT39gTmdxs1sKQQIfLmLrvavnm1yEk UxT/BI0cWNEeRR+5q5xw/HjkJ2gheuk9q2p93q3jqZJwEoYytFimFU38OfnMA5mMSuO584/cE HAwnuFJpItehBB0aSIfXCcc4/CvbreEOOm7sdfGY9ZxgRX+A11EffUiW/JB45ATinfqFcoKMl Wd7MYjvGb67W5fWkPvMhIqzcqMvGsgNhk731uCSQonUAKSJI5DtxTy1G2Eq35Akuh37VB536J zCs4Co8FYXwBQPnPsaDKufNb42t7zy0o7HpOrIq/vCIvwulAkoT/btNusrV+YkH7AfSsSHXjb lr2et6K3UU+lP4/rxHoQ/uYUFPYmNtdPn1GSCBjkvfOY4f0+HVrkwOfKfZ1XxOOAgcJSiq07E iqMXGBH3r9euzcu7lEdmIwMOMhx9X+5Raz0X3gTznX7OM/5fwnWy3WtSmG83m8XzGOK1kSjBZ R4g59rxqsJtnE8YG6HURt8A+8J9K5pX4LNky78VlCfExFhVFyLM/reV6WozkfnLt5bbCzCc5N Jizm8B1BCmG5scEJ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 12 Jan 2017 14:28:03 +0100 Subject: [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops() In-Reply-To: <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com> References: <764334db-3400-58c6-cc4b-3f7ce66daa27@cogentembedded.com> <7d7dc402-e527-c581-0b1c-37713759db31@cogentembedded.com> Message-ID: <3013606.q8hexDUEqF@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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