From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967545AbeCSQzs (ORCPT ); Mon, 19 Mar 2018 12:55:48 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55352 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935120AbeCSQzo (ORCPT ); Mon, 19 Mar 2018 12:55:44 -0400 Date: Mon, 19 Mar 2018 16:55:51 +0000 From: Will Deacon To: Christoph Hellwig Cc: Robin Murphy , x86@kernel.org, Tom Lendacky , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, Muli Ben-Yehuda , iommu@lists.linux-foundation.org, David Woodhouse , Catalin Marinas Subject: Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code Message-ID: <20180319165551.GE14916@arm.com> References: <20180319103826.12853-1-hch@lst.de> <20180319103826.12853-13-hch@lst.de> <20180319152442.GA27915@lst.de> <5316b479-7e75-d62f-6b17-b6bece55187c@arm.com> <20180319154832.GD14916@arm.com> <20180319160343.GA29002@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180319160343.GA29002@lst.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 03:48:33PM +0000, Will Deacon wrote: > > Why can't we just resolve the conflict by adding the underscores? > > We can solve the conflict easily that way. But that's not the point. > > The point is that I've been fighting hard to consolidate dma code > given that the behavior really is common and not arch specific. And > this one is another case like that: the fact that the non-coherent > dma boundary is bigger than the exposed size is something that can > easily happen elsewhere, so there is no need to duplicate a lot > of code for that. Fair enough, although I wouldn't say it's a *lot* of code being duplicated. Are there other architectures working around this issue too? I couldn't see anything in the other dma-direct.h headers. > Nevermind that the commit should at least be three different patches: > > (1) revert the broken original commit > (2) increase the dma min alignment > (3) put the swiotlb workaround in place I'd agree with you if this wasn't already queued and sitting in -next. Reverting what we currently have seems a bit OTT now. Catalin? Will From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code Date: Mon, 19 Mar 2018 16:55:51 +0000 Message-ID: <20180319165551.GE14916@arm.com> References: <20180319103826.12853-1-hch@lst.de> <20180319103826.12853-13-hch@lst.de> <20180319152442.GA27915@lst.de> <5316b479-7e75-d62f-6b17-b6bece55187c@arm.com> <20180319154832.GD14916@arm.com> <20180319160343.GA29002@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20180319160343.GA29002-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: Tom Lendacky , Konrad Rzeszutek Wilk , David Woodhouse , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Muli Ben-Yehuda , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Catalin Marinas List-Id: iommu@lists.linux-foundation.org On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 03:48:33PM +0000, Will Deacon wrote: > > Why can't we just resolve the conflict by adding the underscores? > > We can solve the conflict easily that way. But that's not the point. > > The point is that I've been fighting hard to consolidate dma code > given that the behavior really is common and not arch specific. And > this one is another case like that: the fact that the non-coherent > dma boundary is bigger than the exposed size is something that can > easily happen elsewhere, so there is no need to duplicate a lot > of code for that. Fair enough, although I wouldn't say it's a *lot* of code being duplicated. Are there other architectures working around this issue too? I couldn't see anything in the other dma-direct.h headers. > Nevermind that the commit should at least be three different patches: > > (1) revert the broken original commit > (2) increase the dma min alignment > (3) put the swiotlb workaround in place I'd agree with you if this wasn't already queued and sitting in -next. Reverting what we currently have seems a bit OTT now. Catalin? Will