From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-by2nam03on0055.outbound.protection.outlook.com ([104.47.42.55]:51712 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23993896AbdAKSESuJmai convert rfc822-to-8bit (ORCPT ); Wed, 11 Jan 2017 19:04:18 +0100 From: Bart Van Assche Subject: Re: [PATCH 2/9] Move dma_ops from archdata into struct device Date: Wed, 11 Jan 2017 18:03:15 +0000 Message-ID: <1484157772.2619.12.camel@sandisk.com> References: <20170111005648.14988-1-bart.vanassche@sandisk.com> <20170111005648.14988-3-bart.vanassche@sandisk.com> <20170111064624.GA26893@kroah.com> In-Reply-To: <20170111064624.GA26893@kroah.com> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D8D123C7F88F844A85318B500FF63FE@sandisk.com> Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: 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" Message-ID: <20170111180315.ic_BXw3BEs5e8eNAxBGuIS1HlUE-D4HR7wCqeEu6PLw@z> On Wed, 2017-01-11 at 07:46 +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. > > > > Signed-off-by: Bart Van Assche > > Cc: [ ... ] > > That's a crazy cc: list, you should break this up into smaller pieces, > otherwise it's going to bounce... That's a subset of what scripts/get_maintainer.pl came up with. Suggestions for a more appropriate cc-list for a patch like this that touches all architectures would be welcome. > > diff --git a/include/linux/device.h b/include/linux/device.h > > index 491b4c0ca633..c7cb225d36b0 100644 > > --- a/include/linux/device.h > > +++ b/include/linux/device.h > > @@ -885,6 +885,8 @@ struct dev_links_info { > >   * a higher-level representation of the device. > >   */ > >  struct device { > > + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */ > > + > >   struct device *parent; > >   > >   struct device_private *p; > > Why not put this new pointer down with the other dma fields in this > structure?  Any specific reason it needs to be first? Are there CPU architectures for which access to the first member of a structure can be encoded and/or executed more efficiently than access to other members of a structure? If not, I'm fine with moving the new pointer further down. Bart.