From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0077.outbound.protection.outlook.com [104.47.38.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3tzHDK1C2JzDq8b for ; Thu, 12 Jan 2017 05:17:20 +1100 (AEDT) From: Bart Van Assche To: "gregkh@linuxfoundation.org" CC: "linux-parisc@vger.kernel.org" , "linux-pci@vger.kernel.org" , "ysato@users.sourceforge.jp" , "linux-xtensa@linux-xtensa.org" , "linux-rdma@vger.kernel.org" , "jesper.nilsson@axis.com" , "mulix@mulix.org" , "hpa@zytor.com" , "catalin.marinas@arm.com" , "uclinux-h8-devel@lists.sourceforge.jp" , "linux-hexagon@vger.kernel.org" , "geoff@infradead.org" , "jcmvbkbc@gmail.com" , "linux@armlinux.org.uk" , "iommu@lists.linux-foundation.org" , "linux-c6x-dev@linux-c6x.org" , "linux-am33-list@redhat.com" , "linux-ia64@vger.kernel.org" , "linux-cris-kernel@axis.com" , "linux-mips@linux-mips.org" , "linux-m68k@lists.linux-m68k.org" , "a-jacquiot@ti.com" , "dalias@libc.org" , "linux-metag@vger.kernel.org" , "nios2-dev@lists.rocketboards.org" , "linux-sh@vger.kernel.org" , "shorne@gmail.com" , "lftan@altera.com" , "deller@gmx.de" , "jdmason@kudzu.us" , "linux-alpha@vger.kernel.org" , "openrisc@lists.librecores.org" , "sparclinux@vger.kernel.org" , "chris@zankel.net" , "davem@davemloft.net" , "joro@8bytes.org" , "tglx@linutronix.de" , "linuxppc-dev@lists.ozlabs.org" , "x86@kernel.org" , "fenghua.yu@intel.com" , "jejb@parisc-linux.org" , "linux-snps-arc@lists.infradead.org" , "msalter@redhat.com" , "dledford@redhat.com" , "adi-buildroot-devel@lists.sourceforge.net" , "linux-arm-kernel@lists.infradead.org" , "starvik@axis.com" , "dhowells@redhat.com" , "hskinnemoen@gmail.com" , "mingo@redhat.com" , "stefan.kristiansson@saunalahti.fi" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , "jonas@southpole.se" , "geert@linux-m68k.org" , "egtvedt@samfundet.no" , "will.deacon@arm.com" , "linux-s390@vger.kernel.org" Subject: Re: [PATCH 2/9] Move dma_ops from archdata into struct device Date: Wed, 11 Jan 2017 18:17:03 +0000 Message-ID: <1484158589.2619.14.camel@sandisk.com> References: <20170111005648.14988-1-bart.vanassche@sandisk.com> <20170111005648.14988-3-bart.vanassche@sandisk.com> <20170111064803.GB26893@kroah.com> In-Reply-To: <20170111064803.GB26893@kroah.com> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > > transfer data between memory and PCIe adapter. Because of performance > > reasons it is important that the CPU cache is not flushed when such > > drivers transfer data. Make this possible by allowing these drivers to > > override the dma_map_ops pointer. Additionally, introduce the function > > set_dma_ops() that will be used by a later patch in this series. >=20 > When you say things like "additionally", that's a huge flag that this > needs to be split up into multiple patches.=A0=A0No need to add > set_dma_ops() here in this patch. Hello Greg, Some architectures already define a=A0set_dma_ops() function. So what this patch does is to move both the dma_ops pointer and the set_dma_ops() function from architecture-specific to architecture independent code. I don't think that it is possible to separate these two changes. But I understand that how I formulated the patch description caused confusion. I will rewrite the patch description to make it more clear before I repost this patch series. > And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just > to keep the namespace sane, but that's probably a different set of > patches... Every time I rebase and retest this patch series on top of a new kernel version I have to modify some of the patches to compensate for changes in the architecture code. So I expect that once Linus merges these patches tha= t he will have to resolve one or more merge conflicts. Including a rename of the functions that query and set the dma_ops pointer in this patch series would increase the number of merge conflicts triggered by this patch series and would make Linus' job harder. So I hope that you will allow me to postpone that rename until a later time ... Bart.=