Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2501547ybd; Mon, 24 Jun 2019 07:31:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAF8WTZro4SWtPDi5HE44uhc9Gx2EQkeDdTo4WmLh29NvviBbGIZv9YVoVP91YHsp7Pppx X-Received: by 2002:a17:90a:8985:: with SMTP id v5mr24862685pjn.136.1561386697226; Mon, 24 Jun 2019 07:31:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561386697; cv=none; d=google.com; s=arc-20160816; b=mZvHLQSQadwJGMA2PKMUtMl7y0jOlWXj39TW54r6W0KaKM0lSG42s6mz8u1u6AZllN NRNdR4/HEFLspufASrbigKjKYLWyxeXH9BFHSIxDjPN6z+YDvkLGk6AGd7hhRW5bn8xW mbMtNgd4R8USBhQ9vPYgzJ0Uapq2zAjwRO3lw5NXGOAs0a5OH05uOMTf5ibkkcAhNhDW lt1o/I3i/EOdmVapLwnwePhIISeHK6m6/4E0T1IflQwTCGjT66xy9zLX2KOgkXkHn5cz VmIFqhB41k1M1+pZlY5Pa1xWI6zbGUqAM927zZDyFLFcR7XZazC4rQe9ol22fm1qMNhw 4SPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=z272IsYzaEQjwyNvw91xt021MtQhy8XA3cKUoI8r4o0=; b=BIGiykpK3YXiKNkFZgQIRDB5Eg9FAUZqkjdu4MZq1er1nsw9hwIq+kyVzA3SaYcxVk 1SuBmRruHB44jYRfUCPHQeyh0lDfR/Ym6SdrVWAeSKG1tY5oC5BeGVqJql0I6dj+b9ji na+9VYLEY26SWYFV9tK5Njhn2WCmxPb7Gl+IBRtwgjIb0BezC5ot4k8ts+g1fdtX3tmG zeI1z5ziaaGhuG3JOjmj1xo2eafULPmGgkymhOy43N6tnMyIjO0kLF2Y/r1AbJSU9Lnl gRQCE8IniIVvHTwKot/gbh04P3jaygdNhk7zaYdmGvAqP0iIAHZ2TVOtjdItERrt60/T LNSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l9si8557376pgp.429.2019.06.24.07.31.21; Mon, 24 Jun 2019 07:31:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728178AbfFXOXN (ORCPT + 99 others); Mon, 24 Jun 2019 10:23:13 -0400 Received: from foss.arm.com ([217.140.110.172]:51752 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727170AbfFXOXN (ORCPT ); Mon, 24 Jun 2019 10:23:13 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4151B344; Mon, 24 Jun 2019 07:23:12 -0700 (PDT) Received: from [10.1.32.158] (unknown [10.1.32.158]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C9083F71E; Mon, 24 Jun 2019 07:23:10 -0700 (PDT) Subject: Re: [PATCH 1/7] arm-nommu: remove the partial DMA_ATTR_NON_CONSISTENT support To: Christoph Hellwig , Vineet Gupta Cc: Jonas Bonn , Stefan Kristiansson , Stafford Horne , Helge Deller , linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-xtensa@linux-xtensa.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <20190614144431.21760-1-hch@lst.de> <20190614144431.21760-2-hch@lst.de> From: Vladimir Murzin Message-ID: Date: Mon, 24 Jun 2019 15:23:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190614144431.21760-2-hch@lst.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/14/19 3:44 PM, Christoph Hellwig wrote: > The arm-nommu DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but > does not provide a cache_sync operation. This means any user of it > will never be able to actually transfer cache ownership and thus cause > coherency bugs. By the way, Documentation/DMA-attributes.txt doesn't specify cache_sync() as requirement for DMA_ATTR_NON_CONSISTENT it only states that it is responsibility of the driver to have all the correct and necessary sync points. > > Signed-off-by: Christoph Hellwig > --- > arch/arm/mm/dma-mapping-nommu.c | 24 +++--------------------- > 1 file changed, 3 insertions(+), 21 deletions(-) > > diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c > index f304b10e23a4..bc003df45546 100644 > --- a/arch/arm/mm/dma-mapping-nommu.c > +++ b/arch/arm/mm/dma-mapping-nommu.c > @@ -39,18 +39,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t size, > unsigned long attrs) > > { > - void *ret; > - > - /* > - * Try generic allocator first if we are advertised that > - * consistency is not required. > - */ > - > - if (attrs & DMA_ATTR_NON_CONSISTENT) > - return dma_direct_alloc_pages(dev, size, dma_handle, gfp, > - attrs); > - > - ret = dma_alloc_from_global_coherent(size, dma_handle); > + void *ret = dma_alloc_from_global_coherent(size, dma_handle); > > /* > * dma_alloc_from_global_coherent() may fail because: > @@ -70,16 +59,9 @@ static void arm_nommu_dma_free(struct device *dev, size_t size, > void *cpu_addr, dma_addr_t dma_addr, > unsigned long attrs) > { > - if (attrs & DMA_ATTR_NON_CONSISTENT) { > - dma_direct_free_pages(dev, size, cpu_addr, dma_addr, attrs); > - } else { > - int ret = dma_release_from_global_coherent(get_order(size), > - cpu_addr); > - > - WARN_ON_ONCE(ret == 0); > - } > + int ret = dma_release_from_global_coherent(get_order(size), cpu_addr); > > - return; > + WARN_ON_ONCE(ret == 0); > } > > static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma, > FWIW: Reviewed-by: Vladimir Murzin Cheers Vladimir