From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v2 0/7] Stop losing firmware-set DMA masks Date: Mon, 6 Aug 2018 14:13:45 +0200 Message-ID: References: <1ccccc4b-7d4c-a3ee-23a2-f108916705e9@arm.com> <20180806121334.GA5340@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180806121334.GA5340-jcswGhMUV9g@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Christoph Hellwig Cc: Frank Rowand , gregkh , the arch/x86 maintainers , ACPI Devel Maling List , "open list:IOMMU DRIVERS" , Rob Herring , Sudeep Holla , Robin Murphy , Linux ARM List-Id: linux-acpi@vger.kernel.org On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig wrote: > > On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote: > > There are a few subtle corner cases here, in particular in which cases > > the new dma_set_mask() behavior on arm64 reports success or > > failure when truncating the mask to the bus_dma_mask. > > Going forward my plan was to make dma_set_mask() never fail. The idea > is that it sets the mask that the device is capable of, and the core > dma code is responsible for also looking at bus_dma_mask and otherwise > make things just work. > > Robin brought up the case where a platform can't handle a given limitation > ever, e.g. a PCI(e) device with a 24-bit dma mask on a device with a dma > offset that means we'll never have any physical memory reachable in that > range. So we'll either still need to allow it to fail for such corner > cases or delay such error until later, e.g. when dma_alloc_* (or in the > corner case of the corner case dma_map_*) is called. I'm still undecided > which way to go, but not allowing error returns from dma_set_mask and > its variants sounds very tempting. Another case that I think can happen in practice are devices that need a DMA mask smaller than 32-bit wide (either asked for by the driver or according to bus limitations) on a platform that has no ZONE_DMA. However, IIRC there was no reason to ever fail a dma_set_mask() to something wider than 32 bit even if the resulting mask still stays at the default 32-bit mask or something inbetween. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 6 Aug 2018 14:13:45 +0200 Subject: [PATCH v2 0/7] Stop losing firmware-set DMA masks In-Reply-To: <20180806121334.GA5340@lst.de> References: <1ccccc4b-7d4c-a3ee-23a2-f108916705e9@arm.com> <20180806121334.GA5340@lst.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig wrote: > > On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote: > > There are a few subtle corner cases here, in particular in which cases > > the new dma_set_mask() behavior on arm64 reports success or > > failure when truncating the mask to the bus_dma_mask. > > Going forward my plan was to make dma_set_mask() never fail. The idea > is that it sets the mask that the device is capable of, and the core > dma code is responsible for also looking at bus_dma_mask and otherwise > make things just work. > > Robin brought up the case where a platform can't handle a given limitation > ever, e.g. a PCI(e) device with a 24-bit dma mask on a device with a dma > offset that means we'll never have any physical memory reachable in that > range. So we'll either still need to allow it to fail for such corner > cases or delay such error until later, e.g. when dma_alloc_* (or in the > corner case of the corner case dma_map_*) is called. I'm still undecided > which way to go, but not allowing error returns from dma_set_mask and > its variants sounds very tempting. Another case that I think can happen in practice are devices that need a DMA mask smaller than 32-bit wide (either asked for by the driver or according to bus limitations) on a platform that has no ZONE_DMA. However, IIRC there was no reason to ever fail a dma_set_mask() to something wider than 32 bit even if the resulting mask still stays at the default 32-bit mask or something inbetween. Arnd